Carga do servidor VPN explicada: utilizadores, CPU ou uplink?

Um gateway com carga de 0.4 ainda pode arrastar-se para cada utilizador atrás dele. A carga média conta tarefas executáveis ou presas num sono ininterrupto, e num servidor de quatro núcleos basta um processo saturado para a empurrar para perto de 1.0 enquanto três núcleos ficam ociosos. Ler esse número como margem é o erro mais comum na escolha de um endpoint. O que realmente limita um túnel é, normalmente, uma de quatro coisas: um núcleo ocupado, o uplink, a fila à sua frente ou uma política por sessão que ninguém documentou.

A carga média conta tarefas, não caudal

O kernel recolhe amostras da fila de execução e do número de tarefas à espera de entrada e saída, e depois suaviza ambos ao longo de um, cinco e quinze minutos. Nada nessa definição menciona bytes, pacotes ou túneis. Um servidor com o armazenamento bloqueado pode reportar carga alta com quase nenhum tráfego, e um servidor que empurra um gigabit por um caminho de dados do kernel pode reportar uma carga confortável.

Correlacionar a carga com o desempenho do túnel exige, por isso, uma visão por núcleo. Se um núcleo estiver saturado, a percentagem agregada num painel continuará a parecer boa:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

O terceiro comando é o que mais importa em servidores VPN. O processamento de pacotes no espaço de utilizador no OpenVPN 2.x é em grande parte serializado por processo, pelo que um único thread ocupado pode tornar-se o teto enquanto o painel reporta abundante capacidade ociosa. Se um thread ocupa a maior parte de um núcleo durante o seu período lento, o servidor não está subdimensionado no conjunto; está limitado na dimensão que por acaso importa.

Repare também no momento. As médias de quinze minutos escondem o pico que estragou uma chamada, por isso uma captura de ecrã tirada depois da queixa é prova fraca. Recolha amostras durante o problema e guarde a marca temporal com a saída.

O uplink e a fila à sua frente

Os contadores da interface respondem à pergunta da largura de banda que os números de CPU não conseguem. Também separam capacidade de perda, que são falhas diferentes com correções diferentes:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Uma ligação próxima da sua taxa atribuída durante o teste é a explicação, e nenhuma quantidade de CPU livre a muda. A linha qdisc acrescenta o detalhe que importa para o tráfego interativo: o atraso e as perdas dizem-lhe se os pacotes esperam numa fila antes de sair. Uma fila que enche sob um carregamento grande produz exatamente o sintoma que as pessoas atribuem ao servidor remoto, ou seja, chamadas lentas numa ligação que continua a ter bons resultados nos testes.

Os contadores de retransmissão apanham o caso em que os pacotes saem mas nunca chegam limpos. Se as retransmissões sobem durante a janela lenta e a interface está longe da capacidade, o problema está no caminho e não no servidor, e mudar para outro endpoint na mesma cidade não ajudará.

O número de sessões descreve a procura, não a margem

Cada diretório público mostra um certo número de utilizadores ligados, e quase nenhum diz o que esses utilizadores estão a fazer. Vinte sessões com trabalho interativo e quatro sessões a descarregar ficheiros grandes produzem cargas muito diferentes no mesmo hardware. O segundo padrão é invisível num número de utilizadores, e é ele que estraga uma noite. Por isso, um número de sessões lê-se melhor como uma pista sobre a procura, nunca como uma afirmação sobre capacidade livre.

Num servidor que controla, o ficheiro de estado dá a dimensão que falta. O OpenVPN escreve instantâneos periódicos que incluem contadores de bytes por cliente, e isso basta para ver se uma única sessão é responsável por todo o uplink:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Duas amostras separadas por dez segundos transformam essas contagens acumuladas numa taxa por cliente. É essa a medição que um número de utilizadores substitui, e é também assim que descobre que um único cliente mal configurado satura a ligação todas as noites à mesma hora.

Os limites por sessão escondem-se na política

Um servidor pode estar ocioso e mesmo assim recusar dar-lhe largura de banda. Os limites de taxa, os tetos de largura de banda por cliente e a modelação de tráfego são frequentemente aplicados por nome comum ou por pool, pelo que dois utilizadores no mesmo gateway podem obter resultados muito diferentes. O mecanismo não é subtil, mas é invisível do exterior porque o túnel sobe normalmente nos dois casos.

Procure a modelação na interface do túnel e não na física. Verifique se o limite segue o utilizador, o certificado ou o pool de endereços. Se a sua conta de teste cair no pool sem teto, vai concluir que o servidor está bem e que o utilizador que se queixa está errado. Essa conclusão é pior do que nenhuma, porque fecha o pedido.

Compare dois endpoints com uma única tarefa fixa

A experiência do lado do cliente ainda vale a pena, mas só se as variáveis estiverem fixas. Use o mesmo dispositivo, a mesma rede de acesso, o mesmo protocolo e o mesmo ficheiro de destino, e depois repita contra um segundo endpoint a uma distância semelhante. Tudo o que muda entre execuções, incluindo a hora do dia, contamina o resultado.

Registe as falhas com o mesmo cuidado que os êxitos. Uma série em que três endpoints funcionam e um expira é mais informativa do que quatro números de velocidade, porque aponta para um problema de caminho ou de política e não de capacidade. Execute cada caso pelo menos duas vezes; uma única amostra lenta não prova nada numa rede partilhada.

Por fim, guarde os números que reuniu juntamente com a afirmação que sustentam. "Este endpoint concluiu a transferência na mesma janela em que o outro ficou preso" é defensável, enquanto "este endpoint é mais rápido" convida a uma discussão que não pode ganhar com uma pontuação de página inicial. O manual do OpenVPN 2.6 documenta o ficheiro de estado e as opções de modelação se precisar das diretivas exatas do lado do servidor.