AWS – VPN Server

2024-01-17 by Leka

Existem vários motivos para você querer rotear sua saída de internet por outro local ao invés do seu ISP de costume, privacidade? segurança? acesso a outros conteúdos de mídia?

O motivo em si é irrelevante, hoje contamos com diversos serviços de VPN pagos e gratuitos muito bons por aí, mas da pra confiar neles? uma VPN é basicamente um contrato de mão dupla, você confia em uma ponta enquanto a outra ponta confia em você, é estabelecido um canal de criptografia entre essas duas pontas e os dados podem ou não ser roteados através desse canal, em uma visão simplista uma análise de tráfego ou scan de rede pode partir de uma das pontas para “analisar” o que encontra-se do outro lado, por isso, mesmo uma VPN meia-boca costuma ter firewall restringindo quem e da onde pode vir o tráfego, mas em dispositivos de celular isso é quase impossível.

Claro que existem serviços honestos de VPN por aí, pagos ou gratuitos, mas por que ariscar se você pode montar um para você,,, e de graça,,,

Pra começar é simples, crie uma conta na AWS.

Depois vamos usar o serviço de Marketplace:

Procure por OpenVPN Access Server

Escolha a opção de Continue to Subscribe

Aceite os termos

Muitos termos

é só esperar para ele ativar o serviço na sua conta

Basicamente terminada a subscrição agora vamos iniciar uma máquina EC2 com o OpenVPN, escolha o local onde você vai hospedar a máquina EC2, basicamente qualquer lugar do mundo dentro da nuvem da AWS serve.

eu disse que era grátis? foi mesmo,,, você tem que alterar o tipo de máquina que vai ser usada para hospedar o OpenVPN para o modelo t2.micro

nessa parte onde você troca a máquina.

Aqui vem um detalhe, esse ambiente é grátis por 1 ano, se você já usou esse serviço de EC2 da AWS alguma vez e não aparecer a que vai ser grátis então chegou até aqui a toa, eles vão te cobrar, mas cabaçada sua de não prestar atenção nos termos de uso dos serviços deles…

VPC e Subnet a sua escolha, o que importa são as regras de firewall e o IP valido que vai ser criado para a máquina.

Como você está criado a máquina através de um template, ele já vem com um conjunto de regras pré definidas.

Essa parte é importante, salve a chave para que você tenha acesso a essa máquina através de SSH.

Basicamente após clicar em “Launch” a AWS vai criar a máquina, na região, com regras de firewall e o OpenVPN para você.

Mas não acabou por aqui, afinal, você vai querer acessar essa VPN.

Para acessar essa VPN antes você vai precisar configurar ela, nada tão complicado,,, apenas preste atenção nos detalhes, eles são a grande diferença

Após a máquina iniciar, você terá um endereço de IP válido e uma entrada de DNS. Se você não esqueceu de liberar o seu IP lá na regra de firewall você deve conseguir acessar esse servidor.

Antes de sair tentando acessar pelo Browser e configurar as coisas, você precisa logar no servidor e aceitar aqueles contratos, que como TODOS fazemos lemos até o fim um a um,,,, um a um,,,

Para acessar o servidor não precisa de nenhuma ferramenta especial (caso você esteja usando pelo menos o Windows 10), nos Linux e Mac’s da vida o ssh vem por padrão, no Windows 10 pra cima também, se você está usando alguma coisa mais antiga, procura algum cliente de SSH.

Para acessar esse novo servidor você vai abrir o prompt/terminal/posh o raio que quiser e basicamente digitar:

ssh -i "aquele_arquivo_de_chave" ec2user@IP_ou_FQDN
se não der certo tenta como root mesmo
ssh -i "aquele_arquivo_de_chave" root@IP_ou_FQDN

Se tudo deu certo, deve aparecer a licença, leia com cuidado, tudinho, tintim por tintim,,, e se achar que está tudo bem aceita a licença.

Na primeira vez que você faz login no Servidor de Acesso, um assistente de configuração é executado para permitir que você configure os parâmetros de inicialização antes de poder acessar a interface web administrativa. Neste assistente, você especifica alguns detalhes da rede e define um usuário administrador.

Se você optar por usar o usuário openvpn padrão como usuário administrador, certifique-se de definir uma senha para ele antes de acessar a interface web de administração. Para definir uma senha, use o seguinte comando shell:

sudo senha openvpn

Para acessar a interface web, abra o endereço IP público que você atribuiu e faça login como o usuário administrador que você configurou. A URL da interface da web tem o seguinte formato: https://xxx.xxx.xxx.xxx/admin.

O login abre a página Visão geral do status, conforme mostrado na imagem a seguir. É aqui que você obtém a visão geral do status do dispositivo VPN. Você também pode usar este portal para ajustar a VPN, alterar as configurações de rede e gerenciar permissões e autenticação do usuário.

Por padrão, a VPN é configurada para funcionar no modo NAT (tradução de endereço de rede) da Camada 3. Nesse modo, os clientes VPN são atribuídos a uma sub-rede privada cujos IPs são atribuídos dinamicamente a partir do pool padrão 172.27.224.0/20 (CIDR), conforme mostrado na imagem a seguir.

Você pode alterar esse pool de IPs, mas esteja ciente de que o novo deve ser diferente das outras sub-redes utilizadas na sua rede. Você também pode configurar outra sub-rede privada usada para atribuir endereços IP estáticos a usuários específicos designados na página Permissões do usuário.

Para roteamento de rede, a opção padrão é Sim, usando NAT, conforme mostrado na imagem a seguir.

Para testar a VPN

Normalmente você precisa baixar um cliente VPN para os testes, a principal vantagem do OpenVPN é ele ter clientes para todos os SO’s e Mobiles do mercado.

baixe o cliente correto, ajuste a configuração de IP que você está usando como IP público e terá uma VPN saindo pelo lugar do mundo onde você fez deploy da maquina.

AWS – Redshift – Carregar dados S3

2022-06-18 by Leka

A algum tempo atrás fiz um trabalho que teoricamente parecia simples, extrair dados de um banco transacional e mandar para um Redshift para análilse.

Claro que após bater cabeça alguns minutos entendi que imporar dados diretamente para o Redshift iria ser no mínimo conturbado e instável.

Fazendo uma análise das opções vi que a AWS disponibilizou um método muito parecido com o do SQL Server para importar arquivos diretamente para dentro do banco mas claro ao invés de fazer isso através de um servidor, é possível fazer isso através do S3.

A forma mais simples é basicamente:

copy tabela_destino
from 'S3://bucket/arquivo'
iam_role 'arn:aws:iam::01234567890:role/MinhaRegraDoRedshift'

Se o arquivo for muito grande e foi dividido ele tem que terminar com um numeral incremental 1 2 3 4 …

Se o arquivo for compactado, o comando de COPY tem que ser incrementado com GZIP.

Para mais informações tem esse link da AWS abaixo:

https://docs.aws.amazon.com/pt_br/redshift/latest/dg/t_loading-tables-from-s3.html

para monitorar essa importação você pode usar o

https://docs.aws.amazon.com/redshift/latest/dg/r_STV_LOAD_STATE.html

AWS – Redshift – Lock e Block

2022-03-22 by Leka

Por incrível que pareça o Redshift sofre com problemas de Lock e Block da mesma forma que um banco transacional qualquer.

Como qualquer post sobre nuvem, até o momento dessa publicação, o Redshift não tem uma interface que monitora Lock e Block, ela monitora conexões ativas, querys em execução mas não lock e block.

A query para monitorar o Redshift é a seguinte:

select a.txn_owner, a.txn_db, a.xid, a.pid, a.txn_start, a.lock_mode, a.relation as table_id,nvl(trim(c."name"),d.relname) as tablename, a.granted,b.pid as blocking_pid ,datediff(s,a.txn_start,getdate())/86400||' days '||datediff(s,a.txn_start,getdate())%86400/3600||' hrs '||datediff(s,a.txn_start,getdate())%3600/60||' mins '||datediff(s,a.txn_start,getdate())%60||' secs' as txn_duration
from svv_transactions a 
left join (select pid,relation,granted from pg_locks group by 1,2,3) b 
on a.relation=b.relation and a.granted='f' and b.granted='t' 
left join (select * from stv_tbl_perm where slice=0) c 
on a.relation=c.id 
left join pg_class d on a.relation=d.oid
where  a.relation is not null;

e para dar um kill no processo

select pg_terminate_backend(PID);

o resultado deve vir como “1”

No link abaixo tem mais informações:

https://aws.amazon.com/pt/premiumsupport/knowledge-center/prevent-locks-blocking-queries-redshift/

AWS – EC2 com SQL

2021-03-23 by Leka

Caso você contrate uma AMI com SQL e precise da mídia de instalação do SQL para qualquer atividade, na unidade C:\ existe um diretório chamado “SQLServerSetup” com os binários para a instalação do SQL Server.

Isso ajuda caso precise trocar o Collation da instância, adicionar feature, reinstalar usando uma instância, adicionar uma instância, etc..

A instalação padrão vem na instância default, collation SQL_Latin1_General_CP1_CI_AS, tempdb nas configurações NNF, sem IFI, basicamente uma instalação NNF.

Aí vem outra pergunta, por que pegar uma imagem da AWS com SQL? por que não usar um RDS?

Bom, a resposta disso é mais com você do que comigo, porque tudo vai depender da necessidade.

AMI – EC2 com SQL Instalado

As imagens da AWS com SQL instalado vem em diversos sabores, você escolhe o tamanho da máquina e o tipo de licenciamento STD ou ENT, eles tem developer mas se optar por esse developer você vai pagar um custo pela licença de uma aplicação que pode ser baixada gratuitamente, e ai o preço desse licenciamento do STD ou ENT vai depender do tamanho da máquina que você escolher, a vantagem fica justamente na questão de licenciamento, quem recolhe e paga para a Microsoft é a AWS, você é apenas uma empresa que está usando uma imagem já pré-instalada, então sem stress quando a licenciamento;
Toda a administração do ambiente e com você, eles só deixam o SQL instalado e o resto é o trabalho de casa, desde restaurar o banco até todas as rotinas de manutenção.

RDS

Basicamente o SQL como serviço
você não loga na máquina, não tem nenhum acesso a estrutura onde o SQL está instalado
você não é SA nem faz parte da role de Sysadmin
você é owner dos seus bancos
todas as rotinas de manutenção do SO e algumas do SQL são geridas pela AWS.
é uma administração meio a meio

Vou tratar da comparação entre uma AMI e um RDS em outro post.

AWS – Redshift – Tráfego de dados

2021-03-18 by Leka

Imagine o seguinte cenário:

Você usa o Redshift como DW ou DL para seus relatório e cargas de dados;
Vê uma possibilidade de facilitar sua vida e dar liberdade para o próprio cliente acessar esses dados e gerar relatórios da forma que ele achar mais legal com a ferramenta que ele quiser, etc.;
Mas lembra que a AWS cobra pela saída de dados;
Procura no portal da AWS e descobre que eles não tem uma monitoração específica de quem está saindo com dados, mas eles acertam a cobrança… incrível…
Mas você não quer abandonar a ideia e quer ganhar alguma grana com isso..

O que vou mostrar não é a solução perfeita, ela carece de algumas melhorias mas já é um norte para ajudar nessa ideia…

O Redshift é um PostgreSQL modificado, então muita query em tabelas de sistema do PG funciona direitinho no Redshift…

Para esse cenário, você pode criar um pacote de integration services e rodar a query abaixo contra o Redshift:

select
	TRIM(q.DATABASE) AS DB,
	TRIM(u.usename) as usename,
	sum(bytes)/1024 as kbytes,
	sum(packets) as packets,
	date(b.starttime) as data
from
	stl_bcast b
join stl_query q ON
	b.query = q.query
	AND b.userid = q.userid
join pg_user u
on u.usesysid = q.userid
where
	packets>0
	and b.starttime >= dateadd(day, -7, current_Date)
	and datediff(seconds, b.starttime, b.endtime)>0
	--and u.usename like 'usr%'
	--and querytxt not like 'fetch%'
group by TRIM(q.DATABASE)
,u.usename
,date(b.starttime)

Essa query vai trazer a informação do volume em kb trafegado pela query executada.

Com isso, você consegue montar um report incremental e ratear o custo da saída de dados da AWS.

É 100%?, não,,, mas pelo menos já é alguma coisa já que a AWS não provê dados granularizados de quem consome a saída de dados.

novos códigos serão criados também em outro repositório:

https://github.com/bigleka

AWS – Redshift – Usuário para leituras

2021-03-17 by Leka

O Redshift tem umas vantagens bem interessantes, baixo custo, RDS, baixa necessidade de manutenção.

No fundo ele é um PostgreSQL modificado para prover volume de dados e não ficar trabalhando como OLTP, ele é ótimo como estrutura para DW.

Imagine o seguinte cenário, você vende uma solução mas precisa prover um acesso do seu cliente para que ele consiga acessar uma parte dos dados diretamente na sua estrutura de banco, para ele “ter a liberdade” de cruzar esses dados, montar estruturas de relatórios, etc. da forma que ele achar mais interessante, ou até mesmo exportar esses dados para uma estrutura dele e usar da forma que achar melhor.

Certo, temos várias formas de fazer isso, todas tem seus prós e contras, mas nesse caso vou usar como exemplo justamente o título do post, vamos colocar os dados no Redshift.

Então, você tem alguma forma de extração de dados incrementais (SSIS, Pentaho, Informática, estagiário, etc.) que leva os dados do seu OLTP para o Redshift e isso funciona bem.

Agora você precisa criar a estrutura de permissões para liberar o acesso do seu cliente para essa estrutura de dados.

Uma coisa muito importante : Todos os usuários do Redshift são exclusivos do banco de dados e não da instância, Então caso o cliente tenha mais de um banco ou você queira dar permissão para mais de um banco, siga o processo quantas vezes for necessário.

— Normalmente quando os objetos são criados no Redshift ele ficam armazenados no schema public.
— Isso não é um problema, o problema começa quando é criado um schema para armazenar um outro conjunto de objetos
— para um setor da empresa, ou um outro departamento…
— Quando isso acontece, o usuário owner da carga dos objetos tem acesso a essa estrutura de dados sem problema, mas novos usuários,
— ou usuários permissonalizados não tem a permissão para os objetos ou para novos objetos nesse schema.
— O script abaixo tente a sanar um cenário em que você quer liberar o acesso de select para os objetos e novo objetos em um schema pulic
— ou personalizado sem ter que ficar dando grant toda a vez que novos objetos são criados.
— Outra opção de uso é caso você tenha um Redshift na sua empresa e venda como serviço ele como datalake para algum cliente.
— dessa forma você consegue liberar um usuário para que o cliente acesse a estrutura de dados e consiga baixar os dados.

-- Normalmente quando os objetos são criados no Redshift ele ficam armazenados no schema public.
-- Isso não é um problema, o problema começa quando é criado um schema para armazenar um outro conjunto de objetos
-- para um setor da empresa, ou um outro departamento...
-- Quando isso acontece, o usuário owner da carga dos objetos tem acesso a essa estrutura de dados sem problema, mas novos usuários,
-- ou usuários permissonalizados não tem a permissão para os objetos ou para novos objetos nesse schema.
-- O script abaixo tente a sanar um cenário em que você quer liberar o acesso de select para os objetos e novo objetos em um schema pulic
-- ou personalizado sem ter que ficar dando grant toda a vez que novos objetos são criados.
-- Outra opção de uso é caso você tenha um Redshift na sua empresa e venda como serviço ele como datalake para algum cliente.
-- dessa forma você consegue liberar um usuário para que o cliente acesse a estrutura de dados e consiga baixar os dados.

-- criar um usuário
create user <username> with password ‘<password>’;

-- cria um grupo para receber as permissões
create group data_viewers;

-- adiciona o usuário ao grupo
alter group data_viewers add user <username>;

-- nesse caso remove a opção de criar objetos para os usuários do grupo
revoke create on schema public from group data_viewers;

-- atribui acesso no schema public ao grupo
grant usage on schema public to group data_viewers;

-- atribui select em todas as tabelas do schema public para o grupo
grant select on all tables in schema public to group data_viewers;

-- atribui acesso a futuros objetos do schema public para o grupo
alter default privileges in schema public grant select on tables to group data_viewers