Por que a instância do Amazon EC2 está excedendo seus limites de rede quando a utilização média é baixa?

8 minuto de leitura
0

Por que a instância do Amazon Elastic Compute Cloud (Amazon EC2) está excedendo seus limites de rede quando a utilização média é baixa?

Breve descrição

Você pode consultar as métricas de performance da rede em tempo real em instâncias compatíveis com redes avançadas por meio do Elastic Network Adapter (ENA). Essas métricas fornecem um número cumulativo de pacotes enfileirados ou descartados em cada interface da rede desde a última reinicialização do dispositivo. A seguir estão algumas das métricas do ENA:

  • bw_in_allowance_exceeded: o número de pacotes enfileirados ou descartados porque a largura de banda de entrada agregada excedeu o máximo para a instância.
  • bw_out_allowance_exceeded: o número de pacotes enfileirados ou descartados porque a largura de banda de saída agregada excedeu o máximo para a instância.
  • pps_allowance_exceeded: o número de pacotes enfileirados ou descartados porque o número de pacotes por segundo (PPS) em ambas as direções excedeu o máximo para a instância.

As especificações de performance da rede variam de acordo com o tipo de instância. Para ver as especificações, consulte Instâncias da geração atual. Em alguns casos, você pode ver pacotes enfileirados ou descartados, mesmo que a largura de banda média ou o PPS, como vistos no Amazon CloudWatch, sejam baixos. Por exemplo, as métricas NetworkIn, NetworkOut, NetworkPacketsIn ou NetworkPacketsOut no CloudWatch podem mostrar valores que não indicam que um limite foi atingido.

Resolução

Microbursts são a causa mais comum dos sintomas anteriores. Microbursts são breves picos na demanda seguidos por períodos de baixa ou nenhuma atividade. Esses bursts normalmente duram apenas segundos, milissegundos ou mesmo microssegundos. No caso de microbursts, as métricas do CloudWatch listadas na seção anterior não são suficientemente granulares para refleti-los.

Como as médias são calculadas

As métricas do EC2 no CloudWatch listadas na seção anterior são amostradas a cada um minuto. Essas métricas capturam o total de bytes ou pacotes transferidos nesse período. Essas amostras são então agregadas e publicadas no CloudWatch em períodos de cinco minutos. Cada estatística no período retorna um valor de amostra diferente:

  • Sum (Soma) é a soma de todos os valores de amostra.
  • SampleCount (Número de amostras) é o número de amostras agregadas (neste caso, cinco).
  • Minimum (Mínimo) é o valor da amostra com o menor número de bytes/pacote.
  • Average (Média) é o valor médio da amostra, calculado dividindo Sum (Soma) por SampleCount (Número de amostras).
  • Maximum (Máximo) é o valor de amostra com o maior número de bytes/pacote.

O throughput médio ou PPS pode ser calculado de duas maneiras:

  • Divida Sum (Soma) por Period (Período) (por exemplo, 300 segundos) para uma média simples de 5 minutos.
  • Divida o Maximum (Máximo) por 60 segundos, para uma média no minuto com maior atividade.

Como microbursts são refletidos nas métricas do CloudWatch

Veja a seguir um exemplo de microburst e como ele é refletido no CloudWatch:

  • A instância tem uma performance de largura de banda da rede de 10 Gbps (1,25 GB/s).
  • Em uma dada amostra (60 segundos), uma transferência de dados de saída de 20 GB usa toda a largura de banda disponível, fazendo com que bw_out_allowance_exceeded aumente. A transferência é concluída em cerca de 20 segundos e nenhum dado adicional é enviado posteriormente.
  • A instância permanece ociosa para as 4 amostras restantes (240 segundos).

Neste exemplo, o throughput médio em um período de cinco minutos é muito menor do que durante o microburst:

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

Mesmo que você calcule o throughput com base na amostra mais alta, a média ainda não refletirá o valor do throughput:

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

Monitorar microbursts

Para medir o throughput e o PPS em um nível mais granular, use as ferramentas do sistema operacional para monitorar as estatísticas da rede. Monitore as estatísticas da rede com mais frequência durante períodos de modelagem ou alta atividade.

Estes são exemplos de ferramentas do sistema operacional:

Linux

  • sar
  • nload
  • iftop
  • iptraf-ng

Windows

  • Monitor de performance

O agente do CloudWatch pode ser usado no Linux e no Windows para publicar essas métricas de rede no nível do sistema operacional no CloudWatch como métricas personalizadas. Essas métricas podem ser publicadas em pequenos intervalos, até de um segundo. Note que métricas de alta resolução (com um período inferior a 60 segundos) geram cobranças mais altas. Para obter mais informações sobre preços do CloudWatch, consulte os Preços do Amazon CloudWatch.

É uma prática recomendada monitorar as métricas de performance de rede fornecidas pelo ENA. A versão do driver deve ser maior ou igual a 2.2.10 (Linux) e 2.2.2 (Windows) para que você possa visualizar as métricas. Para obter mais informações, consulte as páginas relevantes para Linux e Windows.

O agente do CloudWatch também pode publicar métricas do ENA. Para obter instruções sobre como publicar métricas do ENA para Linux, consulte Coletar métricas de performance de rede. Para o Windows, as métricas do ENA estão disponíveis no Monitor de Desempenho, e o agente do CloudWatch pode ser configurado para publicar qualquer métrica disponível ali.

Evitar microbursts

Para evitar microbursts, o tráfego precisa ser temporizado nos remetentes para não exceder o máximo throughput ou taxa de pacotes. Isso torna os microbursts difíceis de evitar. Temporizar o tráfego nos remetentes geralmente requer alterações no nível da aplicação. Dependendo de como essa alteração é implementada, pode ser necessário que o sistema operacional seja compatível com temporização de tráfego e que esse recurso esteja disponível e ativado nos remetentes. Isso pode nem sempre ser possível ou prático. Microbursting também pode acontecer porque muitas conexões enviam pacotes em um curto período. Quando isso acontece, temporizar os remetentes individuais não adianta.

Por esses motivos, é uma prática recomendada monitorar as métricas do ENA. Se os limites estiverem sendo atingidos com frequência ou se houver evidência de que isso esteja afetando as aplicações, faça o seguinte:

  • Aumente a escala verticalmente: mude para uma instância maior. Instâncias maiores geralmente têm cotas mais altas. Instâncias otimizadas para rede (as que têm um “n”, como C5n) têm cotas mais altas do que as respectivas contrapartes não otimizadas para rede.
  • Aumente a escala horizontalmente: distribua o tráfego entre várias instâncias para reduzir o tráfego e a contenção em instâncias individuais.

No Linux, além das opções anteriores, há possíveis opções de mitigação para usuários avançados. Você pode implementar essas opções sozinhas ou combinadas. É uma prática recomendada avaliar as mitigações em um ambiente de teste para verificar se elas reduzem ou eliminam a modelagem de tráfego sem afetar negativamente a workload.

  • SO_MAX_PACING_RATE: essa opção de soquete pode ser passada de uma aplicação para um chamada do sistema setsockopt para especificar uma taxa de temporização máxima (bytes por segundo). Assim, o kernel do Linux temporiza o tráfego desse soquete para não exceder o limite. Essa opção requer o seguinte:
  • Disciplinas de enfileiramento (qdiscs): os qdiscs são responsáveis pelo agendamento de pacotes e pela modelagem opcional. Alguns qdiscs, como fq, ajudam a suavizar bursts de tráfego de fluxos individuais. Para obter mais informações, consulte a página do manual Traffic Control (TC) (Controle de tráfego).
  • Filas de transmissão rasas (Tx): em alguns cenários, filas de Tx rasas ajudam a reduzir a modelagem de PPS. Isso pode ser alcançado de duas maneiras:
  • Limites de fila em bytes (BQL): BQL limita dinamicamente a quantidade de bytes em trânsito nas filas de Tx. BQL é ativado por padrão nas versões do driver do ENA fornecidas com o kernel Linux (as que terminam com um “K”). Para versões do driver do ENA do GitHub (as que terminam com um “g”), BQL está disponível a partir da versão v2.6.1g e é desativado por padrão. Você pode ativar BQL usando o parâmetro enable_bql do módulo do ENA.
  • Comprimento reduzido da fila de Tx: reduza o comprimento da fila de Tx do padrão de 1.024 pacotes para uma quantidade menor (mínimo de 256). Você pode alterar esse comprimento usando a ferramenta ethtool.

Informações relacionadas

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos