Horrorgeschichten mit Cluster

Die folgenden Dinge sind mir oder meinen Kollegen in unserer Tätigkeit als Consultant und Troubleshooter passiert. Natürlich sind die Kunden und Personen anonymisiert. Die Seite soll daher kein Pranger darstellen sondern aufzeigen, dass Fehler schnell passiert sind: und ich nehme mich hier auch nicht davon aus. Jeder hat eine Lernkurve. Die Frage ist nur wie viel man selbst in Testfeldern oder Schulungen lernt bzw. wie gut man beim Kunden vorbereitet sein kann.

NetWare SFT III und die Konsole

Verfügbarkeit ist nicht erst seit Windows NT4 mit dem Cluster Server ein Thema. Auch NetWare 3.x, 4.x etc. haben die Verfügbarkeit mit verschiedenen "System Fault Tolerance" (SFT)-Stufen hoch gehalten. Die Krone war SFT III, bei der zwei identische Server über einen "Mirrored Server Link" (MSL) sich permanent abgeglichen haben. Dazu wurde auf jeden Server ein Grundsystem geladen (IOEngine), welche die Hardware (LAN, DISK) angesteuert hat. Darauf wurde die MSEngine gestartet, die auf beiden Systemen in Echtzeit identisch ausgeführt wurde und die Dienste (NDS, Datei, Druckdienste) angeboten hat. Entsprechend hatte der Server drei Konsolen, die auch von allen beiden Tastaturen direkt erreichbar waren.

Wenn man es nicht oft gemacht hat, dann konnte man schon mal auf der falschen Konsole den Befehl "HALT" oder "DOWN" eingetippt hat. Ein HALT war nur auf der IOENGINE möglich und hat diese Engine beendet. Der virtuelle Server (MSENGINE) lief auf dem anderen Server weiter. Ein DOWN auf der MSENGINE hat aber beide Systeme beendet. Das war um so verwirrender, da ein DOWN auf einem einfachen Server eben auch nur diesen herunter gefahren hat.

Es ist mehr als einmal passiert, dass ein Admin nur den einen Knoten beenden wollte aber wohl aus Gewohnheit mit einem DOWN beide Systeme herunter gefahren hat. Trotz dieser Missgeschicke war das Prinzip der SFT III von NetWare sehr robust und der Server hat viele Jahre (>8 !!) seine Dienste verrichtet, auch wenn er die letzten Jahre nur noch als einsamer Server verbracht hat, weil der zweite Knoten komplett ausgefallen ist und es einfach keine Ersatzteile mehr gab.

Cluster mit Terminal Dienste

Gefürchtet waren die Administratoren, die einen HP Deskjet-Drucker der frühen Generation an ihrem Arbeitsplatz angeschlossen hatten und dann per Terminaldienste auf den Server zugegriffen hatten. Die "Druckfreigabe" per RDP hat dann regelmäßig dazu geführt, dass der Cluster versucht hat, den Druckertreiber für den Administrator zu laden. Dumm nur, dass genau der Treiber im Windows Lieferumfang nicht Clustertauglich war und durch die ungeschickte Einbindung eines Portmonitors für einige Bluescreens verantwortlich war.

Ich nutze heute auch noch mit Vorliebe RDP, um einen Cluster aus der Ferne zu verwalten. Aber auf jedem Server schalte ich ab, dass Clientdrucker und Laufwerke verbinden werden. Damit erspare ich mir nicht nur die hässlichen Warnmeldungen im Eventlog, sondern auch Laufwerkskonflikte bei großen Clustern und per Autorun gestartete Programme.

Cluster geliefert und Tschüss

Bei einem Kunden haben wir eine ganz seltsame Situation erlebt. Wir haben einen Anruf erhalten, ob wir denn auch Exchange als Cluster installieren könnten und möglichst schnell. Wunderlicher wurde das ganze dann noch als bekannt wurde, dass die Hardware schon komplett vor Ort stehen würde.

Erst nach einiger Zeit ist dann heraus gekommen, dass ein anderer Lieferant wohl den Zuschlag für die Lieferung bekommen hat, auch geliefert hat und die Rechnung dazu schon bezahlt wurde. Als es dann aber an die Installation gegangen ist, hat er sich wohl achselzuckend davon gemacht und die zweite Hälfte des Auftrags (die Installation selbst) nicht mehr durchgeführt und natürlich auch nicht berechnet. Vermutlich hatte er schon seinen Verdienst an der Hardware realisiert.

Ich möchte mich nun nicht darüber auslassen, wie man als Auftraggeber sich hier verhalten kann. Schließlich verdiene ich mit Hardware sowieso nichts und die Dienstleistung konnte ich problemlos erbringen. Allerdings waren schon noch einige Kompromisse nötig, da die Dimensionierung der Hardware alles andere als "angemessen" war. So hatte der erste Lieferant vorgesehen, dass die Exchange Transaktionsprotokolle auf lokalen Festplatten vorliegen sollten und nur die Datenbanken im SAN abgelegt werden. So kann zumindest ein Exchange 2000/2003 Cluster nicht funktionieren.

Ein Cluster in a Box

Da kommt man zu einem mittelständischen Betrieb und soll eigentlich nur ein Exchange Problem lösen. Nach einem kurzen Blick hat es mir aber schon etwas die Sprache verschlagen. Die komplette Struktur der Firma war auf einem Compaq CL380 System aufgebaut. In den Jahren 2001 (?) hat Compaq solche Server verkauft, die in einem Gehäuse zwei Server und einen shared Storage untergebracht haben. Das Ziel solcher Systeme ist weniger die Hochverfügbarkeit bei Hardwaredefekten, weil die Server dazu doch "zu nahe" beisammen stehen (gemeinsame Anschlüsse etc.) sondern eher die Verfügbarkeit während Wartungsarbeiten hoch zu halten.

Aber dass ein Lieferant dem Kunden "genau ein" System verkauft und dann beide Knoten zu Domain Controllern (not supported) macht und dann noch Exchange und SQL installiert (jeweils auf einem Knoten aktiv), hat mir schon etwas die Sprache verschlagen. Das ist weit weg jeder empfehlenswerten Konfiguration. Es gab sonst KEINE weiteren Windows Server in diesem LAN. Das ist dann wohl eine mangelhafte Leistung des "Dienstleisters"

Missbrauch der Quorum Disk

Windows 2003 kann ja mittlerweile auch ohne Quorum Disk auskommen. Aber die meisten Windows Cluster dürften immer noch mit gemeinsam genutzten Festplatten arbeiten. Auch das Quorum ist einfach eine Festplatte mit einer NTFS-Partition. In vielen Umgebungen ist diese Disk nicht nur die paar benötigte Megabyte Groß, sondern ein paar Gigabyte. So haben einige SAN-Systeme das Problem, dass die Partitionen nicht beliebig sein können, sondern immer ein vielfaches einer logischen Festplatte. Das können 9 GB sein, bei einigen Systemen sind dies aber auch locker mal die kleinste Festplatte im SAN (z.B. 73 GB).

Da liegt es natürlich nahe, diesen kostbaren Speicher nicht einfach brach liegen zu lassen, sondern als Dateifreigabe oder für Daten zu nutzen. Prinzip bedingt produziert der Cluster auf der Quorumdisk nicht wirklich viel IO, so dass der sparsame Administrator hier noch ein paar Ressourcen gewinnen kann.

Gewonnen haben diese Administratoren aber eher ein instabiles System. Es ist mehr als einmal passiert, dass ein Cluster nicht mehr funktioniert hat, weil eben die Quorumdisk voll geschrieben war. Seit Windows 2003 R2 können die Diskquotas zum einen helfen, solche von vollschreiben zu verhindern und zudem rechtzeitig zu warnen. Grundtenor bleibt aber, dass ein Cluster nur dann sinnvoll ist, wenn er für seine Aufgabe exklusiv genutzt wird. Zum Glück kann man seit Exchange 2007 auf die Quorumdisk verzichten (Majority Node Set)

Das vergessene LAN

Manchmal werde ich auch von bislang unbekannten Firmen für ein oder zwei Tage zu einem "Audit" gerufen. Da möchte ein Geschäftsführer oder IT-Leiter dann einfach eine dritte unabhängige Meinung hören und verhindern, dass die Administratoren betriebsblind werden. Besonders interessant ist das natürlich in Verbindung mit "hochverfügbaren" Exchange Servern.

Eins vorneweg: Es gibt eigentlich keine perfekten Netzwerke, denn wer sucht, wird immer etwas finden, was man selbst anders (besser) machen würde. ein TÜV-Prüfer oder Polizist kann immer etwas finden, wenn er etwas finden will.

Wenn ein Kunde aber Clusterknoten in zwei Rechenzentren aufstellt und das SAN auch noch über zwei Storage-Einheiten verteilt und diese replizieren lässt. (was alles eine Stange Geld kostet), dann kann man schon mal übersehen, dass die Mitarbeiter selbst, die letztlich den Server nutzen, nicht davon haben.

Das passiert nämlich dann, wenn zwar Server und SAN alle doppelt und verkreuzt angebunden sind, aber die Etagenverteiler der LANs zur den Arbeitsplätzen eben nicht bis in das zweite entfernte Rechenzentrum verbunden sind. Es gab in den letzten Jahren gleich mehrere Firmen, mit denen ich theoretisch das Szenario "Primäres RZ fällt aus" durchgespielt habe. Und relativ oft wurde dann bemerkt, dass die Cluster zwar alle im anderen RZ funktionieren würden, nur dass die Mitarbeiter keine Verbindung dort hin mehrhatte, da der verbindende Switch nur im Haupt-RZ gestanden hätte. Eigentlich eine Kleinigkeit mit großer Wirkung.

Die zweite Disk

Fatal sind immer die Probleme mit müssenspeichern, bei denen wirklich ein Datenverlust aufgetreten ist. Zwar hoffe ich mittlerweile für alle Leser, dass alle Server über redundante Massenspeicher verfügen (RAID5, RAID10 o.ä.). Genauso wichtig ist aber auch die Überwachung dieser Systeme damit es ihnen nicht so geht, wie anderen Firmen, bei denen wir letztlich ein Restore der Datenbank durchführen müssen. Was ist passiert ?: Nun ja eine Festplatte des RAID-Verbunds ist ausgefallen. An sich noch kein Beinbruch, wenn es eine HotSpare gibt oder Administrator den Ausfall durch Nachstecken einer Ersatzplatte behebt. Fatal wird es, wenn es die zweite Festplatte in einem RAID5 ist, weil der Ausfall der ersten Festplatte einige Wochen zuvor keinem aufgefallen ist.

Es ist nicht ausreichend, ab und an mal durch die Serverreihen zu gehen und zu schauen, ob alle LEDs grün sind. Ein Server kann und MUSS Sie informieren, wenn Defekte auftreten, auch wenn er diese selbst beheben oder überbrücken konnte. Das betrifft Festplatten genauso wie redundante Netzwerklinks, Netzteil oder Speicherriegel.