Was ich vor der Arbeit mit SONiC NOS gerne gewusst hätte - die Perspektive eines CCIE
Wenn Sie sich jahrelang mit traditionellen Netzwerkbetriebssystemen - Cisco IOS, NX-OS, Junos - beschäftigt haben, ist der Wechsel zu einer disaggregierten Plattform wie SONiC (Software for Open Networking in the Cloud) ist eine erschütternde Erfahrung. Als CCIE dachte ich, ich hätte die Kernkompetenzen, um jedes Netzwerkbetriebssystem zu übernehmen. SONiC hat mich gedemütigt. Es ist eine leistungsstarke Plattform, die jedoch eine ganz andere Denkweise und Fähigkeiten erfordert. Wenn Sie gerade dabei sind, Ihre SONiC-Reise zu beginnen, sind hier die Schlüsselkompetenzen, von denen ich wünschte, ich hätte sie vorher entwickelt.
1. Linux-Grundlagen Über die Grundlagen hinaus
SONiC ist auf Linux aufgebaut, und ich meine WIRKLICH auf Linux aufgebaut. Im Gegensatz zu traditionellen NOSs, wo das zugrunde liegende Betriebssystem versteckt ist, SONiC setzt Sie auf alles - systemd, Container, Bash-Skripte und mehr. Grundlegende Linux-Kenntnisse sind nicht genug. Sie müssen damit vertraut sein:
- Navigieren im Dateisystem
- Lesen von Protokollen in /var/log/
- Fehlerbehebung bei systemd-Diensten (systemctl status, journalctl)
- Verwaltung containerisierter Dienste über Docker (Docker exec, Docker Logs)
Wenn Sie außer der Aktivierung von SSH oder ping noch nie eine Linux-CLI angefasst haben, werden Sie schnell verloren sein.
2. Verständnis der containerisierten Architektur
SONiC ist Microservice-basiert. Jede Netzwerkfunktion (BGP, LLDP, DHCP-Relay) läuft in einem eigenen Docker-Container. Das bedeutet:
- Protokolle sind containerspezifisch.
- Netzwerk-Namensräume können den Datenverkehr isolieren.
- Ausfälle können auf einen bestimmten Container beschränkt werden, ohne dass der Rest des Systems beeinträchtigt wird.
Ich musste meine "monolithischen OS"-Instinkte verlernen, schließlich bin ich mit Cisco IOS aufgewachsen, wo alles zentralisiert ist. Die Fehlersuche ist ganz anders, wenn Routing-Entscheidungen in einem Container getroffen und Schnittstellen in einem anderen verwaltet werden.
3. Arbeiten mit Redis und dem SONiC-DB-Modell
SONiC verwendet eine Redis-DB als Vermittler zwischen Konfiguration, Status und der zugrunde liegenden Hardware-Abstraktionsschicht. Es gibt mehrere logische DBs - CONFIG_DB, STATE_DB, APPL_DB - die jeweils einem bestimmten Zweck dienen. Das müssen Sie wissen:
- Abfrage von DB-Einträgen (redis-cli -n keys *)
- Das Schema (SONiC YANG-Modelle helfen)
- Wie die swss-Prozesse Daten aus Redis verbrauchen
Ich wünschte, ich hätte mir im Vorfeld mehr Zeit genommen, um das DB-Schema und die Orchestrierungspipeline von SONiC zu verstehen, das hätte mir eine Menge Kopfzerbrechen erspart.
4. Git und Quellcode-Navigation
SONiC ist Open Source. Wenn etwas bricht oder verhält sich nicht wie erwartet, gibt es eine gute Chance, Ihre Suche wird auf öffentliche GitHub Fragen zeigen, können Sie sogar den Quellcode zu lesen, oder wenn Sie es wagen, bauen / debuggen das System selbst. Es hilft, ein solides Verständnis zu haben von:
- Git-Grundlagen (clone, diff, branch)
- Lesen von Python/C++-Code (insbesondere in swss, syncd, orchagent)
- Erstellen von Bildern über das SONiC-Build-System
BTW, wenn Sie Unterstützung auf SONiC von einem Hersteller, Integrator oder Partner erhalten, werden Sie wahrscheinlich nie zu den oben genannten, aber ich bin immer versuchen, neue Dinge zu lernen.
5. DevOps- und Automatisierungs-Mentalität
SONiC wurde ursprünglich für Cloud-Anbieter entwickelt. Von einer manuellen Konfiguration wird abgeraten. Umarmen:
- Terraform-Ressourcenblöcke
- Ansible-Playbooks
- Konfigurationsverwaltung über config_db.json
- Bildverwaltung und ZTP
- CI/CD-Pipelines für Netzwerkänderungen
Wenn Sie die Konfigurationen immer noch Zeile für Zeile über die CLI bearbeiten, machen Sie es falsch.
Schlussfolgerung
SONiC ist nicht nur ein NOS - es ist eine Plattform, die zukünftige Netzwerkfunktionen ermöglicht. Es belohnt Ingenieure, die wie SREs denken, und bestraft diejenigen, die an veralteten Arbeitsabläufen festhalten. Ich habe durch meine Erfahrungen mit SONiC viel gelernt, aber wenn ich zurückgehen könnte, würde ich mich mehr auf Linux, Container und Automatisierung vorbereiten. SONiC ist die Zukunft des offenen Netzwerks - seien Sie einfach bereit, aufzusteigen, wenn Sie dort ankommen.
Josh Saul
VP Produktmarketing
Josh Saul leistet seit mehr als 25 Jahren Pionierarbeit bei Open-Source-Netzwerklösungen. Als Architekt hat er Kernnetzwerke für GE, Pfizer und NBC Universal aufgebaut. Als Ingenieur bei Cisco beriet Josh Saul Kunden aus dem Fortune-100-Finanzsektor und warb bei Kunden für neue Technologien. In jüngerer Zeit leitete Josh Marketing- und Produktteams bei VMware (übernommen von Broadcom), Cumulus Networks (übernommen von Nvidia) und Apstra (übernommen von Juniper).
