Tráfego regional da AWS: rastrear de onde ele vem

Question

Comecei a usar várias máquinas em um cluster no AWS EC2. Desde que comecei este projeto, vejo os custos do tráfego regional nas minhas informações de faturamento:

regional data transfer - in/out/between EC2 AZs or using elastic IPs or ELB

De acordo com o nome, são três possibilidades:

• diferentes zonas de disponibilidade
• comunicação usando IPs elásticos
• usando um Elastic Loud Balancer

Tinha AZs diferentes para minhas máquinas, isso era um problema. Então eu resolvi isso, agora todas as máquinas estão no mesmo AZ, mas os custos têm aumentado por 24 horas agora (houve 3 atualizações durante esse tempo). Então parece que configurar todas as máquinas para o mesmo AZ não resolveu isso.

No entanto, eu não uso ELastic IPs nem ELB. Quando visito essas páginas no meu portal da web, ele apenas mostra uma lista vazia com uma mensagem de que eu não tenho componentes no momento.

Em outra pergunta de falha do servidor também lemos que isso acontece quando endereços IP públicos são usados para comunicação, mas em alguma discussão sobre o github a> podemos ler que mesmo o nome DNS público será resolvido internamente para o IP interno (ainda assim, o IP público sempre passará pela rede externa, portanto, de fato, acionaria os custos).

Se eu rastrear minha comunicação de rede do mestre e um dos escravos no meu cluster usando

sudo tcpdump -i eth0 | grep -v $MY_HOSTNAME

Eu posso ver apenas o tráfego interno como este:

IP ip-172-31-48-176.ec2.internal.56372 > ip-172-31-51-15.ec2.internal.54768

Então, meu problema: como posso descobrir qual componente está causando esse tráfego regional?

    

Answer 1

tl; dr

A enorme quantidade de tráfego regional foi causada por um apt-get update na inicialização da máquina.

A princípio, suspeitei do software que estou executando no cluster, porque isso envia um monte de solicitações de DNS - provavelmente ele não usa nenhum cache de DNS. E o servidor DNS está em outra zona de disponibilidade.

Caminho completo para depurar essas coisas

Depurei isso com um amigo, eis como chegamos à solução para que todos com esse problema possam seguir:

Em primeiro lugar, no gerenciamento de faturamento, você pode ver que o custo é de US $ 0,01 por GB. Por isso, reflete os seguintes pontos da página de preços (que vão um pouco mais em detalhes):

• Instâncias do Amazon EC2, Amazon RDS, Amazon Redshift e Amazon ElastiCache ou interfaces de rede Elastic na mesma zona de disponibilidade
  • Usando um endereço IP público ou elástico
• Instâncias do Amazon EC2, Amazon RDS, Amazon Redshift e Amazon ElastiCache ou Interfaces de rede Elastic em outra zona de disponibilidade ou VPC emparelhado na mesma região da AWS

Em seguida, verifiquei uma explicação na AWS sobre Zonas e regiões de disponibilidade . O que eu tenho que pagar é definitivamente o tráfego que vem da mesma região ( us-east-1 no meu caso). Pode ser o tráfego passando de um AZ para outro AZ (já sabíamos antes) ou o tráfego usando um endereço IP público ou endereço IP Elástico dentro do mesmo AZ (também sabíamos de a outra questão de falha de servidor ). No entanto, parece agora que esta lista é realmente exaustiva.

Eu sabia que tinha:

• 6 máquinas EC2 em um cluster
• sem RDS
• não Redshift
• sem ElastiCache
• sem endereço IP elástico

PePC VPC

O VPC é um produto próprio, por isso vá para o VPC . De lá você pode ver quantos VPCs você tem. No meu caso, foi apenas um, então não é possível perscrutar nada. Mas você ainda pode ir para Peering Connections e ver se algo está definido lá.

Sub-redes

Da seção Subnet no VPC, também descobrimos algumas dicas importantes para mais depuração. Intervalos de IP das diferentes Zonas de disponibilidade em us-east-1 :

• 172.31.0.0/20 para us-east-1a
• 172.31.16.0/20 para us-east-1b
• 172.31.32.0/20 para us-east-1e
• 172.31.48.0/20 para us-east-1d

Como todas as minhas máquinas devem estar em us-east-1d , verifiquei isso. E, de fato, todos eles tinham IPs começando com 172.31.48 , 172.31.51 e 172.31.54 . Até agora tudo bem.

tcpdump

Isso finalmente nos ajudou a configurar os filtros corretos para o tcpdump. Agora sabendo com quais IPs eu deveria estar se comunicando para evitar custos (rede 172.31.48.0/20 apenas), configuramos um filtro para tcpdump . Isso ajudou a remover todo o barulho que me fez não ver a comunicação externa. Além disso, antes eu nem sabia que a comunicação com [something].ec2.internal poderia ser o problema, já que eu não sabia o suficiente sobre regiões, AZs e seus respectivos IPs.

Primeiro, criamos este filtro tcpdump:

tcpdump "not src net 172.31.48.0 mask 255.255.240.0" -i eth0

Isso deve mostrar todo o tráfego proveniente de qualquer lugar, exceto us-east-1d . Ele mostrou muito tráfego da minha conexão SSH, mas eu vi algo estranho voando - um endereço ec2.internal . Eles não deveriam ter sido todos filtrados, porque não mostramos mais o tráfego interno AZ?

IP ip-172-31-0-2.ec2.internal.domain > ip-172-31-51-15.ec2.internal.60851

Mas isso não é interno! É de outro AZ, ou seja, us-east-1a . Isso é do sistema DNS.

Eu estendi o filtro para verificar quantas dessas mensagens ocorrem:

sudo tcpdump "not src net 172.31.48.0 mask 255.255.240.0 and not src host $MY_HOSTNAME" -i eth0

Esperei 10 segundos, parei o registro e foram 16 respostas do DNS!

Próximos dias, ainda o mesmo problema

No entanto, depois de instalar o dnsmasq, nada mudou. Ainda vários GB de tráfego quando usei o cluster.

De dia para dia, removi mais tarefas do cluster e, finalmente, tentei um dia sem nenhum script de inicialização (ótimo!) e um dia com scripts de inicialização apenas + desligamento instantâneo (tráfego!).

A análise do script de inicialização revelou que apt-get update e apt-get install ... são o único componente que extrai arquivos enormes. Através de uma pesquisa no Google, aprendi que o Ubuntu tem um repositório de pacotes dentro da AWS. Isso também pode ser visto no sources.list :

http://us-east-1.ec2.archive.ubuntu.com/ubuntu/

Resolver o nome do host leva aos seguintes endereços IP:

us-east-1.ec2.archive.ubuntu.com.   30  IN  A   54.87.136.115
us-east-1.ec2.archive.ubuntu.com.   30  IN  A   54.205.195.154
us-east-1.ec2.archive.ubuntu.com.   30  IN  A   54.198.110.211
us-east-1.ec2.archive.ubuntu.com.   30  IN  A   54.144.108.75

Então, eu configurei um serviço de fluxo de logs e registrei o cluster durante o tempo de inicialização. Em seguida, baixei os arquivos de log e os executei através de um script python para somar todos os bytes transferidos para qualquer um desses quatro endereços IP. E o resultado corresponde ao meu tráfego. Eu tinha 1,5 GB de tráfego durante o último teste, tinha 3 clusters de 5 máquinas cada e, de acordo com o meu log de fluxo de log, cada máquina consultava cerca de 100 MB do repositório do Ubuntu.