Pourquoi SONiC révolutionne l'exploitation des réseaux modernes
En tant qu'ingénieur réseau ayant passé des années dans les tranchées avec divers systèmes d'exploitation de réseau, j'ai pu constater de première main comment SONiC (Software for Open Networking in the Cloud) a changé la donne dans le domaine des réseaux de centres de données modernes. Après avoir obtenu mon CCIE et travaillé sur des réseaux d'entreprise de toutes tailles, j'ai pu apprécier ce qui différencie vraiment SONiC des NOS traditionnels et propriétaires. Aujourd'hui, je souhaite partager trois avantages majeurs qui rendent SONiC particulièrement intéressant pour les organisations tournées vers l'avenir.
Conteneurisation : Briser le moule monolithique
Les systèmes d'exploitation de réseau traditionnels ont toujours été des bêtes monolithiques - des composants étroitement couplés et interdépendants qui doivent être mis à niveau ensemble, ce qui crée des maux de tête opérationnels et augmente les domaines de défaillance. SONiC rompt fondamentalement avec ce modèle grâce à son architecture conteneurisée.
Chaque fonction réseau de SONiC fonctionne dans son propre conteneur, ce qui permet une véritable séparation entre les processus. Cette architecture signifie que le démon du protocole de routage, l'interface d'abstraction du commutateur (SAI) et les services de gestion sont tous isolés les uns des autres. Lorsque nous avons besoin de corriger BGP, nous pouvons mettre à jour uniquement ce conteneur sans perturber les autres services ou nécessiter un rechargement complet du système.
D'après mon expérience du déploiement de SONiC dans des environnements de production, cette conteneurisation a considérablement amélioré notre capacité à maintenir la stabilité du réseau. Par exemple, lorsqu'un bogue a été découvert dans notre implémentation OSPF, nous avons été en mesure de revenir à une version antérieure uniquement pour ce conteneur spécifique, tout en laissant tous les autres intacts. Avec notre ancien NOS, cela aurait nécessité une mise à niveau complète de l'ensemble du système d'exploitation du commutateur.
L'architecture basée sur des conteneurs offre également une approche élégante de l'allocation et de la surveillance des ressources. Chaque conteneur peut se voir attribuer des contraintes spécifiques en matière de CPU et de mémoire, ce qui évite qu'une seule fonction réseau ne monopolise les ressources du système lors d'événements inattendus. Cela s'est avéré inestimable lors des sessions de dépannage, lorsque nous devions analyser pourquoi un service particulier se comportait de manière anormale.
L'automatisation d'abord : Les API à tous les étages
Si vous êtes comme moi, vous avez passé d'innombrables heures dans les interfaces CLI, à configurer manuellement les appareils un par un. SONiC représente une rupture nette avec ce modèle opérationnel en adoptant l'automatisation à son cœur.
SONiC utilise une base de données Redis comme source centrale de vérité pour les informations de configuration et d'état. Cette approche centrée sur la base de données signifie que tout changement de configuration, qu'il soit effectué par l'intermédiaire du CLI, du SNMP ou des appels API, met finalement à jour la même base de données. Cela assure une cohérence sans précédent entre les interfaces de gestion et élimine la "dérive de configuration" qui affecte de nombreux réseaux.
Le support de l'API REST dans SONiC est complet, permettant tout, de la configuration de base de l'interface à la manipulation complexe de la politique BGP. Plus important encore, ces API ne sont pas ajoutées après coup - elles constituent l'interface principale utilisée par le système lui-même. Cette approche "eat your own dog food" garantit que les API restent robustes, bien entretenues et performantes.
Dans l'environnement de mon équipe, nous avons exploité cette architecture API-first pour construire des pipelines CI/CD pour les changements de réseau. Lorsqu'un développeur soumet une demande de modification de la configuration du réseau, notre automatisation teste ces modifications dans un environnement de test SONiC avant de les déployer en production. Cela a permis de réduire notre taux d'échec de plus de 60% et d'accélérer notre vitesse de déploiement.
De plus, le support natif de SONiC pour les outils d'automatisation standard tels qu'Ansible et Terraform signifie que vous n'avez pas besoin de réinventer la roue. Les modules maintenus par la communauté sont complets et régulièrement mis à jour, ce qui vous permet d'intégrer les appareils SONiC dans vos cadres d'automatisation existants avec un minimum d'effort.
Fonctionnalités de niveau entreprise sans verrouillage du fournisseur
L'aspect le plus remarquable de SONiC est peut-être la manière dont il offre des fonctionnalités de niveau entreprise grâce à un modèle open-source. Contrairement aux solutions propriétaires, SONiC fonctionne sur du matériel provenant de multiples fournisseurs, notamment Arista, Cisco, Dell, Juniper, Mellanox et de nombreux fabricants de boîtes blanches.
L'ensemble des fonctionnalités est impressionnant et ne cesse de s'enrichir :
- Prise en charge complète des protocoles de routage (BGP, OSPF, IS-IS)
- Fonctions avancées telles que EVPN, VXLAN et VRF
- Prise en charge des tampons profonds pour les applications des centres de données
- Mécanismes robustes de qualité de service
- Capacités de télémétrie et de surveillance détaillées
Ayant déployé SONiC dans des environnements de production, j'ai été particulièrement impressionné par son implémentation EVPN. Nous avons récemment migré un centre de données multi-locataires d'une solution propriétaire vers SONiC, et les capacités EVPN se sont avérées plus que suffisantes pour nos besoins complexes de superposition.
Les capacités de télémétrie méritent une mention spéciale. SONiC exporte des données riches et structurées sur l'état et les performances des appareils par le biais des interfaces gNMI et Kafka. Cela permet l'intégration avec des plateformes d'observabilité modernes et permet des analyses de réseau en temps réel qui n'étaient auparavant disponibles que dans des écosystèmes fermés et coûteux.
Ce qui distingue vraiment ces fonctionnalités, c'est qu'elles sont mises en œuvre dans le cadre d'un développement ouvert, piloté par la communauté. Lorsque nous avons découvert un cas limite dans l'implémentation de BGP qui affectait nos modèles de trafic spécifiques, nous avons pu proposer un correctif à la communauté plutôt que d'attendre qu'un fournisseur reconnaisse le problème et développe un correctif selon son calendrier.
Conclusion : L'avenir des systèmes d'exploitation de réseau
Après avoir travaillé pendant des années avec des systèmes d'exploitation de réseau propriétaires, mon expérience avec SONiC m'a convaincu qu'il représente l'avenir des réseaux de centres de données. L'architecture conteneurisée offre flexibilité et résilience, les capacités d'automatisation accélèrent les opérations tout en réduisant les erreurs, et l'ensemble des fonctionnalités rivalisent avec les alternatives commerciales sans l'enfermement du fournisseur.
Si le SONiC n'est pas encore adapté à tous les environnements (les réseaux de campus et certaines fonctions spécialisées des fournisseurs de services restent difficiles), son rythme de développement rapide et la croissance de la communauté suggèrent que son applicabilité ne fera que s'étendre au fil du temps.
Pour les organisations qui cherchent à moderniser leur infrastructure de réseau tout en évitant le verrouillage des fournisseurs, SONiC mérite une considération sérieuse. La courbe d'apprentissage existe, mais les avantages opérationnels sont substantiels et le soutien de la communauté ne cesse de s'améliorer. Comme de plus en plus de professionnels des réseaux se familiarisent avec les architectures basées sur les conteneurs et les pratiques d'infrastructure en tant que code, l'approche de SONiC deviendra de plus en plus la norme attendue plutôt que l'exception.
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).
