Defina um orçamento de atraso para o tráfego em tempo real por VPN
Comece pelo prazo que a aplicação precisa cumprir e, em seguida, meça o atraso unidirecional e o jitter em condições declaradas. Uma média sem limite de pacotes atrasados não prova nada.
As queixas sobre VPN em tempo real precisam de um prazo contra o qual falhar, e «baixa latência» não é um prazo. Decida o que a conversa ou a sessão remota precisa entregar e, em seguida, meça o caminho contra esse requisito em condições declaradas. Sem um limite de pacotes atrasados, qualquer resultado é discutível. A distribuição abaixo é uma decisão de projeto, e existe para que a medição tenha algo a responder.
Escreva o prazo antes de tocar numa sonda
O prazo vem da aplicação e dos seus utilizadores, não da página de marketing de um fornecedor. Uma chamada de voz ao vivo, uma sessão de ambiente de trabalho remoto e uma cópia de segurança noturna toleram tempos de espera completamente diferentes, e a falha que importa costuma ser a cauda e não a mediana. Escreva o número junto com a carga de trabalho a que pertence.
Depois reparta-o. A captura e a pacotização consomem parte do orçamento, a ligação de acesso e o túnel outra parte, o buffer de des-jitter do recetor retém pacotes de propósito e o processamento da aplicação fica com o resto. Dar nome a essas etapas mantém a cifra do túnel em proporção, em vez de a tornar o suspeito predefinido de cada pacote lento.
Por fim, defina o contrato de medição em quatro linhas: extremos e direção, forma do tráfego, condições durante a execução e o resultado que vai reportar. Uma amostra de um domingo calmo e uma de uma terça-feira carregada respondem a perguntas diferentes, por isso indique qual recolheu. Se não conseguir preencher as quatro linhas, a execução não está pronta para começar. Essa lista de verificação é também o que torna dois relatórios comparáveis meses depois, quando já ninguém se lembra do que mais a ligação transportava.
Reparta o orçamento por cada etapa
A tabela é uma ajuda de planeamento, não dados recolhidos. Preencha o proprietário de cada linha antes da primeira sonda, porque o proprietário é quem liga quando essa etapa excede a sua parte.
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
Duas linhas costumam surpreender as pessoas. O buffer do recetor não é um defeito quando acrescenta atraso, porque está a fazer o trabalho para o qual foi configurado. E a parte do túnel é muitas vezes menor do que a fila à sua frente, sobretudo numa ligação de subida que se satura durante os carregamentos.
Quando uma etapa não tem proprietário, o orçamento é ficção. Atribua um antes de medir, ou vai passar a reunião seguinte a discutir qual número está errado.
Meça o atraso unidirecional com um relógio honesto
O atraso unidirecional é o número com que o prazo se importa, e precisa de relógios sincronizados nas duas pontas. A métrica de atraso unidirecional exige que reporte o método de sincronização, a resolução e o desvio estimado ao lado do resultado. Dois anfitriões não sincronizados podem produzir um número muito preciso para a grandeza errada.
Capture algumas centenas de pacotes em vez de uma mão-cheia e registe o estado do relógio ao mesmo tempo:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3
O tempo de ida e volta é uma medição separada, não dois valores unidirecionais somados. Dividir um RTT ao meio assume caminhos simétricos e filas simétricas, e um túnel sobre uma ligação móvel de subida quebra ambas as suposições com frequência. Reporte o RTT como RTT e mantenha-o fora do orçamento unidirecional.
Reporte a cauda e os pacotes atrasados
Resuma a distribuição: mediana, percentil 95 e 99, pior caso, perda e o número de pacotes que chegaram mais tarde do que o prazo permite. A média é o menos útil desses números para uma carga de trabalho em tempo real, porque uma média suave pode esconder uma cauda que arruína cada terceira chamada.
A variação do atraso alimenta diretamente o buffer do recetor. Mais buffer esconde a variação e acrescenta espera, por isso um fluxo pode parecer estável enquanto excede o seu prazo. Escolha uma formulação da variação, indique o intervalo sobre o qual mediu e mantenha-a consistente entre execuções.
Repita a execução com tráfego cruzado representativo. Um caminho que cumpre o orçamento quando está inativo e o falha durante uma janela de cópia de segurança disse-lhe algo útil sobre agendamento, que nenhuma medição silenciosa isolada revelaria. Registe as condições ao lado do resultado, porque o próximo engenheiro, caso contrário, comparará duas amostras que nunca foram comparáveis.
Aceite o projeto quando a cauda medida couber no orçamento sob a carga de trabalho que realmente executa, e rejeite-o nomeando no relatório a etapa que excedeu.