Hochverfügbare Cluster unter Linux und Solaris
Failover mit dem Pinguin
Die Linux-Anbieter haben den Rechenzentrumsmarkt für sich entdeckt. Dort können sie vor allem mit hochverfügbaren und ausfallsicheren Lösungen punkten, die es vielfach als offene und kommerzielle Variante gibt. Sun Microsystems will mit einer eigenen Strategie Paroli bieten.
Linux-Cluster bestehen typischerweise aus Standardcomputern auf Intel- oder AMD-Basis, den
Knoten also, wobei auf jedem ein Betriebssystemkern läuft und physikalischer Speicher nicht
gemeinsam genutzt wird. Jeder Knoten kann folglich auch unabhängig von den anderen arbeiten. Damit
unterscheiden sich diese Verbünde von NUMA- (Non-Uniform Memory Access) oder SMP-Plattformen
(Symmetric Multiprocessing). Der Vorteil des gemeinsamen Betriebs mehrerer Systeme auf Linux-Basis
liegt neben einem guten Preis-Leistungs-Verhältnis in den Möglichkeiten, hohe Verfügbarkeit und
Leistung sowie Load Balancing zu erzielen.
Kategorien von Clustern
Nach diesen Kriterien wurden die Cluster häufig in der Vergangenheit kategorisiert. Doch zeigt
sich, dass heutige Lösungen, unabhängig davon, ob es sich um Open Source oder kommerzielle Software
handelt, meist alle drei Merkmale in sich vereinen. Dennoch gibt es einige typische Beispiele für
jede Art, die zumeist aus älteren quelloffenen Projekten stammen. Dazu gehört Beowulf als älteste
Software für das Hochleistungs-Computing, das Mosix-Projekt für Load Balancing oder HA-OSCAR für
Hochverfügbarkeits-Cluster (siehe auch LANline 11/2004, "Quelloffene Aufgabenteilung", Seite
88).
Gerade die Hochverfügbarkeit der Anwendungen ist ein wesentliches Merkmal von Clustern, das
bereits durch eine inhärente Redundanz der Bestandteile im Verbund gegeben ist. Die meisten
Cluster-Lösungen bieten Mechanismen, die erkennen, wenn ein Knoten ausfällt und dafür sorgen, dass
ein anderer dessen Arbeit übernimmt. Darüber hinaus bieten auch Cluster-Dateisysteme einige
Funktionen, die Hochverfügbarkeit garantieren. Üblicherweise werden sie als eine Art "Wrapper" um
reguläre Dateisysteme herum implementiert, kommunizieren über das Netzwerk miteinander, um ihre
Aktivitäten zu synchronisieren und verwenden dasselbe SAN oder spezielle "Cluster-interconnect"
-Geräte. Typische Funktionen sind der Journaling-Mechanismus, der alle Aktionen festhält, und ein
Lock-Manager, der die verbundweiten Zugriffe auf die Daten im weitesten Sinne regelt. Die
bekanntesten Cluster-Dateisysteme sind GFS (Global File System) mit der quelloffenen Variante
OpenGFS und dem von Redhat eingesetzten von Sistina erworbenen kommerziellen Pendant (ebenfalls
GFS). Außerdem gibt es GPFS (Generalized Parallel File System) von IBM, das Cluster File System
(CFS) von Polyserve sowie Sun Cluster.
HA Linux
Das wohl bekannteste quelloffene Hochverfügbarkeitsprojekt ist High Availability Linux (HA
Linux) mit Heartbeat. Diese Hauptkomponente des Projekts implementiert serielle, UDP- und
PPP/UDP-Heartbeats zusammen mit der Übernahme von IP-Adressen.
Für große Cluster mit bis zu 32 Knoten und gemeinsam genutztem Storage eignet sich die
Hochverfügbarkeitssoftware Lifekeeper (für Linux, Windows und Solaris) von Steeleye. Die einzelnen
im Cluster geschützten Ressourcen können parallel und nicht nur sequentiell wieder in Betrieb
genommen werden. Lifekeeper bietet mit mehrfachem und kaskadierendem Failover einen hohen
Ausfallschutz. Dies bedeutet, dass eine Anwendung bei einem Serverausfall auf einen anderen
geleitet wird und bei dessen Ausfall wiederum auf einen nächsten gelegt werden kann.
Linux Failsafe ist eine von SGI entwickelte und gemeinsam mit Suse auf Linux portierte Software.
In Verbünden mit bis zu 16 Knoten übernimmt sie über einen Resource-Manager die Aufgabe des
Failovers der betroffenen Anwendungen. Verschiedene Plug-ins, etwa für IP-Adressen, Dateisysteme,
Apache oder NFS, bieten anwendungsspezifische Schnittstellen zwischen Failsafe und den
Applikationen beziehungsweise Ressourcen, die hochverfügbare Funktionalität verwalten.
Die oben vorgestellten Lösungen (weitere im Kasten rechts) enthalten nur einige der Komponenten,
die ein High-Availability-Cluster benötigt. Eine vollständige Lösung sollte möglichst viele der
folgenden Komponenten enthalten: Membership Services, Communication Services, Cluster- und
Resource-Management und Monitoring.
Redhats Cluster-Suite
Eine umfassende Hochverfügbarkeitslösung für Linux-Verbünde bietet Redhat mit der Cluster-Suite.
Das Produkt steht unter der GPL (General Public License) und stellt einen Zusatz für Enterprise
Linux AS (Advanced Server) und ES (Enterprise Server) dar. Die Lösung bietet zwei Hauptfunktionen:
Der Cluster-Manager soll die Hochverfügbarkeit im Cluster gewährleisten, während sich IP Load
Balancing (ursprünglicher Name "Piranha") um die Lastverteilung im Netzwerk kümmern soll.
Der Cluster-Manager verwaltet eine Failover-Infrastruktur, die laut Firmenangaben Anwendungen
verwaltet, die ohne Veränderungen in der Cluster-Implementierung laufen können. Die Software
unterstützt Verbünde mit bis zu acht Knoten. Voraussetzung ist deren Verbindung zu demselben
externen und gemeinsam genutzten Storage-Subsystem mit SCSI- oder Fibre-Channel-Verbindung. Alle
Cluster-Mitglieder haben Zugriff auf denselben Speicher. Fällt ein Knoten aus, so montiert der
Cluster-Manager die betroffenen Partitionen auf einem anderen Knoten, konfiguriert dort die
IP-Adressen und startet die Anwendung in der gleichen Umgebung wie auf dem ursprünglichen Server
neu.
Die Lösung unterstützt Active/Active-Cluster mit mehreren voneinander unabhängigen und über die
Knoten verteilten Anwendungen oder auch Active/Passive-Verbünde. Letztere Art von Failover-Cluster
eignet sich gut für sehr große Anwendungen, die auf einem einzelnen Server laufen, während ein
weiterer lediglich beim Ausfall des aktiven einspringt. Der Cluster-Manager ist nicht nur für das
Applikations-Failover im Fall von Hardwareproblemen oder -ausfällen zuständig, sondern überwacht
auch die Anwendungen auf eine ordnungsgemäße Funktion und startet diese bei einem Ausfall
erneut.
Da Standardanwendungen meist keine gleichzeitigen Zugriffe auf ihre Daten von mehreren Systemen
aus erlauben, kann auch nur ein Serverknoten zurzeit auf eine Speicherpartition zugreifen. Um
diesbezügliche Konflikte zu vermeiden, gibt es Kontrollskripte, die dafür sorgen, dass zu einem
bestimmten Zeitpunkt lediglich ein Server eine bestimmte Partition montiert. Dennoch können
Situationen auftreten, in denen ein Server diese Skripte umgeht und unerlaubterweise eine Anwendung
startet, die bereits auf einen anderen Server ausgelagert wurde. Dies verhindert der
Cluster-Manager durch so genannte I/O-Barrieren. Die Software verwendet dafür zweierlei
Mechanismen: programmierbare Netzschalter und Watchdog-Timer. Letztere werden auf jedem Server
installiert und stoßen ein Shutdown an, falls das System "hängt", nämlich den Timer nicht korrekt
aktiviert.
Andere Hochverfügbarkeitslösungen verwenden als Barriere beispielsweise SCSI-Reservierungen.
Diese Mechanismen erlauben es einem Server, eine ganze Speicherplatte für sich zu reservieren,
sodass kein anderes System diese Platte ansprechen kann. Der Nachteil dabei ist, dass viele
Storage-Controller diese Reservierungen nicht zuverlässig implementieren und dass ganze Platten
statt lediglich Partitionen zugeteilt werden. In vielen Fällen ist dies eine
Platzverschwendung.
Die zweite Komponente der Redhat-Cluster-Suite dient dem IP Load Balancing und beruht auf dem
Open-Source-Projekt LVS (Linux Virtual Server) und Piranha. Die Technik dient der Lastverteilung
von eingehenden IP-Anfragen auf mehrere Server und ist für große Webserver gut geeignet
(Einzelheiten zu LVS und Piranha siehe LANline 11/2004).
Keine eigene Cluster-Lösung bietet der große Rivale Novell mit Suse Linux Enterprise Server
(SLES) 9 an. Um ebenfalls ein Stück des Data-Center-Kuchens zu ergattern, setzt der Hersteller seit
kurzem auf eine Vertriebspartnerschaft mit Polyserve und deren Cluster-Software namens "
Matrix-Server". Das Produkt unterstützt Cluster mit bis zu 16 Knoten oder Blades, ist also für
größere Verbünde geeignet als die Lösung von Redhat.
Die Software setzt ein Storage Area Network voraus, unterstützt verteiltes Metadatenmanagement
und kennt keine Master-/Slave-Beziehungen unter den Servern (Bild auf Seite 32). Der Hersteller
nennt als oberstes Architekturprinzip seiner Software die Symmetrie aller Knoten eines Clusters.
Alle Aufgaben, die ein Verbund ausführen muss, sind gleichmäßig unter den Mitgliedern verteilt. So
genannte Gruppenkommunikationsmechanismen überwachen den Status der Knoten und koordinieren eine
Cluster-weite Liste von "gesunden" Servern bezüglich ihrer Konfiguration. Aufgrund dieser
Architektur kann sich ein Administrator auf jedem beliebigen Knoten einloggen, um alle anderen von
hier aus zu verwalten. Failover-Mechanismen auf der Basis von vordefinierten Regeln übertragen
Anwendungen im Fehlerfall auf einen anderen Server oder starten die Applikation erneut.
Der Matrix-Server enthält ein verbundweit verteiltes Journaling-Cluster-Filesystem (CFS) mit
Unterstützung für das Online-Hinzufügen beziehungsweise Löschen von Knoten und dem gleichzeitigen
Zugriff auf Shared-Daten über mehrere Knoten hinweg. Die Software umfasst zudem einen verteilten,
symmetrischen Lock-Manager auf jedem Cluster-Knoten. Er ermöglicht es, Daten im Read-only-Modus
über beliebige Knoten hinweg gemeinsam zu nutzen. Zudem spielt er eine wichtige Rolle im Fall von
Netzwerkfehlern. Denn wenn ein Knoten auf eine Nachricht des Lock-Managers nicht antwortet, ist
dies häufig ein Anzeichen eines Fehlers. Der Unterschied der Lösung von Polyserve zu der anderer
Hersteller ist laut Firmenangaben die Tatsache, dass in einem Matrix-Cluster Server zu Gruppen
zusammengefasst werden, die in der Lage sind, große Anwendungen zu unterstützen. Diese Gruppen
können im laufenden Betrieb je nach Bedarf umkonfiguriert werden.
Cluster unter Solaris
Schließlich kann in naher Zukunft auch Sun Microsystems mitsprechen, wenn es um Quelloffenheit
geht. Der Hersteller hat nämlich angekündigt, im Juni dieses Jahres den Quellcode von Solaris 10
als Open Source zugänglich zu machen. Die eigene Verbundssoftware Sun Cluster 3.1 unterstützt mit
dem Sun-eigenen Betriebssystem und der eigenen Hardware Cluster-Konfigurationen mit bis zu 16
Knoten. Die Lösung bietet Netzwerkdienste für das Management und Failover. Zudem verteilt die
Software über eine Netzwerkschnittstelle mit einer globalen IP-Adresse eingehende Anfragen an die
verschiedenen Instanzen der verteilten Anwendungen. Bei einem Ausfall wird die globale IP-Adresse
an eine Backup-Netzwerkschnittstelle geleitet.
Zusätzlich lässt sich über eine Zwischenschicht Solaris oder das Veritas-Dateisystem
Cluster-weit nutzen. Ein SAN ist keine Voraussetzung für einen Sun-Verbund. In der nächsten Version
von Solaris 10 soll es dann auch möglich sein, ein Failover für so genannte Container auf
physikalisch getrennte Systeme auszuweiten.
HA-OSCAR (www.openclustergroup.org/HA-OSCAR):
Das Projekt baut auf einem Beowulf-Cluster auf und verleiht diesem Hochverfügbarkeitsfunktionalität.
Linux-HA (www.linux-ha.org):
Der Hauptbestandteil des Hochverfügbarkeitsprojekts ist Heartbeat. Die Software wird in allen Arten von Clustern eingesetzt.
Kimberlite (oss.missioncriticallinux.com):
Die Software unterstützt Cluster mit zwei Knoten und einem gemeinsamen SCSI- oder Fibre-Channel-Storage-System in einer Active/Active-Failover-Umgebung.
Lifekeeper (www.steeleye.com):
Lösung von Steeleye für große hochverfügbare Cluster.
Linux Failsafe (www.oss.sgi.com/projects/failsafe):
Die Linux-Portierung von SGI enthält Module für Aufgaben des Failovers.
Linux Replicated High Availability Manager (www.linuxha.net):
Das Projekt bietet eine Lösung für einen hochverfügbaren Zwei-Knoten-Cluster, wobei die Daten zwischen den beiden Knoten repliziert werden.
Serviceguard (h71028.www7.hp.com/enterprise/cache/6468-0-0-0-121.aspx):
Die Software von Hewlett-Packard schützt gegen eine Vielfalt von Hard- und Softwareausfällen in Aktiv/Passiv-Clustern. Die Anwendungen und Dienste sind in Ressourcengruppen eingeteilt mit einer virtuellen IP-Adresse und eventuell Plattenplatz auf Shared Storage.
RSF-1 (www.high-availability.com):
Die Resilient Server Facility wird zwischen die Anwendungsschicht und das Storage Volume Management implementiert und übernimmt im Fall eines Ausfalls das automatische Failover von Anwendungen. RSF bietet multidirektionale Redundanz.
Service Routing Redundancy Daemon (srrd.org):
Der SRRD-Server überwacht und verwaltet sowohl Dienste als auch Shared-Ressourcen, wobei sich die Cluster-Knoten in verschiedenen LANs befinden können. Er unterstützt PKI- und SSL-Clients sowie Server-Authentifizierung und Servicegruppierung.
Veritas Cluster Server (www.veritas.com):
Der Cluster-Server unterstützt in der Linux-Version bis zu 16 Knoten und läuft sowohl in SAN- als auch in traditionellen Client-/Server-Umgebungen.
Lesen Sie mehr zum Thema
