Quem tem interesse em “cloud computing” usando Amazon Web Services depara com uma grande quantidade de informações no sítio AWS, mas não há um caminho claro para seguir.

Sugerimos o seguinte roteiro:

1. Levantar o máximo de informação possível sobre a aplicação que será migrada para AWS: perfil de uso de CPU, memória e disco; perfil de uso de rede (banda, picos, média); tamanho do banco de dados, website, conteúdo dinâmico e estático, etc. Se for uma aplicação nova, fazer estimativas desses parâmetros.

2. Elaborar uma planilha de custos simples para uma boa estimativa dos custos de operação AWS, contendo: tamanho e região da instância EC2 que executará a aplicação, volume do armazenamento permanente EBS para dados (website e banco de dados), volume de backup S3 para dados, volume de transferência de dados (download), e estimativa de IO total.

3. Fazer o cadastro de usuário no sítio AWS, e utilizar o console de administração para conhecer seus recursos e funções, e experimentar ativando instâncias EC2 e volumes de dados EBS.

4. Planejar a migração da aplicação para AWS.

Nos projetos que a Intercom já executou, as etapas 1 e 2 são as mais importantes, pois requerem gerar documentação da aplicação existente, e permitem resumir claramente os custos de operação AWS para compará-los com o custo de outros provedores de “cloud computing” existentes.

Nas duas consultorias mencionadas no post anterior (lentidão geral na rede e Internet), Linux foi fundamental.

As duas redes são segmentadas com múltiplos switchs e VLANs, AD Windows com Windows Server 2008R2 localizados no “core”, e firewall estilo “appliance” com gerência web para Internet. Não havia uma ferramenta em lugar adequado para debug: Wireshark no Windows não mostrava tráfego Internet, e a interface web do firewall “appliance” não era de fácil uso para “packet sniffing”.

Solução? Instalamos servidores Linux provisoriamente como firewall, cujas ferramentas (tcpdump, jnettop, ntop, nmap, netflow, etc.) permitiram visão clara sobre o tráfego Internet; habilitamos proxy transparente, para registrar e gerar relatórios de padrão de acesso web; e usamos o recurso de “port mirroring” para investigar segmentos específicos da rede local.

Após o término da consultoria, ambos os clientes decidiram manter os servidores Linux, pois os múltiplos relatórios gerados se tornaram essenciais para melhor gerenciamento.

Recentemente prestamos duas consultorias de “trouble-shooting” de lentidão generalizada em acessos a recursos de rede e à Internet. As duas redes têm tamanho médio, com aprox. 200 dispositivos (estações, servidores, smartphones).

Após instaladas as ferramentas necessárias (proxy transparente para capturar o tráfego web, monitoração de tráfego em switchs, “packet sniffer”, etc.), uma grande descoberta: nas duas empresas, havia usuários rodando Torrent e gerando elevado tráfego de saída, e havia usuários pirateando músicas e vídeos gerando grande “downloads”.

Conclusão técnica óbvia: controles de acesso são necessários, e os logs precisam ser verificados com frequência.