Quantos núcleos o OpenVPN precisa? Depende do caminho

Dois servidores com o mesmo número de processadores podem sustentar vazões muito diferentes, porque o número que importa é quantos núcleos o caminho de dados ativo consegue realmente usar. Um único daemon no espaço do usuário que processa os pacotes de um cliente fica limitado a um núcleo, enquanto um caminho de kernel com offload pode distribuir esse trabalho. Nenhuma das duas afirmações diz o que uma máquina específica fará com o seu tráfego, por isso a medição vem antes da contagem de núcleos.

A comparação abaixo trata de onde os pacotes são processados, não de qual produto é mais rápido em abstrato. São perguntas diferentes com respostas diferentes.

Um núcleo por fluxo no caminho do espaço do usuário

Numa instância Community OpenVPN tradicional, o canal de dados é processado no espaço do usuário, e uma conexão ocupada pode prender um processador enquanto a utilização global da máquina continua discreta. Por isso acrescentar núcleos a um host já saturado num único fluxo não muda nada: o escalonador não tem como dividir esse trabalho. A estrutura de um processo por cliente limita a transferência de um cliente à capacidade de um núcleo, seja qual for o número total de núcleos. Leia a utilização por núcleo durante um teste em vez da cifra agregada, ou o gargalo vai parecer folga.

Executar várias instâncias de servidor num único host distribui clientes separados entre processos. Não paraleliza uma conexão existente e custa pools, ouvintes e decisões de roteamento separados.

O outro caminho: pacotes no kernel

Offload do canal de dados move para o kernel o processamento de pacotes suportado e a criptografia, onde o trabalho pode usar vários núcleos. Isso muda a pergunta de capacidade de um núcleo para a máquina, mas apenas para configurações que a implementação suporta: um módulo de kernel compatível, uma cifra de dados elegível e uma configuração sem os recursos que o offload exclui. Instalar um módulo não é o mesmo que usá-lo, então confirme o modo ativo a partir do log ou da saída de estado da própria conexão. Um banner de versão prova o que está disponível, não o que está em execução.

O offload não remove a autenticação nem o canal de controlo, e não transforma cada implantação numa de vários núcleos. É uma aceleração local de um caminho de dados compatível, e os requisitos variam conforme a plataforma e a versão.

O que a comparação realmente decide

A escolha real é entre aceitar um teto por fluxo, distribuir clientes por instâncias e passar para uma configuração de offload suportada. Cada uma resolve um problema diferente, e escolher a errada custa dinheiro sem mexer no número. O teste que importa é o que tem a forma de como o serviço é usado.

Meça três formas: um cliente com uma transferência, um cliente com vários fluxos e vários clientes em simultâneo. Um total alto na terceira não prova que um único download o possa alcançar, e uma transferência única lenta não prova que o servidor esgotou a capacidade total. Os resultados respondem a perguntas diferentes e ambos valem a pena.

Só a forma intermédia lhe diz se a concorrência dentro de um cliente ajuda, o que normalmente é uma propriedade do transporte e do caminho e não do servidor. Só a primeira diz o teto que uma única aplicação verá. Mantenha a carga idêntica entre execuções para que a comparação signifique algo.

Medir para que o número signifique algo

Registe as versões de servidor e cliente, o caminho de dados ativo, a cifra de dados negociada, o sentido da transferência, os tamanhos dos pacotes, o número de fluxos e a duração. Observe a atividade por núcleo e as perdas de pacotes e de filas nos dois extremos, porque a interface do próprio cliente, a rede do fornecedor ou o serviço de destino podem tornar-se o limite primeiro. Mude uma variável de cada vez, pois uma execução que altera cifra, compressão, MTU e offload em conjunto não lhe pode dizer qual contou. Mantenha durante o teste a política de acesso que realmente pretende implementar, porque uma montagem de laboratório que ninguém vai executar prova pouco.

Depois deixe margem para o canal de controlo, para a renegociação e para tudo o resto que corre no host.

Relate o que a configuração sustentou sob a concorrência pretendida, em vez de uma taxa extrapolada do hardware de outra pessoa. Um número com as suas condições de teste anexadas é útil; uma promessa sem elas é um palpite que lhe será citado de volta.