Ao operar uma grande rede global, assegurar uma boa conetividade e desempenho entre sistemas que comunicam através da Internet pública é fundamental para garantir uma experiência positiva do utilizador. Dada a natureza complexa e mais eficiente da Internet, até mesmo os links mais bem aprovisionados nos fornecedores mais confiáveis às vezes têm problemas.
Há uma série de estratégias para monitorar esses links, incluindo medição ativa , que gera tráfego especificamente para medição, e medição passiva , que monitora o tráfego existente. neste artigo, descrevemos uma abordagem passiva que faz uso do nosso sistema de amostragem de socket xTCP para monitorar passivamente muitos desses links de que a nossa rede depende.
Para aproveitar ao máximo os dados do xTCP, desenvolvemos ainda mais uma abordagem para processar estes dados que aborda alguns dos desafios associados ao monitoramento da Internet. Em particular, introduzimos um conceito a que chamamos a relação de retransmissão , que fornece uma medida relativa da gravidade das retransmissões observadas entre os sites da rede de distribuição de conteúdo (CDN). Demonstramos que a taxa de retransmissão acima de certos níveis corresponde a degradações na taxa de transferência, impactando diretamente o desempenho percebido pelo utilizador, tornando-a uma excelente base para a automação de rede que nos permite trabalhar em torno das degradações do desempenho da rede.
Fundo
Um fluxo de trabalho comum na CDN envolve um ponto de presença (pop) que se encontra com outro para algum conteúdo, por exemplo, para buscar um pedaço de conteúdo para armazenar em cache. Frequentemente, estas interações são feitas em resposta direta a um pedido do cliente, o que significa que o pedido a jusante pode estar à espera que esta transferência seja concluída. Geralmente, os pedidos em si podem ser bastante pequenos, por ordem de alguns kilobytes. As respostas podem ser muito variáveis em tamanho, desde kilobytes a muitos megabytes.
Figura 1: O fluxo de pedidos envia pedidos pequenos (ordem de KBs) e recebe respostas potencialmente grandes (potencialmente megabytes).
Para monitorar a integridade das conexões entre pontos de presença, podemos usar a nossa ferramenta de monitoramento de sockets, xtcp, para provar o estado atual de todos os sockets abertos nos nossos servidores de borda. Enquanto isso fornece visibilidade crítica em nossos soquetes voltados para o cliente, esses dados de soquete também nos dão uma visão dos dados entre os POPs.
No entanto, medir estes dados não é sem alguns desafios. Primeiro, o xTCP fornece uma amostra pontual de diferentes conexões. Isso significa que podemos pegar muitas conexões em muitos pontos diferentes da transmissão. Portanto, qualquer avaliação que fizermos terá que considerar a distribuição mais ampla de comportamentos, em vez de quaisquer valores únicos.
Em seguida, precisamos de garantir que estamos a monitorizar a direção correta. Enquanto tanto o pop que gerou a solicitação (Pop A no diagrama acima) quanto o pop que recebeu a solicitação e deve responder a ela (pop B acima) têm informações de soquete, suas cargas de trabalho assimétricas significam que esperamos ver comportamento diferente: A maioria dos pacotes enviados pelo cliente serão pacotes de controle (a solicitação inicial, pacotes de confirmação subsequentes), enquanto a maioria dos pacotes enviados pelo servidor serão pacotes de dados, que são mais prováveis.
Como resultado, se houver congestionamento ou outros problemas ao longo do caminho, os pacotes que transportam dados, e portanto ocupam mais espaço na fila, são mais propensos a encontrar perda de pacotes e sofrer retransmissões, por exemplo, como resultado de quedas de fila em um roteador ocupado. Para demonstrar isso, consideramos a distribuição das taxas de retransmissão de pacotes (computadas como a proporção de pacotes retransmitidos totais divididos pelo número total de segmentos de dados enviados, menos retransmissões) vistas nos fluxos de solicitação e resposta entre um par de POPs por um período de 10 minutos.
Figura 2: O tráfego de resposta encontra mais retransmissões, provavelmente devido ao seu tamanho maior.
Aqui, vemos que os sockets de pedido do cliente quase não têm retransmissões durante este período de tempo. Por outro lado, as respostas mostram quase 85% dos sockets com retransmissões não-zero, no entanto, notamos que a taxa de retransmissão está bem abaixo de 1% para a grande maioria das conexões. Sem surpresa, observamos comportamento semelhante em quase todos os pares de POPs com retransmissões não-zero durante o período de teste. Por isso, concentramo-nos nos fluxos de resposta carregados de dados. Uma vez que estamos preocupados em atender as solicitações aos pedidos originais, referimo-nos a estes como fluxos de entrada.
O nosso desafio final vem de algumas complexidades gerais em torno das retransmissões, e da dificuldade de usá-las como um sinal para a degradação do desempenho. Na verdade, as retransmissões podem ocorrer regularmente sem indicar um problema específico, pois elas simplesmente refletem o estado do remetente e o número de vezes que um pacote foi reenviado. Estes podem, em última análise, ser o resultado de outro comportamento complexo de protocolos além da perda (por exemplo, perda de cauda). Somando a complexidade, observamos que muitas tomadas nunca observam retransmissões. Isto significa que os sumários ingénuos (por exemplo, considerando a mediana) podem resultar em sumários muito conservadores da taxa de retransmissão, e sumários distorcidos (por exemplo, percentis 95 ou 99) podem capturar em grande parte comportamentos que não são prejudiciais à população em geral.
Relação de retransmissão
A fim de ajudar a simplificar os impactos destes desafios, consideramos uma métrica composta a que chamamos a razão de retransmissão. Inspirada na relação HD do Meta , que visa quantificar a fração de clientes que são capazes de transmitir vídeo HD, esta medida esforça-se por descrever a fração de tomadas que estão a experimentar um nível pouco saudável de retransmissões. Uma vez que as retransmissões não-zero são por vezes esperadas, definimos a relação de retransmissão da seguinte forma:
Criticamente, este valor é particularmente fácil de calcular com dados disponibilizados via xtcp. Na nossa experiência operacional, descobrimos que os valores da razão de retransmissão são geralmente pequenos em ligações saudáveis, evitando os desafios quase sempre zero presentes nas medições da taxa de retransmissão bruta.
Também descobrimos que a medição é sensível, muitas vezes gerando alertas antes de outros sistemas de monitoramento de desempenho. Isto torna-a especialmente valiosa quando se diagnostica rapidamente as degradações da rede, que muitas vezes começam com pequenos problemas que eventualmente se tornam problemas maiores.
A validar a métrica
Para demonstrar que a relação de retransmissão está diretamente correlacionada com o desempenho da aplicação, demonstramos a sua eficácia considerando duas medições. Primeiro, mostramos que durante tempos de alta taxa de retransmissão, a aplicação do cliente (o solicitante) sofre menor rendimento do que durante tempos com baixa ou zero taxa de retransmissão. Segundo, mostramos que a alta taxa de retransmissão muitas vezes corresponde a degradações em outros sinais de rede, em particular, sondas ICMP entre POPs.
Para explorar os impactos no desempenho da aplicação, retomamos medidas explicitamente da camada de aplicação. Em particular, consideramos os rendimentos medidos no pop do cliente, uma vez que estes representam a taxa de entrega funcional alcançada no processo de envio de dados. Para compreender o impactos dos eventos de retransmissão, realizamos o seguinte estudo sobre um par de POPs ao longo de uma semana, durante o qual ocorreu um problema significativo no fornecedor.
Primeiro, consideramos todos os períodos em que ocorreu um evento de retransmissão. Definimos um evento de retransmissão como qualquer período de tempo em que a relação de retransmissão entre um par de pops se encontra dentro de um determinado intervalo durante pelo menos dez minutos consecutivos. Embora notemos que isso exclui eventos de curta duração, ele fornece uma visão sobre o comportamento de eventos mais longos. Para cada evento de retransmissão, recolhemos os valores de taxa de transferência correspondentes durante o evento. Como controlo, recolhemos dados durante o mesmo período de tempo que o evento, mas com três horas de antecedência. Isto dá-nos dois conjuntos de medições de rendimento: Os eventos de retransmissão durante o tempo e o normal, feitos durante tempos sem retransmissão. Em seguida, normalizamos as medições “durante” pelo rendimento médio alcançado entre os POPs durante o tempo normal. Para os nossos limiares, consideramos quatro intervalos: Maior que 0 mas menor que 25%, maior que 25 mas menor que 50%, maior que 50 mas menor que 75%, e finalmente maior que 75%.
Figura 3: A taxa de transferência relativa em comparação com os períodos de não retransmissão, observados durante cada evento de retransmissão.
A figura acima mostra a distribuição dos rendimentos relativos observados durante o período de medição. Primeiro, vemos que, mesmo no intervalo mais baixo, 60% das transações alcançaram um rendimento inferior ao da mediana. À medida que consideramos maiores taxas de retransmissão, a taxa de transferência continua a cair, com maior taxa de retransmissão correspondente a menor taxa de transferência, e o pior caso resulta em uma diminuição mediana relativa de mais de uma ordem de magnitude. Estas medições deixam claro que a taxa de retransmissão capta com êxito o fraco desempenho dos fluxos afetados.
Em seguida, voltamos para a forma como estes eventos se correlacionam com as nossas medidas ICMP ativas entre os POPs. Aqui, consideramos o comportamento de alguns de nossos monitoramentos ativos, que realizam sonoamentos regulares de ICMP entre POPs, para medir qualquer perda ou alteração nos padrões de atraso. Para esta análise, usamos novamente os eventos extraídos da nossa comparação de taxa de transferência. Desta vez, porém, olhamos para a perda medida do ICMP por períodos de tempo de cada limiar, onde, neste caso, normal, não se observou perda. Notamos que as limitações na nossa sondagem ICMP resultam numa granularidade de perda de 2% para estas medições em particular.
Figura 4: A perda observada de ICMP em cada período de tempo. A maior relação de retransmissão corresponde a uma maior perda.
Aqui, vemos que os limiares mais baixos raramente apresentam qualquer perda, com 90% das medições a falhar em detetar alguma. Em contraste, no limiar de .75, 80% das medições observaram perda, e observaram perda média relativamente alta de 4%. Criticamente, observamos níveis em que a taxa de retransmissão correspondia a impactos significativos na taxa de transferência (por exemplo, 0,25) resultam em pouca perda nas métricas do ICMP. Estes resultados reiteram a importância de medir o desempenho do caminho para além das simples sondas ICMP, e destaca a capacidade do rácio de retransmissão de oferecer uma visão diferenciada do desempenho dos fluxos reais através da Internet.
Conclusões e além
Neste post, demonstramos o valor da taxa de retransmissão, uma métrica resumida conveniente que pode ser facilmente calculada com dados disponíveis também a partir dos dados do socket xTCP. Mostrámos ainda que fornece uma visão clara dos casos em que o desempenho da aplicação é afetado e as intervenções da rede são necessárias.
A taxa de retransmissão tornou-se uma parte fundamental do nosso processo de monitorização, fornecendo uma visão clara do desempenho do sistema, sem a necessidade de processar registos de aplicações maiores e mais inflexíveis ou depender de sondas ICMP que não conseguem captar alguns impactos.
O nosso trabalho contínuo é explorar como a métrica pode ser feita o mais sensível possível para fornecer um alerta precoce às degradações, ao mesmo tempo que fornece uma entrada adequada para sistemas de automação mais complexos.
Um agradecimento especial às equipas de Engenharia de Arquitetura e Confiabilidade de Rede no seu apoio a este trabalho!
Para os investigadores interessados em saber mais sobre o Edgio Labs e os projetos avançados, ou interessados em explorar trabalhos colaborativos sobre qualquer um dos tópicos descritos acima, contacte a equipa através do endereço research@edg.io.
