Combien de cœurs OpenVPN nécessite-t-il ? Cela dépend du chemin

Deux serveurs ayant le même nombre de processeurs peuvent soutenir des débits très différents, car le nombre qui compte est celui des cœurs que le chemin de données actif peut réellement utiliser. Un démon en espace utilisateur qui traite les paquets d'un seul client est limité à un cœur, tandis qu'un chemin noyau déporté peut répartir ce travail. Aucune des deux affirmations ne dit ce qu'une machine donnée fera de votre trafic, c'est pourquoi la mesure précède le comptage des cœurs.

La comparaison ci-dessous porte sur l'endroit où les paquets sont traités, non sur le produit le plus rapide dans l'abstrait. Ce sont des questions différentes avec des réponses différentes.

Un cœur par flux sur le chemin en espace utilisateur

Dans une instance Community OpenVPN traditionnelle, le canal de données est traité en espace utilisateur, et une connexion chargée peut immobiliser un processeur alors que l'utilisation globale de la machine reste discrète. C'est pourquoi ajouter des cœurs à un hôte déjà saturé sur un seul flux ne change rien : l'ordonnanceur n'a aucun moyen de diviser ce travail. La structure d'un processus par client borne le transfert d'un client à la capacité d'un cœur, quel que soit le nombre total de cœurs. Lisez l'utilisation par cœur pendant un test plutôt que le chiffre agrégé, sinon le goulot d'étranglement ressemblera à une marge disponible.

Exécuter plusieurs instances de serveur sur un seul hôte répartit des clients distincts entre les processus. Cela ne parallélise pas une connexion existante et coûte des pools, des écouteurs et des décisions de routage séparés.

L'autre chemin : les paquets dans le noyau

Déport du canal de données déplace dans le noyau le traitement de paquets pris en charge et la cryptographie, où le travail peut utiliser plusieurs cœurs. Cela fait passer la question de capacité d'un cœur à la machine, mais uniquement pour les configurations que l'implémentation prend en charge : un module noyau compatible, un chiffrement de données éligible et une configuration sans les fonctions que le déport exclut. Installer un module n'est pas la même chose que l'utiliser, aussi confirmez le mode actif à partir du journal ou de la sortie d'état de la connexion elle-même. Une bannière de version prouve ce qui est disponible, pas ce qui tourne.

Le déport ne supprime ni l'authentification ni le canal de contrôle, et il ne transforme pas chaque déploiement en déploiement multicœur. C'est une accélération locale d'un chemin de données compatible, et les exigences varient selon la plateforme et la version.

Ce que la comparaison décide réellement

Le vrai choix se situe entre accepter un plafond par flux, répartir les clients entre instances et passer à une configuration de déport prise en charge. Chacun traite un problème différent, et choisir le mauvais coûte de l'argent sans faire bouger le chiffre. Le test qui compte est celui qui a la forme de l'usage réel du service.

Mesurez trois formes : un client avec un transfert, un client avec plusieurs flux, et plusieurs clients ensemble. Un total élevé sur la troisième ne prouve pas qu'un seul téléchargement peut l'atteindre, et un transfert unique lent ne prouve pas que le serveur a épuisé sa capacité globale. Les résultats répondent à des questions différentes et les deux valent la peine.

Seule la forme intermédiaire vous dit si la concurrence à l'intérieur d'un client aide, ce qui est généralement une propriété du transport et du chemin plutôt que du serveur. Seule la première vous donne le plafond qu'une application verra. Gardez la charge identique entre les exécutions pour que la comparaison ait un sens.

Mesurer pour que le chiffre ait un sens

Notez les versions du serveur et du client, le chemin de données actif, le chiffrement de données négocié, le sens du transfert, la taille des paquets, le nombre de flux et la durée. Surveillez l'activité par cœur ainsi que les pertes de paquets et de files aux deux extrémités, car l'interface du client lui-même, le réseau du fournisseur ou le service de destination peuvent devenir la limite en premier. Ne changez qu'une variable à la fois, car une exécution qui modifie chiffrement, compression, MTU et déport ensemble ne peut pas vous dire lequel comptait. Conservez pendant le test la politique d'accès que vous comptez réellement déployer, car un montage de laboratoire que personne n'exploitera ne prouve pas grand-chose.

Laissez ensuite de la marge pour le canal de contrôle, pour la renégociation et pour tout le reste de ce qui tourne sur l'hôte.

Rapportez ce que la configuration a soutenu dans la concurrence prévue, plutôt qu'un débit extrapolé du matériel d'un autre. Un chiffre assorti de ses conditions de test est utile ; une promesse sans elles est une conjecture qu'on vous citera plus tard.