Komponenten jonglieren

von Martin Loschwitz

Während Lifecycle-Management bei Servern mittlerweile fast schon zum guten Ton gehört, tun viele Administratoren sich bei der Automation und der zentralen Verwaltung von Infrastrukturgeräten wie Switches schwer. Einen technischen Grund gibt es dafür eigentlich nicht, denn Tools für verschieden Gerätetypen stehen durchaus zur Verfügung. Der Artikel zeigt, was für die Softwareverwaltung von Infrastrukturkomponenten nötig ist und welche Geräte im Fuhrpark besser und welche schlechter zu handhaben sind.

Im Rechenzentrum der Gegenwart ist Lifecycle-Management das Gebot der Stunde. Diverse Werkzeuge verschiedenster Hersteller buhlen dabei um die Gunst der Admins. Das Versprechen ist stets dasselbe: Ist ein Server erstmal ausgepackt und im Rack verschraubt, schaltet der Administrator ihn per Knopfdruck nur noch an. Den Rest erledigen Automation und Orchestrierung – mittels Protokollen und Modellen wie DHCP, PXE und TFTP bekommt der neue Rechner zunächst ein Installationssystem, das das komplette Betriebssystem automatisch auf die Platte bügelt. Im Nachgang laufen Automatisierer wie Ansible, Puppet oder Chef los und betanken das Gerät mit der gewünschten Software und der passenden Konfiguration. Kurze Zeit später steht der Server für die vorgesehene Aufgabe zur Verfügung.

Und falls einmal etwas schief geht, ist das auch kein Problem: Wenige Mausklicks genügen und das Lifecycle-Management installiert die Maschine neu. Das soll Administratoren vor allem vor stundenlangem Debugging bewahren, das auf händisch konfigurierte Änderungen des Systems zurückgeht. Und was vor zehn Jahren noch wie schwarze Magie geklungen hätte, klappt in Summe heute ganz hervorragend. Die "Economy of Scale", die sich aus vollständiger Automatisierung ergibt, ist dabei unternehmenskritisch für jene Unternehmen, die ihr Geld als Plattformanbieter verdienen und ihre Landschaft möglichst schnell in die Breite skalieren wollen.

So gut Automation und Orchestrierung bei Servern funktionieren, so desolat ist die Situation hingegen bei typischen Infrastrukturkomponenten wie Switches. Dabei gehören die zur Infrastruktur eines Racks freilich genauso dazu wie die Server, denen sie dienen. Ein falsch konfigurierter Switch im Rack nimmt einen Server im schlechtesten Fall genauso offline wie ein Fehler in der Konfiguration des jeweiligen Systems. Und beim Skalieren in die Breite spielen die nötigen Infrastrukturkomponenten ebenso eine Rolle. Und mehr noch: Switches etwa für die BMC-Netzwerke der Systeme sind unerlässlich, damit Metal-as-a-Service-Tools von Canonical, Red Hat Satellite oder SUSE Manager ihre Aufgaben im Hinblick auf Server abwickeln können.

Betroffene Geräte und Automatisierungsfelder

Auf seiner Reise hin zur automatisierten Infrastruktur tut der Administrator gut daran, sich zunächst einen Überblick über die betroffenen Geräte zu schaffen. Im Standardrack der Gegenwart finden sich typischerweise die klassischen Komponenten für Zwecke der Infrastruktur:

- Switches (Leaf-Spine oder klassische L2-Architektur und L2-Switch für BMC)

- Terminalserver für den Zugriff auf BMC-Schnittstellen

- Steuerbare Steckdosen ("Power Distribution Units" oder PDOs)

Die Relevanz von Terminalservern zum Anbinden von Komponenten mit serieller Schnittstelle hat dabei in den vergangenen Jahren allerdings kontinuierlich abgenommen. Mittlerweile kommt für den Zugriff auf eine (virtuelle) serielle Konsole üblicherweise die BMC-Schnittstelle zum Einsatz. Das jedoch unterstreicht die Notwendigkeit, auch den für diese Schnittstellen vorgesehenen Switch sinnvoll automatisiert zu konfigurieren.

Je nach Szenario gesellen sich zu den aufgelisteten Geräten noch zusätzliche Komponenten. Wer etwa ein echtes Core-Gateway betreibt, hat dafür üblicherweise leistungsstarke Router zum Beispiel von Cisco oder Juniper im Einsatz. Auch diese sind eigentlich ein Fall für Automatisierung und die Verwaltung mittels Managementsoftware, auch wenn Administratoren genau davor in der Regel zurückschrecken. Die Anzahl solcher Geräte im Rechenzentrum ist aber in den meisten Fällen auch relativ gering. Selbst wenn also am Ende nur diese Komponenten für die händische Pflege übrigblieben, ließe sich in den meisten Rechenzentren trotzdem ein erheblicher Gewinn in Sachen Effizienz und Betriebssicherheit realisieren.

Steht fest, um welche Geräte und um welche Anzahl es eigentlich geht, ist die nächste Frage jene nach anstehenden Aufgaben. Was genau ist im Hinblick auf Infrastruktur im Rack also zu leisten, wie tief soll die Integration gehen? Ein paar offensichtliche Punkte sind

- die Installation und das Update der Betriebssysteme der Geräte,

- das Aufspielen der benötigten Konfiguration und

- das automatische Konfigurieren von Monitoring, Alerting und Trending.

Je nach Gerätetyp und Hersteller fallen noch zusätzliche Aufgaben an. Diese aber sind so hochspezifisch, dass auf sie einzugehen den Rahmen dieses Artikels sprengen würde. Wieder gilt aber: Gelingt es dem Administrator, die gröbsten Brocken in Form des Betriebssystems und der Konfiguration aus dem Weg zu räumen, ist der Zuwachs an Effizienz dramatisch. Die einzelnen genannten Punkte allerdings bedingen – wieder in Abhängigkeit von Gerät und Hersteller – unterschiedliche Herangehensweisen.

Leidiges Thema OS-Wartung

Die Wurzel umfassender Automation und Orchestrierung von Infrastruktur ist, die Betriebssysteme der betroffenen Geräte unter ein Regime der automatisierten Konfigurationsverwaltung zu stellen. Der erste Schritt dorthin besteht aus der Automation des Betriebssystems selbst. Zunächst geht es also gar nicht um die Frage, welche Ports beispielsweise auf einem Switch wie konfiguriert sind. Im Fokus steht stattdessen die Frage, wie sich das Betriebssystem des Geräts installieren und aktualisieren lässt. Netzwerkswitches bilden in dieser Hinsicht mit die größte Herausforderung. Denn sie sind einerseits in beinahe jedem Rack vorhanden; andererseits aber ist hier die Streuung der Hersteller und der möglichen Lösungen beinahe unendlich groß.

Ein schneller Blick auf handelsübliche Konfigurationen verdeutlicht das schnell. Zwei absolute Standardausrüster sind Cisco und Juniper. Neuerdings findet sich auch Huawei immer häufiger. Kleinere Anbieter wie Nvidia (über das eingekaufte Unternehmen Mellanox), HP oder Arista kommen hinzu. Den Geräten all dieser Hersteller gemein ist, dass sie ab Werk mit einem installierten Betriebssystem ausgeliefert werden. Doch schon die ersten Schritte der Konfiguration variieren zum Teil erheblich. Und dabei ist die Frage noch gar nicht gestellt, wie Updates des Betriebssystems nach der Vorstellung des Herstellers einzuspielen sind. Hier ist also eine genauere Betrachtung nötig. Dabei lässt sich die Netzwerkwelt grob in zwei verschiedene Bereiche einteilen.

Proprietät schafft Hürden

Die eine Gruppe beschreibt Geräte mit proprietärer Software und einer vollständig eigenen Kommandozeile als zentraler Schnittstelle. Jeder Netzwerkadministrator weiß sofort, was gemeint ist: Die CLIs von Cisco und Dell etwa unterscheiden sich weitgehend voneinander, lediglich einzelne Kommandos sind auf Geräten beider Hersteller nutzbar. Und jemand, der umfassende Erfahrung mit der Linux-Shell hat, kann deshalb noch lange keine Geräte der genannten Hersteller bedienen. Zum Teil ist das auch gar nicht gewollt, weil sich über die Eigenheiten der Betriebssysteme Schulungen und Consulting verkaufen lassen.

Entsprechend eindeutig ist auch die Empfehlung von Cisco und Juniper, ebenso wie von Huawei: Die Softwareinstallation sollte entweder mittels spezieller Software von außen angestoßen werden oder über die Funktionen des laufenden Betriebssystems selbst realisiert sein. In iOS, NX-OS, JunOS & Co. sind entsprechenden Features vorhanden, die die Software des Geräts selbst aktualisieren. Zum Teil geht das auch komplett automatisch. Sinnvoll in ein Framework für Lifecycle-Management zu integrieren sind diese Automatismen jedoch nicht. Für die Verwaltung des Betriebssystems ist es also ratsam, den Empfehlungen des Herstellers zu folgen.

Mit einer Ausnahme: In Ansible existieren mittlerweile für die Geräte zahlloser Hersteller Module, mittels derer sich einzelne Funktionen in Form von Paketen oder Modulen zentralisiert und automatisiert nachrüsten lassen. Für die Produkte einiger Produzenten umfasst das explizit auch das möglicherweise notwendige Management von Lizenzen für Zusatzfunktionen. Ein Quentchen Automatisierung gelingt also auch bei diesen Geräten und ihrem Betriebssystem.

Offene Standards erleichtern Automatisierung

Deutlich einfacher zeigt sich die Situation, wenn stattdessen ein Switch mit einer Managementschnittstelle auf Grundlage offener Standards zur Anwendung kommt. Die haben in der Regel nämlich eine Linux-CLI und die grundlegenden Shell-Kommandos funktionieren entsprechend. Vorreiter und noch immer Platzhirsch in dieser Hinsicht ist freilich Cumulus Linux, selbst mittlerweile ebenfalls Teil von Nvidia und üblicherweise im Schlepptau von Nvidia-Switches zu finden.

Cumulus Linux fußt im Kern auf Debian GNU/Linux. Bereits auf dem frisch ausgelieferten und gerade eingebauten Switch funktioniert entsprechend das apt-Kommando. Und damit lässt sich praktisch das gesamte Betriebssystem effizient aktuell halten, auch aus den gängigen Automatisierern heraus. In Ansible beispielsweise ist das reguläre apt-Modul dafür nutzbar, es braucht also nicht mal ein spezielles Modul für Cumulus. Analog sieht die Sache bei anderen Switch-Betriebssystemen aus, die auf dem ONIE-Standard fußen.

Konfiguration folgt Server-Vorbild

Deutlich angenehmer gestaltet sich das Lifecycle-Management bei Netzwerkswitches, wenn es um deren Konfiguration geht. Denn hier haben die großen Hersteller längst realisiert, dass Handlungsbedarf ihrerseits besteht. Deshalb haben sie alle ihre Geräte um standardisierte Schnittstellen erweitert, die sich von außen ansprechen lassen. Die Open-Source-Community ihrerseits hat reagiert und für die gängigen Automatisierer Erweiterungen produziert, die eben diese Schnittstellen nutzen. Im Detail unterscheiden die Ansätze sich allerdings voneinander.

So existieren beispielsweise sowohl für Ansible als auch für Chef umfangreiche Integrationen der Konfigurationsschnittstellen von iOS, NX-OS und JunOS, also für die Geräte von Cisco und Juniper. Auch Geräte von Huawei lassen sich über die Standard-Automatisierer mittlerweile recht gut mit einer Konfiguration versehen. Dabei herrscht allerdings der Ansatz vor, die Automatisierung so zu implementieren, wie der Administrator auch Befehle auf den Kommandozeilen der jeweiligen Geräte eingeben würde.

Wer also auf einem Switch einen bestimmten Port mit einer angepassten Konfiguration versehen will, automatisiert das genauso wie auf der Shell: Nach und nach setzt er etwa aus Ansible heraus die einzelnen Parameter. Dabei kann es durchaus vorkommen, dass eine bestimmte Reihenfolge einzuhalten ist, etwa weil ein bestimmtes Setting auf einen Port nur anzuwenden ist, wenn eine andere Konfiguration für diesen Port bereits gegeben ist.

Setzen Admins hingegen auf Netzwerkgeräte mit ONIE-Interface und haben es folglich mit Cumulus, Sonic oder einer anderen Variante zu tun, gleicht die Administration eher der klassischen Linux-Automatisierung. Kein Wunder: Sinn und Zweck von Cumulus & Co. ist es ja gerade, die Konfiguration der Geräte so umzusetzen, wie es auch auf einem Standardserver mit demselben Linux der Fall wäre. Die Integration mit dem proprietären ASIC des jeweiligen Anbieters passiert dann auf der Kernel-Ebene und mit spezieller Software.

Konkret bedeutet das, dass etwa die Einrichtung einer BGP-Session auf einem Spine-Switch hin zum Core-Gateway über die Konfigurationsdatei des Dienstes "frr" eingerichtet wird – zumindest in Cumulus Linux. Wer es bereits mit Debian zu tun hatte, erinnert sich von dort möglicherweise zudem an "/etc/network/interfaces". Eben weil Cumulus auf Debian GNU/Linux basiert, ist diese Datei auch hier die zentrale Konfigurationsdatei für die einzelnen Ports. Aus Admin-Sicht ist ein mit Cumulus bestückter Switch also auch nichts anderes als ein Computer mit sehr vielen Netzwerkschnittstellen.

Das impliziert auch, dass der Admin die gesamte Konfiguration eines Ports in "interfaces" verankern und die Datei danach einfach auf den Switch per Ansible kopieren kann. Ein Neustart des Netzwerks führt dazu, dass der Switch die neue Konfiguration auch verwendet. Freilich sind aber Abhängigkeiten zwischen einzelnen Diensten möglich. Wer etwa FRR für einen bestimmten Port konfigurieren möchte, sollte zuvor sicherstellen, dass der Port die passende Konfiguration hat.

Module und Playbooks nicht immer sinnvoll

Es darf als Treppenwitz der Geschichte gelten, dass die Integration der Geräte von Juniper, Cisco, Huawei und anderer in Automatisierer wie Ansible, Puppet oder Chef üblicherweise besser ist als die verfügbare Automation etwa für Cumulus Linux. Das dürfte nicht zuletzt daran liegen, dass viele Administratoren für ihre Switches mit Cumulus lieber komplett eigene Ansible-Implementierungen schreiben. Die Alternative dazu wäre ja, auf standardisierte Playbooks oder Ansible-Module zu setzen und diese dem eigenen Bedarf anzupassen. Das aber ist manchmal mehr Arbeit, als sich einfach eine passende "interfaces" sowie eine entsprechende "frr.conf" selbst zu generieren.

Ein umfassendes Cumulus-Setup mit EVPN lässt sich über diese beiden Dateien bereits gut realisieren. Wer sich jedoch inspirieren lassen möchte, findet im Netz mehrere Implementierungsbeispiele für die Konfiguration von Cumulus Linux. Administratoren sollten allerdings darauf achten, sich ein Anschauungsobjekt herauszupicken, das wirklich die Dateien auf dem System kopiert. Für das Cumulus-interne Konfigurationsmanagement stehen zwar ebenfalls fertige Playbooks bereits. Zumindest zwischenzeitlich hat Cumulus aber selbst davon abgeraten, quasi zwei Managementsysteme (das interne sowie Ansible oder Chef) aufeinander zu pfropfen.

Als vorläufiges Fazit steht damit fest, dass Netzwerkgeräte sich im Hinblick auf ihre Konfiguration heute umfassend automatisieren lassen. Was die Verwaltung des auf dem Gerät installierten Betriebssystems angeht, hängt die Qualität der nutzbaren Automation stark von der Vorleistung des jeweiligen Anbieters ab. Auch hier ist Automatisierung bis zu einem bestimmten Grad im Normalfall aber gut zu realisieren und im Alltag mit einem Mehr an Effizienz zu verwenden.

Weitere Infrastruktur einschließen

Auf der To-do-Liste stehen damit allerdings noch die PDUs einerseits und Geräte wie Terminalserver andererseits. Auch USVs wird der eine oder andere Administrator in seiner Auflistung vermissen. Der Erfahrung nach ist es gerade in vollständig durchorganisierten Rechenzentren so, dass der einzelne Administrator mit diesen gar nichts zu tun hat. Um USVs – in welcher Form auch immer – kümmert sich im Normalfall stattdessen meist eine spezielle Abteilung oder der RZ-Anbieter selbst. Mit seriellen Switches und schaltbaren Steckdosen sieht das anders aus.

Die gute Nachricht ist, dass es auch für diese Geräte meist umfassende Unterstützung in den gängigen Automatisieren gibt. Die schlechte Nachricht besteht darin, dass das de facto vom jeweiligen Einzelfall abhängt und zum Teil sogar das Sortiment innerhalb eines Herstellers im Support stark variiert. Grundsätzlich gilt: Je weiter verbreitet bestimmte Komponenten insgesamt sind, desto besser ist im Normalfall der Support durch freie Software. Ein paar Beispiele verdeutlichen das gut: APC beispielsweise gilt als Standardlösung im Kontext von praktisch allem, was irgendwie mit der Kombination aus "Serverschrank" und "Strom" zu tun hat. Eine schnelle Recherche ergibt etwa, dass die "APC Metered Rack PDU" zu den am weitesten verbreiteten Modellen gehört.

In Sachen Remotemanagement ergeben sich gleich mehrere Möglichkeiten. APC kommt von Schneider, und dieser Hersteller bietet eine eigene Managementsoftware für seine Bauteile an, die allerdings weder Open Source noch kostenlos erhältlich ist. Wer darauf keine Lust hat, findet auf den Geräten eine SSH-Shell vor. Die ist allerdings nicht an eine Standard-Shell wie Bash gekoppelt, sondern benötigt eigene SSH-Befehle.

Fertige Playbooks zum Steuern dieser Geräte gibt es für Ansible im Augenblick zwar nicht. Auf Grundlage der genannten Informationen ist es allerdings recht einfach, sich eine entsprechende Integration in den Automatisierer der Wahl selbst zu schreiben. Zumal sich bei PDUs der zu leistende Aufwand in Sachen Konfiguration ja durchaus in Grenzen hält.

Knackpunkt Terminalserver

Letztlich geht es darum, eine IP zu konfigurieren, um die einzelnen Steckdosen aus der Ferne steuern zu können. Wer auf Ansible keine Lust hat, hat im Falle von APC übrigens auch SNMP als Option zur Auswahl. Ansible bietet gegenüber SNMP allerdings den Vorteil, dass der Admin etwa auch das Einspielen von Firmware auf dem Gerät per SSH gut automatisieren kann, wenn auch spezifisch für die jeweilige Hardware. Gerade das Beispiel APC eignet sich allerdings insofern, als dass es hier auch andere Werkzeuge aus der Open-Source-Community gibt, um beispielsweise die aktuelle Konfiguration abzufragen. PDU-Commander etwa kann die Steckdosen sogar von der Kommandozeile aus steuern [1], und das lässt sich auch hervorragend automatisieren.

Etwas komplizierter sieht die Sache aus, wenn tatsächlich klassische Terminalserver für den Anschluss über die serielle Schnittstelle Verwendung finden. Viele Server habe diese ja schon gar nicht mehr, aber wenn es sie gibt und sie benötigt werden, ist ein Terminalserver meist ebenfalls gewünscht. Zudem sieht die Sache bei klassischen Infrastrukturkomponenten oft anders aus. Die haben nämlich oft noch eine RS232-kompatible Schnittstelle und lassen sich per Terminalserver sinnvoll administrieren.

Hier ist eine generelle Aussage über den Support durch Automatisierungswerkzeuge aber seriös schlicht nicht mehr möglich. Der Administrator tut insofern gut daran, sich idealerweise vor der Anschaffung der Geräte zu informieren und zumindest auf eine SSH-Schnittstelle zu achten. Steht eine SSH-Shell zur Verfügung, lassen sich die Shell-Fähigkeiten der Standardautomatisierer nutzen, und das ist meist die halbe Miete.

Monitoring nicht vergessen

Zur Softwareverwaltung auf Zielsystemen gehört nicht nur das Aktualisieren von deren Software und das Einspielen ihrer Konfiguration. Auch im laufenden Betrieb möchte der Administrator ja wissen, was los ist, und entsprechend gehören Infrastrukturkomponenten ebenso überwacht wie Server auch. Hier spielt eine große Rolle, welche Schnittstellen zur Überwachung die Geräte selbst anbieten. Die Router und Switches der großen Hersteller etwa kommen regelmäßig mit einem Füllhorn verschiedener Schnittstellen, darunter SNMP. Bei Terminalservern oder PDUs sieht die Sache schon etwas anders aus, hier ist oft nur SNMP vorhanden, wenn überhaupt eine standardisierte Schnittstelle zur Verfügung steht. Im schlimmsten Fall muss der Administrator sich seine Integration also selbst stricken.

Hier entscheidet die Wahl des eigenen Systems für Monitoring, Alerting und Trending über Wohl und Wehe. Am Beispiel der Zeitreihendatenbank Prometheus mit dem sie umgebenden Tool-Zirkus etwa impliziert dies das Ausrollen des Push Gateways oder eines entsprechenden Exporters, der SNMP oder ähnliche Interfaces abgrast. Aus den gefundenen Daten muss der Dienst dann Metrikdaten im Prometheus-Format bauen und zur Abholung durch Prometheus bereitstellen. Hier befindet der Administrator sich de facto an der Schnittkante zwischen klassischem Systemmonitoring und der Überwachung von Infrastruktur. Der größere Teil des Konfigurationsaufwands hier fällt aber im Hinblick auf das bereits bestehende Monitoringsystem an, und diesen erledigt der Administrator mit den ihm ohnehin bekannten Werkzeugen.

Fazit

Auch wenn viele Administratoren das Thema Automation und Lifecycle-Management der eigenen Infrastruktur bisher nicht auf dem Schirm hatten, lohnt es sich doch, darüber ausgiebig nachzudenken. Wer einmal eine valide Konfiguration für Switches mit Cumulus Linux entwickelt hat, rollt diese auf beliebig vielen Geräten in beliebig vielen Racks aus. Der in die Automatisierung investierte Aufwand rentiert sich also umfänglich. Dabei greift nicht unbedingt das Prinzip "All or Nothing". Der Administrator muss nicht sofort seine gesamte IT-Infrastruktur beackern, sondern kann sich auf einzelne Teilbereiche beschränken und sich schon dadurch das Leben erheblich leichter machen.

Auch die Sorge vor ungewollter Fehlkonfiguration muss keine Sorge bleiben. Hier ist sinnvolle Planung nötig: Wer Angst hat, sich das Managementinterface zu einem Switch abzuschießen, geht ruhiger an die Sache, wenn er über einen an autarker Netzwerkinfrastruktur angeschlossenen Terminalserver verfügt. Denn über diesen ist selbst im Falle einer totalen Switch-Fehlkonfiguration der Zugang noch möglich. Obendrein lässt beispielsweise Ansible sich so fein granuliert verwenden, dass es auch möglich ist, eine Konfiguration zwar auszurollen, aber das händische Aktivieren durch den Administrator nach Prüfung geschehen muss.

Infrastruktur verwalten und automatisieren