Ce que j'aurais aimé savoir avant de travailler avec SONiC NOS - Le point de vue d'un CCIE
Lorsque vous avez passé des années à maîtriser les systèmes d'exploitation de réseau traditionnels (Cisco IOS, NX-OS, Junos), le passage à une plateforme désagrégée comme le SONiC (Software for Open Networking in the Cloud) est une expérience déroutante. En tant que CCIE, je pensais avoir les compétences de base pour prendre en main n'importe quel système d'exploitation de réseau. SONiC m'a rendu humble. C'est une plateforme puissante, mais qui exige un état d'esprit et un ensemble de compétences très différents. Si vous êtes sur le point de commencer votre voyage SONiC, voici les compétences clés que j'aurais aimé développer au préalable.
1. Principes fondamentaux de Linux Au-delà de l'essentiel
SONiC est construit sur Linux, et je veux dire VRAIMENT construit sur Linux. Contrairement aux NOS traditionnels, où le système d'exploitation sous-jacent est caché, SONiC vous expose à tout - systemd, conteneurs, scripts bash, et plus encore. Les bases de Linux ne suffisent pas. Vous devez être à l'aise avec :
- Navigation dans le système de fichiers
- Lecture des journaux dans /var/log/
- Dépannage des services systemd (systemctl status, journalctl)
- Gestion des services conteneurisés via Docker (docker exec, docker logs)
Si vous n'avez jamais touché à une interface de programmation Linux en dehors d'activer SSH ou ping, vous serez vite perdu.
2. Comprendre l'architecture conteneurisée
SONiC est basé sur des microservices. Chaque fonction réseau (BGP, LLDP, relais DHCP) fonctionne dans son propre conteneur Docker. Cela signifie que :
- Les journaux sont spécifiques aux conteneurs.
- Les espaces de noms en réseau permettent d'isoler le trafic.
- Les défaillances peuvent être isolées dans un conteneur spécifique sans affecter le reste du système.
J'ai dû désapprendre mes instincts de "système d'exploitation monolithique", après tout, j'ai grandi avec Cisco IOS où tout est centralisé. Le dépannage est très différent lorsque les décisions de routage sont prises dans un conteneur et que les interfaces sont gérées dans un autre.
3. Travailler avec Redis et le modèle de base de données SONiC
SONiC utilise une base de données Redis comme intermédiaire entre la configuration, l'état et la couche d'abstraction matérielle sous-jacente. Il existe plusieurs bases de données logiques - CONFIG_DB, STATE_DB, APPL_DB - chacune servant un objectif distinct. Ce qu'il faut savoir :
- Comment interroger les entrées de la base de données (redis-cli -n keys *)
- Le schéma (aide sur les modèles SONiC YANG)
- Comment les processus swss consomment les données de Redis
J'aurais aimé prendre plus de temps pour comprendre le schéma de la base de données et le pipeline d'orchestration de SONiC, cela m'aurait évité de me gratter la tête.
4. Git et navigation dans le code source
SONiC est un logiciel libre. Lorsque quelque chose se casse ou ne se comporte pas comme prévu, il y a de fortes chances que vos recherches vous mènent vers des problèmes publics sur GitHub, vous pouvez même lire le code source, ou si vous êtes audacieux, construire/déboguer le système vous-même. Il est utile d'avoir une bonne connaissance de ce qui suit :
- Les bases de Git (clone, diff, branch)
- Lecture de code Python/C++ (en particulier dans swss, syncd, orchagent)
- Construction d'images via le système de construction SONiC
BTW, si vous recevez du support sur SONiC de la part d'un fabricant, d'un intégrateur ou d'un partenaire, vous n'aurez probablement jamais à faire ce qui précède, mais j'essaie toujours d'apprendre de nouvelles choses.
5. L'état d'esprit DevOps et l'automatisation
SONiC a été conçu à l'origine pour les opérateurs à l'échelle du nuage. La configuration manuelle est déconseillée. Adopter :
- Blocs de ressources Terraform
- Manuels Ansible
- Gestion de la configuration via config_db.json
- Gestion des images et ZTP
- Pipelines CI/CD pour les changements de réseau
Si vous continuez à éditer des configurations via l'interface de programmation ligne par ligne, c'est que vous vous y prenez mal.
Conclusion
SONiC n'est pas seulement un NOS - il s'agit en fait d'une plateforme qui permet d'exploiter les futures capacités du réseau. Il récompense les ingénieurs qui pensent comme des SRE et pénalise ceux qui s'accrochent aux flux de travail existants. J'ai beaucoup appris de mon expérience avec SONiC, mais si je pouvais revenir en arrière, je me préparerais davantage à Linux, aux conteneurs et à l'automatisation. SONiC est l'avenir des réseaux ouverts - il faut juste être prêt à passer au niveau supérieur quand on y arrive.
Josh Saul
Vice-président du marketing produit
Josh Saul est un pionnier des solutions de réseau open source depuis plus de 25 ans. En tant qu'architecte, il a construit des réseaux centraux pour GE, Pfizer et NBC Universal. En tant qu'ingénieur chez Cisco, Josh a conseillé des clients dans le secteur financier du Fortune 100 et a évangélisé les nouvelles technologies auprès des clients. Plus récemment, Josh a dirigé des équipes de marketing et de produits chez VMware (racheté par Broadcom), Cumulus Networks (racheté par Nvidia) et Apstra (racheté par Juniper).
