Basisarbeit für erfolgreiche Failover-Strategien Kampf dem Split Brain – die Rolle des Netzwerks in High Availability Clustern

Wird über Hochverfügbarkeit in verteilten IT-Landschaften (HA-Cluster) gesprochen, ist oft nur die Verfügbarkeit innerhalb eines Computersystems gemeint. Damit ein Failover der Computersysteme und Applikationen funktioniert, muss aber auch die Netzwerkverbindung zwischen den Clustern-Knoten stets verfügbar sein.

Anbieter zum Thema

ALE Deutschland GmbH

Vogel IT-Medien GmbH

Vitel GmbH

Das Fühlen des Pulsschlags gehört beim Notarzt-Einsatz und vielen Diagnosen zu den allerersten Maßnahmen. Auch in einem HA-Cluster (High Availability, Hochverfügbarkeit) ist der Pulsschlag aussagekräftig, wenn die Gesundheit der Knoten und des Netzwerks überprüft werden soll.

Herzschlag und Reflexe liefern wichtige Aussagen über den Zustand eines Organismus – oder eines Netzwerks, denn vielleicht ist der für ein Failover vorgesehene Cluster-Knoten nicht erreichbar. Die Ursachen können vielfältig sein: ein Mitarbeiter hat einen Switch ausgewechselt, der Knoten hat sich einfach aufgehängt oder ein Netzwerk-Controller beendet sein Dasein.

Nicht nur technische Probleme können die Verbindungen zwischen den Knoten stören: Die Ausdehnung der IT-Infrastruktur und immer neue Rechner können das HA-Cluster-Konzept aushebeln. Cluster-Dienste identifizieren Netzwerke unter Umständen nur bei der Installation eines Knotens über eine Netzwerk-ID, bestehend aus der Subnetzmaske und IP-Adressen.

Schnell entsteht eine Situation, für die sich der Begriff „Split Brain“ durchgesetzt hat. Split Brain beschreibt eine Situation, bei der ein Cluster-Knoten keinen anderen Knoten mehr sehen kann, gerade so, als ob die Verbindung zwischen der linken und der rechten Gehirnhälfte unterbrochen wäre. Die Split-Brain-Situation muss in jedem Fall vermieden werden.

Ebenfalls typisch: Das Netzwerk steht, der Netzwerk-Controller behauptet, alles sei in bester Ordnung. Trotzdem ist der Knoten nicht erreichbar.

Hausmittel

Gegen die typischen Unwägbarkeiten in Hochverfügbarkeits-Clustern gibt es Mittel und Konzepte. Helfende Software-Pakete stehen sowohl als Open-Source-Tools als auch als kommerzielle Lösungen zur Verfügung. Oft greifen konzeptionelle Hausmittel aber schon bei der Konzeption des HA-Clusters.

Zu den wichtigsten Maßnahmen gehört es, einen HA-Cluster nicht über das allgemeine LAN zu konfigurieren, schon gar nicht über das Subnetz des allgemeinen Netzwerk-Traffics. Ein separates Subnetz mit hoher Priorität und im Idealfall ein separates physisches LAN sind für einen HA-Cluster wichtig.

Ist der HA-Cluster gut konzipiert und konfiguriert, sind Überwachungsmaßnahmen erforderlich. Verbreitet ist dabei die Open-Source-Technik „Heartbeat“. Mit diesem Verfahren prüfen die Cluster-Knoten in regelmäßigen Abständen, ob die anderen Knoten noch erreichbar sind.

Separate Verbindung für Diagnosen

Für den Heartbeat wird eine Nachricht sowohl über TCP/IP-Verbindung als auch über die serielle Schnittstelle versendet. Kommen von einem Knoten keine Nachrichten mehr, gilt dieser als ausgefallen. Darauf kann mit geeigneten Maßnahmen reagiert werden, beispielsweise durch ein Failover auf den Knoten, der noch erreichbar ist.

Die Verbindungen für den Heartbeat müssen redundant und im Idealfall über alle vorhandenen Netzwerk-Interfaces aktiv sein. Am besten, man setzt mehrere dedizierte Netzwerk-Interfaces für die Heartbeats ein. Das Netzwerk darf dabei nur so viele aktive Komponenten haben, wie unbedingt nötig, um Fehlerquellen auszuschließen. Das Heartbeat-Netzwerk sollte zudem autonom sein. Dazu zählt vor allem, dass die Heartbeats nicht in vorhandene Spanning-Tree-Architekturen eingeschlossen werden, damit Ausfälle durch einen Spanning-Tree-Reconfigure vermieden werden.

Der Herzschlag der Applikationen

Allerdings genügen Heartbeat und ähnliche Werkzeuge zur Überwachung von HA-Clustern nicht allein. Damit Applikationen hochverfügbar sind wird Heartbeat deshalb mit Lösungen wie Lifekeeper von Steeleye kombiniert.

Lifekeeper überprüft die Funktion des Netzwerkes durch einen Broadcast-Ping. Solange ein anderer Knoten als der eigene auf das Ping antwortet, funktioniert das Netzwerk. Es ist ebenfalls möglich, direkte Ping-Listen zu hinterlegen. Dabei ist es wichtig, dass immer mehrere Ping-Targets eingetragen werden, um auch hier das Ping-Ziel als SPOF (Single Point of Failure) auszuschließen. Da Lifekeeper keine ganzen Netzwerk-Interfaces (einschließlich der MAC-Adresse) im Cluster schwenkt, führt er nach einem Failover einen so genannten Gratuitous Arp Request, einen Broadcast im Ethernet, aus. Dadurch stellt er sicher, dass nach Umzug der virtuellen IP auf ein neues Interface – und damit der Änderung der zur VIP gehörigen MAC Adresse – alle Clients nach dem Failover mit dem richtigen Knoten kommunizieren.

Auf Teaming- und Bonding-Funktionalitäten im Betriebssystem oder den Netzwerk-Treibern kann die Lifekeeper-Lösung ebenfalls zurückgreifen. Hier werden Ausfälle bereits auf Ethernet-Ebene und in wenigen Sekunden transparent abgefangen. Dies vermeidet Cluster-Failover und erhöht damit die Verfügbarkeit des Netzwerks.

Für alle Überwachungsmaßnahmen ist aber auf jeden Fall die korrekte Konfiguration des Netzwerks wichtig, damit den positiven Rückmeldungen der Funktionstests nicht nur ein „Kabel steckt“ zugrunde liegt.

(ID:2005686)