Utilizadores ou débito? Dimensionar um servidor VPN para a carga real
O número de contas não dimensiona uma Gateway; é o trabalho sobreposto que o faz. Compare transferências simultâneas, CPU por núcleo e filas, e depois registe a carga.
Dez contas inativas custam menos do que uma cópia de segurança noturna que satura o túnel, e um número de utilizadores não consegue mostrar essa diferença. Dimensionar um servidor VPN é uma comparação entre dois números: a simultaneidade que suporta realmente e o recurso que se esgota primeiro. A maioria dos erros de capacidade nasce de escolher o primeiro número e nunca medir o segundo. Faça as duas coisas, por essa ordem, e a decisão de hardware deixa de ser um palpite.
Compare o número de contas com a hora de ponta
O número de contas é uma licença e um limite de suporte; a hora de ponta é uma carga. Enumere o trabalho que se sobrepõe nessa hora: chamadas, administração remota, transferências grandes, cópias de segurança e os pedidos de aplicações privadas que deixam as pessoas à espera. Depois marque, para cada item, se atravessa a Gateway e em que direção. As chamadas são simétricas e sensíveis ao atraso, enquanto uma cópia de segurança é unidirecional e tolera um arranque lento, por isso sobrecarregam partes diferentes do caminho.
A direção decide qual ligação importa. Uma ligação de subida doméstica raramente é simétrica, e uma sucursal que transfere durante todo o dia atinge o seu limite de descida muito antes de a Gateway transpirar. Escreva a direção e o âmbito do túnel ao lado de cada item, porque uma Gateway que só transporta destinos privados e outra que transporta todo o tráfego da internet são dois problemas de dimensionamento diferentes.
Acrescente a carga de fundo como linha própria: atualizações de clientes, telemetria e tudo o que o anfitrião faz além de reencaminhar. Esses bytes esquecem-se com facilidade e são contados pela mesma interface.
Encontre o recurso que se esgota antes da ligação
A ligação é apenas um candidato. O trabalho criptográfico de um único túnel pode ocupar um núcleo enquanto a interface fica meio vazia, e uma fila saturada pode tornar as chamadas inutilizáveis a um débito que parece medíocre num gráfico. Um destino a uma rota lenta de distância também pode parecer fraqueza da Gateway do lugar do cliente. Três observações separam estes casos, e nenhuma precisa de um teste de rajada.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
Meça com uma transferência que lhe seja permitido executar, e acrescente o trabalho simultâneo por passos em vez de tudo de uma vez. Leia a taxa sustentada e a resposta interativa em conjunto, porque um teste só de pico esconde uma sessão que se tornou inutilizável. Uma Gateway que atinge o seu débito máximo enquanto as chamadas se cortam não passou no teste.
Depois repita a execução com as cargas opcionais paradas. Um limite que se desloca quando a cópia de segurança para nunca foi o limite da Gateway.
Transforme a comparação num número que possa defender
Escolha o recurso que se esgotou e exprima o requisito nas suas unidades: núcleos a uma utilização alvo durante a hora de ponta, bits por segundo em cada direção, ou sessões simultâneas sob um limite de atraso. Deixe margem para atualizações, diagnóstico e recuperação, porque um servidor sentado no seu teto medido não tem nada para o trabalho que o mantém em funcionamento. Depois escreva os números ao lado da configuração que os produziu, incluindo o número de clientes e o teste utilizado.
O número de utilizadores por núcleo é o menos transportável deste exercício, porque assume uma mistura de protocolos e um perfil de dispositivos que o sítio seguinte não partilha. Guarde a medição e deite fora a fórmula. Quando alguém pede capacidade para mais cinquenta utilizadores, a resposta honesta é o perfil de hora de ponta desses cinquenta, não uma multiplicação.
Registe o tempo de resposta além do débito. Uma capacidade que só preserva a transferência em massa não é capacidade para as pessoas em chamadas, e a próxima revisão perguntará pela diferença.
Escolha entre escalar verticalmente e separar o papel
Quando o limite medido é um núcleo, mais núcleos à mesma velocidade podem não ajudar; um núcleo mais rápido ou um modelo de trabalhadores diferente pode. Quando o limite é o CPU agregado, uma instância maior é a solução direta. Quando o limite é a ligação de acesso, nenhuma alteração de servidor ajuda e a comparação termina no fornecedor. Separar os papéis web e VPN em anfitriões distintos compra isolamento ao preço de uma segunda superfície de gestão.
Compare essas opções com o número registado e não entre si. Uma alteração que duplica um recurso que não era a restrição é custo sem benefício, e o registo é o que lhe permite dizê-lo sem discussão. Meça novamente depois da alteração com a mesma carga, ou substituiu um palpite por outro.