## Échelle horizontale de GNS3 pour les laboratoires réseau gourmands en ressources
GNS3 vous permet de répartir des nœuds réseau gourmands en ressources sur plusieurs machines virtuelles en utilisant des serveurs externes. Cette approche est essentielle pour simuler de grandes topologies avec IOS-XRv9K, CSR1000v et NSO, où une seule VM atteint les limites de vCPU et de RAM. L'auteur décrit le passage d'un ordinateur portable (8 vCPU, 16 GB) à un cluster de VM basé sur Workstation, totalisant 64 vCPU et 200 GB de RAM.
Comparaison des simulateurs et cas d'usage
Parmi les outils de laboratoire réseau, EVE-NG, PNETLab, GNS3 et containerlab se distinguent. GNS3 excelle dans l'échelle horizontale : les nœuds sont répartis sur des VM sans configuration manuelle de cloud comme dans EVE-NG.
Cas d'usage principaux :
- Étudier des protocoles comme LISP, BGP et OSPF.
- Préparation aux examens avec des images spécifiques aux fournisseurs (IOS-XRv9K nécessite 4 vCPU par nœud).
- Preuve de concept avant déploiement.
Pour les labs Cisco SP (jusqu'à 50 nœuds), les simulateurs standards plantent avec 8+ IOS-XRv9K : gels, redémarrages. Calcul : 50 × 4 vCPU = 200 vCPU, impossible sur une seule machine.
Images gourmandes en ressources et optimisation par conteneurs
IOS-XRv9K (4 vCPU, RAM importante) peut être remplacé par IOS-XRd — une version du plan de contrôle conteneurisée (1 vCPU, 2 GB de RAM, démarrage en 30 s). Cela réduit la charge tout en conservant les fonctionnalités.
Matériel de l'auteur :
- Serveur SuperMicro X10DRL-i : 80 vCPU, 256 GB de RAM, 2 nœuds NUMA.
- OS : Windows 10 Pro (charge gaming), Workstation (limite de 32 vCPU/128 GB par VM).
- 3 VM GNS3 : isolation des IOS-XRv9K et CSR1000v.
Architecture GNS3 avec serveurs externes
GNS3 inclut Controller, GNS3 GUI/Web et Compute Nodes (VM avec Docker/QEMU). Compute Nodes sur le bureau, controller sur l'ordinateur portable, connectés via LAN.
Avantages :
- Routage automatique du trafic entre VM.
- Surveillance de la charge CPU/RAM sur les serveurs.
- Répartition des images sur les VM pour l'équilibre.
Limites de GNS3 2.2.46
Malgré les avantages, des problèmes surgissent :
- La topologie ne s'ouvre pas — supprimez le hub dans le fichier .gns3.
- ioll2-xe-17-12-01 ne démarre pas.
- Erreurs Calvados AUX dans XRv9K (non critiques).
- Sauvegarde des configs Docker nécessite une configuration de volumes.
- Changements d'interfaces : déconnectez les liens, modifiez, reconnectez.
Configuration étape par étape de l'échelle
- Planification : Assignez des VM par NUMA (au moins 2–3), ressources (64 vCPU, 200 GB). Isolez les types de nœuds.
- Préparation des VM GNS3 :
- Téléchargez l'OVA, définissez une IP statique (Network → config).
- Port (Configure → config).
- Ajout des serveurs : Édition → Préférences → Remote Servers → Ajouter (IP, nom, sans authentification pour LAN).
- Images : Assignez à des VM spécifiques (dupliquez pour la répartition).
- Topologie : GNS3 gère la connectivité automatiquement.
Surveillance : Servers Summary affiche la charge.
Enseignements clés
- Utilisez IOS-XRd pour le plan de contrôle : 1 vCPU/2 GB contre 4 vCPU pour XRv9K.
- Répartissez sur 3+ VM pour 40–60 nœuds sans plantage.
- Limite Workstation : 32 vCPU/128 GB par VM (NUMA).
- Volumes Docker pour configs persistantes.
- GNS3 > EVE-NG pour multi-VM sans clouds.
Cela permet d'échelonner les labs au niveau des examens, en contournant les limites matérielles sans louer de serveurs.
— Editorial Team
Aucun commentaire pour le moment.