Außer Rand und Band

Sie führen ein Schattendasein, doch ohne sie ließe sich keine IT-Infrastruktur in Gang halten: die Konsolen-server. Einst eine Domäne namhafter Spezialisten, ist der Markt inzwischen dank Open Source heiß umkämpft. Sieben Geräte der Oberklasse mit mindestens 32 Ports stellten sich dem Vergleich.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Dirk Wetter
Inhaltsverzeichnis

Wer im Rechenzentrum alle Komponenten unter Kontrolle halten möchte, kommt um klassische serielle Verbindungen nicht herum - ob es um Server, Router, Firewalls, SAN-Komponenten (Storage Area Networks), unterbrechungsfreie Stromversorgungen (USV), Telefon- und Klimaanlagen oder gar dafür ausgelegte Steckdosenleisten geht, letztlich sind sie im Krisenfall nur per serieller Konsole steuerbar. Bei heutigen Installationen von Rechenzentren und IT-Strukturen steht vor allem die ständige Überwachung im Vordergrund und dazu braucht es Server, die solche seriellen Konsolen über eine Fernverbindung bereitstellen: Konsolenserver.

Die Testumgebung im Firmenlabor des Autors sollte solche Geräte nicht vor unlösbare Aufgaben stellen: Als Hardware standen ein Cisco-Catalyst-Switch, ein Server-PC und ein Ultra-Sparc-Server zur Verfügung, der die heutzutage übliche Break-Festigkeit („Solaris Ready“) verifizieren sollte. Zum Hintergrund: Bestimmte Sparcs (wie SGIs) missinterpretieren fatalerweise bei einem Stromausfall eines Konsolenservers die Signalkurve auf den 12-V-Zweigen der RS-232 als Befehl, sich in den „OK“-Prompt zu begeben. Glücklicherweise passiert das nicht mehr bei allen Sparcs, bei neueren Solaris-Versionen kann ein Patch dem abhelfen.

Bei Exemplaren mit zwei Netzteilen sollte das Steckerziehen eines Stromzweiges einen Stromausfall simulieren. Dass die Kandidaten nach einem Stromausfall wieder sauber hochfahren, ist nicht selbstverständlich: Es gibt zwar ein jffs (journal based flash file system) oder ähnliche Dateisysteme, doch nicht alle Konsolenserver verwenden sie. Der Stromausfalltest fand mindestens 10-mal statt. Außerdem harrten für Modelle mit PCMCIA-Slot drei PCMCIA-Karten (CF-Adapter, 3Com-Modem- und Linksys-Ethernet-Karten) ihres Einsatzes.

Zur Zeitsynchronisation sollte ein NTP-Server (Network Time Protocol) konfigurierbar sein und der Konsolenserver das Umleiten des Syslog auf einen zentralen Server zulassen. Dem Benutzer vor Ort müssen die Geräte zwei der 32 bis 48 Ports zur Verfügung stellen können. Die IP-Adressen vergibt ein DHCP-Server im Labor.

Für die Kür stand ein LDAPv3-Server inklusive „normalem“ SSL und TLS-Upgrade-Option im Labor bereit, um weitere Testbenutzer zu authentifizieren. Die meist in größeren Netzen anzutreffenden Authentifizierungsverfahren wie TACACS+ (Terminal Access Controller Access System) oder Radius [2] blieben aus Zeitmangel außen vor. Hie und da unterstützen Konsolenserver zwar NIS, es ist aber für Konsolenserver zu unsicher - ypcat -d <NIS-Domain> passwd gibt die via schwachem DES verschlüsselten Passwörter preis.

Fernwartungen sollten nur in einer kontrollierten Umgebung über ein dediziertes physikalisches Admin-Netz „out-of-band“ stattfinden. Anderenfalls droht der GAU, wenn etwa ein Unbefugter durch „vergessene“ Root- oder Admin-Sitzungen am seriellen Zweig des Konsolenservers die Herrschaft über einen Server, Router, eine USV oder gar eine schaltbare Steckdosenleisten übernimmt.

Da die Voraussetzungen schlimmstenfalls aufgrund von Nachlässigkeit nicht immer realisiert sind - wenn man weiß, wonach und wie man suchen soll, findet man sogar Web-GUIs von Konsolenservern im Internet via Google -, lag ein besonderes Augenmerk auf den Sicherheitsmerkmalen: Erschienen die Konsolen als offene Telnet-Ports oder gar ohne Authentifizierung, gab es Punktabzug. Als Standard gilt heutzutage ein authentifizierter wie verschlüsselter Zugang per SSHv2.

Aus ähnlichen Gründen sind nicht mit SSL verschlüsselte Webserver, im Klartext kommunizierende Applets und Telnet-Admin-Zugänge zum Konsolenserver eine Sünde, besonders in der Werkskonfiguration: Der Hersteller bestraft so alle mit einem erhöhten Risiko. Verhängnisvoll sind ererbte Root-Sitzungen, die mit einer Portauthentifizierung in den Griff zu bekommen sind. Ein Idle-Logout des Ports am Konsolenserver oder beim „Endgerät“ kann zusätzlich helfen.

Weitere Laborversuche beschränkten sich auf Stichproben, darunter die Untersuchung des SNMP-Monitoring und der -Traps.

Einst proprietäre Betriebssysteme der Konsolenserver wie Xyplex Maxserver, Cisco 2511 und Lantronix SCS 3200 sind Linux-basierten Lösungen gewichen, was die Entwicklungsarbeiten dank offener Quellen vereinfacht, die es bei sonst nicht ganz trivialen Zusatz-Features wie Firewall, Unterstützung von PCMCIA oder Modems für die Geschmacksrichtungen seines „embedded Linux“ lediglich anzupassen gilt. Administratoren schätzen es, wenn sie die Funktionen des Geräts auf der Kommandozeile - falls vorhanden - transparent steuern können und ihnen damit die Einarbeitung leichter fällt als früher. Sonderwünsche kann man sich mit (Cross-)Entwicklungsumgebungen für den Konsolenserver erfüllen. Ein brandheißes wie häufig vernachlässigtes Thema beim Umgang mit Linux: Die Beachtung des GNU-Copyrights.

Angefangen hat der Linux-Boom bei den Konsolenservern vor ein paar Jahren, als die Firma Cyclades ihre TS-Serie ins Rennen schickte, was sich gut auszahlte. Mittlerweile hat der Hersteller Konkurrenz bekommen, da viele neue Hersteller auf der Bildfläche erschienen sind, die gerne im Linux-Konsolenserver-Geschäft mitmischen wollen.

Sieben Linux-betriebene Topmodelle mit mindestens 32 Ports bilden das Testfeld. Angetreten sind Cyclades, Digi, Thinklogical, Lantronix, MRV, Raritan und Avocent.

Den vollständigen Artikel finden Sie in der Print-Ausgabe der 8/2005. (rh)