„All IP“: Ein Schlagwort, das mancher Provider für die Umstellung der eigenen Infrastruktur auf das Internet Protocol (IP) gewählt hat, ist seit Jahren Programm. Ob klassische Telefonie oder vernetzte Dinge, ob Sensoren oder Industrienetze, seit Jahren sind wir Zeugen und Gestalter eines anhaltenden Trends weg von Nicht-IP- zu IP-Kommunikation.
Dieser Trend wurde mit der Pandemie noch beschleunigt. IP ermöglicht universelle Kommunikation, weil DAS weltweite Internet darauf basiert. Das Internet rettete uns über die Pandemiezeit. Über IP können wir von überall auf fast alle digitalen Ressourcen und Dinge zugreifen. IP hat Social Distancing ermöglicht, und somit die Kontinuität vieler notwendiger Abläufe auch zu Zeiten, in denen sich Menschen nicht wie gewöhnlich bewegen durften.
Damit die IT als Rettungsanker funktioniert, muss sie selbst aufgebaut, installiert, konfiguriert und in Betrieb genommen bzw. gehalten werden. Und siehe da: Auch dabei hilft das Internet Protocol. Ganze Rechenzentren können – notwendige Vorkehrungen vorausgesetzt – betrieben und am Leben gehalten werden, ohne dass außer für mechanischen Auf-, Um- oder Abbau eine Tätigkeit vor Ort erforderlich wird.
Es gibt Ausnahmen von dieser Regel. IT-Komponenten müssen erstmal IP-fähig gemacht werden. Als ich vor 35 Jahren bei ComConsult als Mitarbeiter angefangen habe, gehörten zu den ersten zu lernenden Dingen die Schritte, die wir beim Aufbau eines Netzgeräts unternehmen mussten. Es galt nicht nur, die Hardware zu bestücken, zu verkabeln und an das Stromnetz anzuschließen, sondern sie auch mit einer IP-Adresse zu versehen, damit sie über das Netz erreichbar und die weitere Konfiguration möglich wurde. Es gab zwar BOOTP und später das darauf basierende Dynamic Host Configuration Protocol (DHCP), mit dem auch ein Netzgerät durch Kommunikation mit einem Bootserver automatisch IP-fähig gemacht und mit einer erreichbaren und passenden Adresse versehen werden konnte. Jedoch war das „Booten über das Netz“ bei Netzgeräten wie Brücken und Routern nicht üblich. Schließlich mussten diese Komponenten aufgebaut werden, damit man überhaupt ein Netz hatte. Daher wurde zum Beispiel mit jedem Router ein serielles Kabel geliefert. Dieses passte zu einer Konsolenschnittstelle des Routers. Ein PC oder Terminal war über dieses Kabel mit dem Netzgerät zu verbinden. Vom Terminal oder vom PC mit einem Terminalprogramm aus wurde in der Regel mittels des RS-232-Protokolls auf das Netzgerät zugegriffen, das nach dem Booten über die serielle Schnittstelle ein Menü für die initiale Konfiguration anzeigte. Dann konnte es losgehen.
Bis heute können wir diese Möglichkeit nutzen. Hinzu gekommen sind andere Möglichkeiten, zum Beispiel das besagte Booten vom Netz und DHCP. Netzgeräte wie Switches, Router, Firewalls und Load Balancer haben in der Regel eine Ethernet-Schnittstelle speziell für administrative und Management-Zugriffe. Das haben Server normalerweise auch. Im Gegensatz zu den meisten Server-Administratoren möchten jedoch viele Netzadministratoren trotz Möglichkeiten zum Management über Ethernet und IP auf die serielle Schnittstelle am Gerät nicht verzichten. Das hat nicht nur mit Gewohnheit zu tun. Es gibt zwei mir auf Anhieb einfallende Situationen, in denen das serielle Interface verfügbar sein sollte. Aus Sicherheitsgründen erfordert das „Factory Reset“ oder „Password Reset“ in der Regel den Zugriff über das serielle Interface, damit ein solcher Schritt nicht über das potenziell unsichere IP-Netz erfolgen kann. Die zweite Situation gibt es dann, wenn man anhand der Meldungen des Geräts über die serielle Konsole die Ereignisse beim Booten verfolgen will. Es existieren nämlich Meldungen, die man nur an der seriellen Konsole verfolgen kann und sonst nicht. Boot-Vorgänge müssen manchmal auch analysiert werden. Sie werden immer länger, weil die Software der Komponenten immer komplexer wird. Wenn es ein Problem mit dem Booten gibt, oder wenn es gilt, beim Booten einzugreifen, so wie beim Zurücksetzen des Passworts oder der gesamten Einstellungen, wird häufig die serielle Schnittstelle benötigt.
Also doch die Turnschuhe anziehen und zum Gerät laufen, wie im letzten Jahrtausend? Nicht wenn man vorgesorgt hat. Hersteller wie Cisco, Lantronix, OpenGear, Perle und Vertiv bieten Konsolenserver an. Diese sind über eine IP-Schnittstelle erreichbar, zum Beispiel über ein Admin-Netz und solche Protokolle wie Secure Shell (SSH) und Hyper-Text Transfer Protocol Secure (HTTPS). Zusätzlich haben diese Geräte serielle Interfaces, die mit den zu administrierenden Geräten verbunden werden können. Über IP gelangt man zu einem Auswahlmenü für die seriellen Schnittstellen.
Die Notwendigkeit redundanter Rechenzentren geht oft damit einher, dass die Komponenten mindestens in einem RZ von Ferne administriert werden müssen. Sind die Netzkomponenten in dem entfernten RZ so vorverkabelt, dass man zur Not über die Konsolenserver auf die seriellen Schnittstellen der Geräte zugreifen kann, können Vor-Ort-Arbeiten auf mechanische Schritte beschränkt werden, für die man kein gerätespezifisches Know-how benötigt. „Helping Hands“ vor Ort, zum Beispiel Hauselektriker, können solche Arbeiten übernehmen.