Utilisateurs ou débit ? Dimensionner un serveur VPN pour la charge réelle
Le nombre de comptes ne dimensionne pas une passerelle ; c’est le travail qui se chevauche qui le fait. Comparez transferts concurrents, CPU par cœur et files, puis écrivez la charge.
Dix comptes inactifs coûtent moins qu’une sauvegarde nocturne qui sature le tunnel, et un nombre d’utilisateurs ne peut pas montrer cette différence. Dimensionner un serveur VPN, c’est comparer deux nombres : la concurrence que vous portez réellement et la ressource qui s’épuise la première. La plupart des erreurs de capacité viennent du choix du premier nombre et de la mesure jamais faite du second. Faites les deux, dans cet ordre, et la décision matérielle cesse d’être une devinette.
Comparez le nombre de comptes à l’heure de pointe
Le nombre de comptes est une licence et une limite de support ; l’heure de pointe est une charge. Listez le travail qui se chevauche dans cette heure : appels, administration à distance, gros téléchargements, sauvegardes et les requêtes d’applications privées qui font attendre les gens. Puis indiquez, pour chaque élément, s’il traverse la passerelle et dans quel sens. Les appels sont symétriques et sensibles au délai, tandis qu’une sauvegarde est unidirectionnelle et tolère un démarrage lent : ils sollicitent donc des parties différentes du chemin.
Le sens décide quel lien compte. Une liaison montante domestique est rarement symétrique, et une agence qui télécharge toute la journée atteint sa limite descendante bien avant que la passerelle ne transpire. Notez le sens et la portée du tunnel à côté de chaque élément, car une passerelle qui ne porte que des destinations privées et une qui porte tout le trafic internet sont deux problèmes de dimensionnement différents.
Ajoutez la charge de fond comme sa propre ligne : mises à jour des clients, télémétrie et tout ce que l’hôte fait en plus de transmettre. Ces octets s’oublient facilement et la même interface les compte.
Trouvez la ressource qui s’épuise avant le lien
Le lien n’est qu’un candidat. Le travail cryptographique d’un seul tunnel peut immobiliser un cœur pendant que l’interface reste à moitié vide, et une file saturée peut rendre les appels inutilisables à un débit qui paraît médiocre sur un graphique. Une destination à une route lente peut aussi ressembler à une faiblesse de la passerelle depuis la place du client. Trois observations séparent ces cas, et aucune n’a besoin d’un test en rafale.
| 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 |
Mesurez avec un transfert que vous êtes autorisé à lancer, et ajoutez le travail concurrent par étapes plutôt que d’un coup. Lisez le débit soutenu et la réponse interactive ensemble, car un test de débit de pointe seul cache une session devenue inutilisable. Une passerelle qui atteint son débit maximal pendant que les appels se coupent n’a pas réussi le test.
Répétez ensuite l’exécution avec les charges optionnelles arrêtées. Une limite qui bouge quand la sauvegarde s’arrête n’a jamais été la limite de la passerelle.
Transformez la comparaison en un nombre que vous pouvez défendre
Choisissez la ressource épuisée et exprimez l’exigence dans ses unités : cœurs à un taux d’utilisation cible pendant l’heure de pointe, bits par seconde dans chaque sens, ou sessions concurrentes sous une limite de délai. Laissez de la marge pour les mises à jour, le diagnostic et la reprise, car un serveur assis sur son plafond mesuré n’a plus rien pour le travail qui le maintient en marche. Écrivez ensuite les nombres à côté de la configuration qui les a produits, y compris le nombre de clients et le test utilisé.
Le chiffre d’utilisateurs par cœur est le nombre le moins transférable de cet exercice, car il suppose un mélange de protocoles et un profil d’appareils que le site suivant ne partage pas. Gardez la mesure et abandonnez la formule. Quand quelqu’un demande de la capacité pour cinquante utilisateurs de plus, la réponse honnête est le profil d’heure de pointe de ces cinquante, pas une multiplication.
Enregistrez le temps de réponse autant que le débit. Une capacité qui ne préserve que le transfert en masse n’est pas une capacité pour les gens en appel, et la prochaine revue posera la question de la différence.
Choisissez entre monter en puissance et séparer le rôle
Quand la limite mesurée est un cœur, plus de cœurs à la même fréquence peuvent ne pas aider ; un cœur plus rapide ou un autre modèle de traitement le peut. Quand la limite est le CPU total, une instance plus grande est la solution directe. Quand la limite est le lien d’accès, aucun changement de serveur n’aide et la comparaison s’arrête chez le fournisseur. Séparer les rôles web et VPN sur des hôtes distincts achète l’isolation au prix d’une seconde surface d’administration.
Comparez ces options au nombre enregistré plutôt qu’entre elles. Un changement qui double une ressource qui n’était pas la contrainte est un coût sans bénéfice, et c’est l’enregistrement qui vous permet de le dire sans discussion. Remesurez après le changement avec la même charge, sinon vous avez remplacé une devinette par une autre.