Es ist noch gar nicht so lange her, da betrachtete mancher Systemverwalter das Thema Automatisierung mit einer Mischung aus Gleichgültigkeit und Argwohn. Zwischen "Automatisierung vernichtet Arbeitsplätze" und "Es lohnt sich nicht, diese oder jene Aufgabe zu automatisieren, weil sie nur einmal zu erledigen ist" schwankten die Argumente derer, die sich mit Ansible, Puppet & Co. nicht befassen wollten. Diese Zeiten sind zum Glück vorbei, und die meisten Admins verstehen Automatisierung in ihrer Umgebung heute als das, was sie de facto ist: eine Notwendigkeit.

Es ergibt schließlich keinen Sinn, teures IT-Personal mit genialen Fähigkeiten die immer selben Aufgaben erledigen zu lassen, wenn sie genauso gut hilfreiche neue Produkte für das Unternehmen entwickeln könnten. Und der Satz, dass einzelne Arbeiten nur einmal zu erledigen seien, erweist sich in den allermeisten Fällen als Trugschluss. Und das üblicherweise im ungünstigsten Moment – nämlich im Rahmen eines Ausfalls, bei dem der Administrator dann von Hand unter Druck rekonstruieren muss, was er sich vor grauer Vorzeit einmal ausgedacht hat.

Durchaus bemerkenswert ist allerdings, dass die Automatisierungsstory vieler Firmen ein hässliches Loch hat, ja gerade zu eine Art Zwei-Klassen-Gesellschaft in den Schränken eines Unternehmens etabliert. So erschließt sich den allermeisten Admins heute ohne große Diskussion, warum es sinnvoll ist, Server per DHCP, PXE und TFTP automatisch mit einem Betriebssystem zu betanken. Wer sein Setup oft in die Breite skalieren muss, kennt das Problem nur zu gut: etliche Schränke mit hunderten neuen Systemen wären händisch in akzeptabler Zeit unmöglich in einen produktiven Zustand zu bringen.

Auf weit weniger Einsicht treffen die Fans von Automatisierung, wenn sie sich auch die Hardware anschauen, die für den Betrieb von Infrastruktur zwar notwendig ist, jedoch nicht unter den Oberbegriff "Server" fällt. Im modernen RZ sind das neben schaltbaren Steckdosen vor allem Geräte der Netzwerkinfrastruktur – Switches und Router also –, wobei die Trennung in modernen Umgebungen oft fließend ist.

Oft genug ist das der Tatsache geschuldet, dass den Admins einer Umgebung gar nicht klar ist, wie viel Konfiguration auf Netzwerkgeräten eigentlich zu leisten ist. Lange waren einfache Switches verbreitet, bei denen jeder Port per VLAN-Tag logisch einem Kunden zugeteilt und so von den anderen abgegrenzt wurde. Ergänzt um eventuell notwendige Einstellungen für Spanning Tree war die Konfiguration bereits fertig. Allerdings: Wer mal an einem alten HP ProCurve die passende Konfiguration vorgenommen hat, weiß, dass auch das eine lästige Aufgabe ist. Und zwar nicht, weil HP hier ein besonders negatives Beispiel wäre, sondern weil es einfach nervt, per CLI Dutzende, wenn nicht Hunderte von Befehlen einzugeben.

Hinzu kommt obendrein, dass es mit einer so einfachen Switch-Konfiguration heute meist nicht mehr getan ist. Wer etwa skalierbare Setups betreibt, nutzt dabei oft ein internes Border Gateway Protocol (BGP). Dann müssen die Switches aber zugleich Router sein, also über die passende BGP-Konfiguration verfügen. Und das fügt der Sache gleich wieder eine neue Ebene an Komplexität hinzu. Ganz abgesehen von anderen Wehwehchen: Wer beispielsweise Ethernet-VPN (EVPN) betreibt, benötigt zwar auch BGP auf Switches und Routern, zusätzlich werden aber Dienste wie DHCP-Relays fällig. Denn EVPN lebt ja gerade von der Idee, ein großes Netz in viele Layer-2-Segmente zu teilen und zwischen diesen im Anschluss per BGP zu routen.

Wie der Admin die Sache also auch dreht und wendet: Automatisierung auf der Netzwerkebene ergibt ähnlich viel Sinn wie auf der Ebene der Server. Allein die Umsetzung ist deutlich schwieriger: Juniper, Cisco und Huawei haben etwa ganz eigene Ideen und Vorstellungen davon, wie sich ihre Geräte am besten automatisch mit valider Konfiguration versehen lassen. Ihnen gegenüber stehen Ansätze wie Open Networking, bei dem Standardwerkzeuge zum Einsatz kommen, weil Standardschnittstellen seitens der Geräte zur Verfügung stehen. Ein mächtiger Konkurrent im Automatisierungsspiel der Netzwerkinfrastruktur ist zudem Ansible, das durch seine Vielfalt punktet, wenn es um die Kommunikation mit Geräten sämtlicher Hersteller geht.

Juniper gehört mit seinen zahlreichen Switches und Routern seit Jahrzehnten zu den Großen in der Netzwerkbranche. Die Automatisierungsgeschichte des Herstellers ist allerdings nicht so eingängig, wie mancher Systemverwalter sich das vielleicht wünscht. Denn wie fast immer bei den großen Herstellern gilt: Es führen viele Wege nach Rom.

Juniper selbst bietet in seinem Switch- und Router-Betriebssystem Junos OS eine eigene Automatisierungs-Engine an. Diese heißt ganz einfach "Junos Automatisierung" und bietet mehrere Schnittstellen hin zur Außenwelt. Grundsätzlich handelt es sich um Automatisierung auf Basis von Ereignissen: Der Administrator kann anhand von bestimmten Ereignissen also "Trigger" definieren. Tritt das jeweilige Ereignis ein, führt der Switch die durch den Admin mit diesem Ereignis verknüpfte Aktion aus.

Hinzu gesellen sich zwei weitere Arten von Skripttypen: Die "Operational" sowie die "Commit Scripts". Die ruft Junos Automatisierung selbstständig auf, falls der Admin bestimmte andere Konfigurationsschritte händisch vornimmt. Was sämtlichen Skripttypen in Junos Automatisierung gemein ist: Der Systemverwalter spielt sie in Form von XML-, XSLT- oder SLAX-Statements oder Python-Skripten ein.

Mancher Admin stöhnt hier vermutlich auf, denn keines der genannten Formate steht in der IT allgemein im Verdacht, besonders gut les- oder schreibbar zu sein. Zumal die Junos-Automatisierung eine Lücke hat: Ist ein Switch einmal grundsätzlich im Betrieb, lassen sich mit der Engine diverse Dinge – etwa Debugging-Aufgaben – gut automatisieren. Wer den Switch oder Router aber automatisiert in Betrieb nehmen will, legt entweder sehr viel Handarbeit für die Automatisierung-Engine an oder greift – natürlich gegen Bares – auf ein anderes Produkt des Herstellers zurück: Apstra.

Apstra bietet die Möglichkeit, frisch ausgepackte Juniper-Geräte mit einer initialen Konfiguration auszustatten – mit einer schönen Management-GUI und einer Vielzahl praktischer Funktionen. Im Hintergrund greift es freilich zum Teil auf die Automatisierungs-Features von Junos OS zurück; hiervon merkt der Admin aber nichts. Was der Admin merkt, ist das Loch, das Apstra zusätzlich zu den ohnehin schon meist nicht ganz günstigen Netzwerkgeräten selbst in den Geldbeutel reißt. Wie üblich finden sich im Netz keine konkreten Angaben zu den Preisen, doch günstig ist Apstra nicht. Es stellt sich zudem die Frage, ob es aus Admin-Sicht gerade in kleineren Setups wirklich Sinn ergibt, viel Geld für eine komplexe Software auf den Tisch zu legen – denn in Form von Ansible steht eine gute Alternative bereit.

Die meisten Systemverwalter assoziieren Ansible oft gar nicht mit Hardware, die eher in die Kategorie "Infrastruktur" fällt. Das ist ein grober Fehler, denn mit den Geräten vieler Hersteller beherrscht Ansible mittlerweile einen weitgehend perfekten Umgang. Weitgehend perfekt, weil sich nicht alle Funktionen sämtlicher Geräte nutzen lassen. Ein solides Fundament grundsätzlicher Funktionen ist jedoch für die Geräte aller Hersteller gegeben. Das Beispiel Juniper macht das gut deutlich.

Denn wer sich die Ansible-Module für Junos-Geräte im Detail anschaut [1], merkt schnell: Hier gibt es mannigfaltige Möglichkeiten, den Geräten unmittelbar Befehle mit auf den Weg zu geben. Alles, was dazu gegeben sein muss, ist eine Verbindung zwischen Ansible-Host und Switch samt entsprechender Logins.

Die Ansible-Module bieten zudem mehrere Möglichkeiten, Konfiguration auf den Switches zu hinterlegen. Ihnen allen ist gemein, dass der ausführende Admin die CLI-Syntax der Junos-Shell beherrschen muss. Bewusst haben die Entwickler sich also dazu entschieden, gar keine Abstrahierung zu implementieren, sondern die originale CLI-Sprache an den Systemverwalter durchzureichen. Wer Geräte mehrerer Hersteller per Automatisierung betanken möchte, muss sich gegebenenfalls also passende Ansible-Rollen selbst bauen.

Bei der Suche nach Hinweisen, wie Cisco das Thema Automatisierung für die eigenen Geräte angeht, fühlt sich der IT-Verantwortliche im ersten Augenblick beglückt. Denn in Ciscos eigener Dokumentation in Sachen Automatisierung findet sich der Hinweis auf ein "Day-0 Deployment Tool". Als "Day-0-Deployment" bezeichnen Admins heute in der Regel Szenarien, bei denen Geräte nur aus dem Karton genommen und im Rack installiert werden, um anschließend automatisch eine Konfiguration zu erhalten. "Ignite" hieß dieses Werkzeug bei Cisco – und dass es so hieß, ist Teil des Problems. Denn wer sich in der Dokumentation des Herstellers umschaut, findet zwar einen Link zu GitHub, dort ist das Ignite-Repository aber als "Deprecated" markiert, also als veraltet.

Spätestens jetzt schwant dem erfahrenen Systemverwalter Böses, und im Fall von Cisco zurecht. Denn die komplette Automatisierung bei Cisco basiert heute auf Cisco ACI, der "Application Centric Infrastructure". Das ist eigentlich eine Software-defined-Network-Lösung, die aber auch Cisco-Hardware zu konfigurieren in der Lage ist. Damit das funktioniert, muss der Administrator allerdings einiges an Geld in die Hand nehmen. Denn Cisco ACI bedingt Controller in Form spezieller Software, Lizenzen für jedes verbundene Gerät, eigene Lizenzen, falls die Verbindung über mehrere Standorte gespannt sein soll, und so weiter.

Obendrein lässt ACI sich auf Wunsch sehr eng mit Software verzahnen, etwa mit einem Cloudwerkzeug wie Open­Stack. Eine so konstruierte Aufstellung bietet dem Systemverwalter allerdings keine Option mehr, zu einem anderen Anbieter zu wechseln. Kurz und knapp: Cisco ACI ist aus Sicht des Anbieters einerseits ein Traum, weil es den Vendor-Lock-in bis weit auf die Software-Ebene ausdehnt. Und weil es kommerzielle Spielräume für das Geschäft mit zusätzlichen Lizenzen eröffnet, die ohne eine komplexe und vielfältige Umgebung wie ACI nicht denkbar wären.

Notabene: Wer lediglich ein paar Switches automatisch mit Konfiguration betanken will, wird den größten Teil der ACI-Features niemals benötigen. Mit der ACI innewohnenden Komplexität müssen Admins sich dann aber trotzdem auseinandersetzen. Und natürlich mit den Lizenzkosten für das Produkt.

Wer sich diesen Aufwand nicht antun will, bekommt einmal mehr Schützenhilfe von Ansible. Verschiedene Ansible-Erweiterungen für Cisco-Geräte mit IOS [2] oder Nexus [3] stehen im Netz zur Verfügung und sind zum Teil in Ansible integriert. Cisco selbst geht in der eigenen Dokumentation gar auf die Möglichkeit ein, die eigenen Geräte per Ansible automatisch zu konfigurieren. Praktisch: Die Module sowohl für Nexus- als auch für IOS-Geräte implementieren anders als die für Juniper-Geräte eigene Funktionen für bestimmte Aufgaben. Sie geben also nicht nur mit der Cisco-CLI kompatible Befehle an die Geräte weiter.

Möchte der Admin etwa ein VLAN konfigurieren, erledigt er das mit der Funktion "cisco.nxos.nxos_vlans". Das ist einerseits hilfreich, weil die CLI-Syntax von NEXUS oder IOS vielen Admins vermutlich nicht so eingängig ist wie die Parameter von Ansible. Andererseits kann dieser Modus Operandi aber auch dazu führen, dass viele Admins das Gefühl bekommen, mit Cisco-Geräten hantieren zu können – obwohl das gar nicht der Fall ist. Vorsicht in der Einschätzung der eigenen Fähigkeiten ist also angebracht.

Huawei hat mit seiner Netzwerkhardware noch nicht annähernd die Verbreitung von Juniper oder Cisco erreicht, knabbert aber kontinuierlich am Kuchen der Großen. Da verwundert es nicht, dass sich Huaweis Automatisierungsansatz von jenem der großen Anbieter nicht so stark unterscheidet. Geht es nach dem Anbieter, würden Kunden ihr Huawei-basiertes Netz mit dem "Agile Controller" steuern.

Der funktioniert im Kern so ähnlich wie Ciscos ACI-Controller und kann jede Maschine im Netz im Stil eines Day-0-Deployments mit einer entsprechenden Konfiguration ausstatten. Auch hier gilt allerdings wieder, dass die Software komplex und für die meisten Setups vermutlich viel zu umfangreich ist. Wer lediglich ein paar Huawei-Switches oder -Router konfigurieren möchte, konfiguriert sich beim Agile Controller schnell einen Wolf.

Die Lösung, der geneigte Leser ahnt es bereits, ist einmal mehr Ansible. Nicht nur, dass Huawei in der jüngeren Vergangenheit explizit die Integration der eigenen Hardware in Ansible beworben hat. Tatsächlich steht diese Integration heute in Form zusätzlicher Module zu Ansible [4] zur Verfügung. Das bedeutet ganz konkret: Aus Ansible heraus lassen sich einem Switch Kommandos schicken, so wie es auf der CLI des Switches ebenfalls möglich wäre. Wie Juniper hinkt Huawei hier bei der Ansible-Integration insofern nach: Nur wer die Huawei-CLI-Sprache kennt, kommt mit den Ansible-Modulen voran. In Summe ist aber selbst dieser Lernaufwand für Huawei-Geräte noch immer kleiner als das Setup des Agile Controllers.

Zuletzt darf in diesem Vergleich Nvidia nicht fehlen – denn auch dieser Hersteller ist mittlerweile als Anbieter von Netzwerkhardware im Rechenzentrum aktiv. Diese Sparte hat das Unternehmen jedoch nicht selbstständig aufgebaut, sondern extern zugekauft: Wer Netzwerkhardware von Nvidia kauft, kriegt Mellanox auf der Hardware- und Cumulus Linux auf der Softwareseite.

Mellanox hat sich in der Community seit Jahren einen Namen als Verfechter von "Open Networking"-Ideen gemacht. Und in dasselbe Horn stößt Cumulus, bei dem es sich ja im Grunde nur um ein Debian GNU/Linux handelt, das auf Netzwerkgeräten von Mellanox lauffähig ist. Was lapidar klingt, bringt allerdings große Vorteile mit sich.

Weil der Admin es auf Mellanox-Hardware mit einem normalen Linux-System zu tun hat, das über spezielle Kernel-Treiber das ASIC des Switches steuert, stehen ihm alle gewohnten Werkzeuge von anderen Linux-Systemen zur Verfügung. Nach dem Login landet er also in einer Bash, die Konfiguration der einzelnen Ports lässt sich mit Werkzeugen wie "ip" problemlos überprüfen. De facto sieht ein Switch mit 48 Ports hier aus wie ein Linux-System mit vielen Netzwerkkarten. Und weil Debian einen etablierten Weg kennt, diese zu konfigurieren, lässt sich auf einem Cumulus-System von Mellanox auch heute noch "/etc/network/interfaces" nutzen.

Hinzu gesellt sich bei Bedarf "/etc/frr/ frr.conf", falls Protokolle wie BGP oder OSPF nötig sind. Eine Ausgabe gibt es: Cumulus kennt ein CLI-Werkzeug namens "net", das Cumulus-spezifisch ist. Dieses ist jedoch gut dokumentiert und spielt bei der Automatisierung zudem höchstens eine untergeordnete Rolle.

Die Automatisierung der Konfiguration von Switches mit Cumulus Linux ist denkbar einfach. Mehrere Male hat sich in diesem Artikel bereits Ansible als Werkzeug der Wahl entpuppt, und das ist gerade bei Cumulus Linux nicht anders. In den meisten Fällen wird der Admin nämlich seine Ansible-Rollen so gestalten wollen, dass sie auf den Switches die beiden erwähnten Dateien aus Templates generieren und ausrollen. Änderungen an "interfaces" bedingen im Anschluss ein ifreload -a und Änderungen an "frr.conf" einen Restart des "frr"-Dienstes. Kleinigkeiten wie das Applizieren der Switch-Lizenz für Cumulus-Linux lassen sich ebenfalls hervorragend in Ansible abbilden. Hier gibt es im Netz sogar fertige Rollen und Playbooks, auf denen der Systemverwalter im Zweifelsfalle seine eigene Arbeit fußen lässt.

Gerade weil bei Cumulus Linux eine echte Shell zur Verfügung steht und gängige CLI-Werkzeuge von Linux verfügbar sind, lässt es sich von allen Ansätzen in diesem Vergleich am besten mit Standardwerkzeugen automatisieren. Das geht so weit, dass der Admin die gesamte Konfiguration eines Switches in Ansible über dessen Variablen pro Host festlegen kann – Ansible kümmert sich danach auf der Basis seiner Templates um den Rest. Leider findet sich im Netz kein allgemein gültiges Beispiel; dies hängt auch damit zusammen, dass sich die Umgebungen auf Basis von Cumulus stark unterscheiden. Der Versuch, alle Eventualitäten einer FRR- oder Interfaces-Konfiguration abzubilden, müsste insofern zwangsläufig zur gefürchteten "YAML-Schaufel" führen. Der Begriff bezeichnet verächtlich den Ansatz, alle möglichen Konfigurationsparameter einer Datei in YAML abzubilden, damit Ansible anschließend wieder eine Konfigurationsdatei daraus machen kann.

Sinnvoller ist es aus Sicht des Admins, sich zumindest für "frr.conf" und "interfaces" lokale Templates zu bauen, die lediglich den erforderlichen Umfang haben und die erforderlichen Funktionen abdecken. Das dürfte in den allermeisten Fällen in wenigen Tagen erledigt sein, falls es überhaupt so lange dauert. Der Mühe Lohn besteht darin, kaputte Switches in Windeseile durch neue ersetzen zu können – oder, falls es um das Skalieren in die Breite geht, neue Geräte komplett automatisiert online zu bekommen.

Ideen für das Thema Automatisierung haben alle Anbieter im Programm – doch könnten diese unterschiedlicher kaum sein. Zu gerne würden Juniper für Junos, Cisco für Nexus & Co. sowie Huawei für die eigenen Geräte die Kunden im eigenen Produktportfolio fangen. Riesige Suiten wie etwa Ciscos ACI, die vorrangig Software-defined Networking bieten und dabei quasi en passant auch die Hardware automatisiert mitkonfigurieren, dürften gerade für kleinere Unternehmen aber völlig überdimensioniert sein. Obendrein verschärfen Sie den "Lock-in" eines Kunden im Zusammenhang mit dem jeweiligen Anbieter.

Ausgesprochen elegant und vielseitig zeigt sich im Vergleich hingegen Ansible. Selbst in Infrastrukturen, in denen sich Hardware unterschiedlicher Hersteller findet, bietet das Werkzeug die Option zur einheitlichen Konfiguration. Denn wer für seine Einstellungen einmal ein Format definiert, kann dieses in Playbooks für alle Hersteller verarbeiten. Damit gilt: Wer Netzwerkhardware automatisieren möchte, sollte Ansible nicht nur auf der Rechnung haben, sondern bevorzugt evaluieren. Lediglich ein Problem lässt sich damit zumindest im Augenblick noch nicht zufriedenstellend lösen: Jenes des Day-0-Deployments. Cisco war mit Ignite hier de facto auf der richtigen Spur. Hier bleibt zu hoffen, dass FL/OSS-Projekte die Lücke in Zukunft füllen.