High-Availability Clustering
Werbung
High-Availability Clustering Holger Hennig, HA-Cluster Specialist HA Cluster INHALTSVERZEICHNIS 1. ABSTRACT..............................................................................................................................3 2. EINFÜHRUNG .........................................................................................................................4 2.1 GRUNDLAGEN .........................................................................................................................4 2.2 DAS KONZEPT DES HA C LUSTERS .......................................................................................4 2.3 VORTEILE EINER HA C LUSTERLÖSUNG ................................................................................5 3. ARCHITEKTUR.......................................................................................................................6 3.1 3.2 3.3 3.4 ALLGEMEINES ........................................................................................................................6 SHARED ALL PRINZIP ............................................................................................................6 SHARED NOTHING PRINZIP ...................................................................................................7 MIRRORING PRINZIP ..............................................................................................................8 4. BETRIEBSMODI .....................................................................................................................9 4.1 4.2 4.3 4.4 GRUNDLAGEN ........................................................................................................................9 AKTIV – P ASSIV CLUSTERMODELL........................................................................................9 AKTIV – A KTIV CLUSTERMODELL ........................................................................................10 GEMISCHTE CLUSTERMODELLE ..........................................................................................11 5. AUFBAU EINES REDUNDANTEN DIENSTES...............................................................13 5.1 S TRUKTURELLER AUFBAU BEI MEHREREN CLUSTERGRUPPEN ...........................................15 5.2 PLANUNG VON CLUSTERRESSOURCEN...............................................................................16 6. WEBADRESSEN ZUM THEMA HA CLUSTERING .......................................................17 Dieses Werk ist geistiges Eigentum der transtec AG. www.transtec.de Es darf ohne Zustimmung des Autors und der transtec AG weder kopiert noch auszugs weise abgedruckt oder in einer anderen Form vervielfältigt werden. Alle in dieser Publikation enthaltenen Informationen wurden mit größter Sorgfalt zusammengestellt. Dennoch können fehlerhafte Angaben nicht völlig ausgeschlossen werden. Die transtec AG und der Autor haften nicht für etwaige Fehler und deren Folgen. Die in der Veröffentlichung verwendeten Soft- und Hardwarebezeichnungen sind häufig eingetragene Warenzeichen. Sie werden ohne Gewährleistung der freien Verwendbarkeit genutzt. Das Abdrucken von Waren- und Handelsnamen auf den folgenden Seiten berechtigt nicht zu der Annahme, diese Namen als frei im Sinne der Markenschutzgesetzgebung zu betrachten. transtec AG Seite 2/17 HA Cluster 1. ABSTRACT Dieses Whitepaper soll IT Entscheidern und Administratoren einen Überblick über die aktuelle HA (High Availability) Clustering Technologie verschaffen. Es wird das Konzept des HA Clustering beschrieben sowie die Anforderungen, die zum Betrieb eines HA Clusters notwendig sind. Des weiteren wird aufgezeigt, welche Möglichkeiten existieren, Dienste auf Windows und Linux Plattformen redundant zu halten. Auf die Softwareaspekte, die bei der konkreten Installation eines Windows oder Linux HA Clusters zu berücksichtigen sind, gehen wir in einer getrennten Publikation ein. transtec AG Seite 3/17 HA Cluster 2. EINFÜHRUNG 2.1 Grundlagen Die Verfügbarkeit von Serverdiensten und Applikationen sind unternehmenskritisch geworden. Durch Ausfallzeiten entstehen einem Unternehmen Kosten und allzu oft auch ein Imageschaden, vor dem man sich nur durch entsprechende Maßnahmen schützen kann. Die Lösung sind Hochverfügbarkeits-Cluster. Das Ziel eines HA Clusters ist es, die Downtime eines oder mehrerer Dienste möglichst gering zu halten. Eine Verfügbarkeit von 100% ist nicht zu erhalten, sehr wohl aber 99,999%. Um einen solchen Wert zu erreichen muss man die Zahl der sogenannten „Single Point of Failure“ möglichst gering halten. Das beginnt beim redundanten Aufbau der Serversysteme durch Clusterlösungen, geht über redundante USV-Anlagen bis hin zur geographischen Trennung der Clusterpaare. Verfügbarkeit 99% 99,9% 99,99% 99,999% 99,9999% 99,99999% entsprechende Downtime 3,6 Tage Ausfall/Jahr 8,76 Stunden Ausfall/Jahr 52 Minuten Ausfall/Jahr 5 Minuten Ausfall/Jahr 30 Sekunden Ausfall/Jahr 3 Sekunden Ausfall/Jahr Tab. 1: Verfügbarkeitsgrad und entsprechende Ausfalldauer Unter Microsoft Windows und Linux Betriebsystemen steht das HA Clustering Feature bereits seit geraumer Zeit zur Verfügung. Unter Windows seit NT 4.0 (Wulfpack), fortgeführt mit dem Windows 2000 Advanced Server und nun dem Windows 2003 Enterprise Server von Microsoft. Unter Linux gibt es sowohl verschiedene Open Source Projekte als auch kommerzielle Produkte für das HA Clustering, die mehr oder weniger den gleichen Prinzipien entsprechen. 2.2 Das Konzept des HA Clusters Ein Cluster besteht aus zwei oder mehreren Computern, die zu einem logischen System zusammengefasst werden. Das Ziel ist eine bessere Verfügbarkeit, Verwaltbarkeit und Erweiterbarkeit. Diese Aspekte werden in diesem Whitepaper ausführlich beleuchtet. Wenn Fehler im Cluster auftreten, können Ressourcen anderer Knoten verwendet werden. Der Benutzer bekommt in der Regel von dem Fehler nichts mit, auch entfällt eine neue Verbindung mit seiner Applikation. transtec AG Seite 4/17 HA Cluster 2.3 Vorteile einer HA Clusterlösung • Erweiterte Verfügbarkeit: Dienste und Applikationen, die auf dem Cluster laufen, werden durch die HA Mechanismen redundant ausgelegt, so dass bei einem Hardware- oder Softwarefehler die Dienste weiter zur Verfügung stehen. Ebenso sind geplante Wartungen an den Servern durch Dienstmigration (manuelles Verschieben der Dienste auf den anderen Knoten) einfacher und sicherer durchzuführen. • Erweiterte Skalierbarkeit: unter dem Microsoft Windows Betriebssystem erhält man mit Windows 2000 Advanced Server oder dem Windows 2003 Enterprise Server eine erweiterte Unterstützung von bis zu 8 Prozessoren (normalerweise nur 4) und Support von bis zu 8 GB RAM (normalerweise nur 4 GB). Bei beiden Windowsversionen wie auch bei Linux, lässt sich die Hardware in einem Clusterverbund einfacher erweitern. Erweiterungen für die CPU, RAM oder Storage lassen sich durch eine geplante Downtime ohne Ausfall eines Dienstes realisieren. • Verbessertes Management: die Managementkonsole der Clustersoftware stellt den Cluster als ganzes dar. Die Ressourcen des gesamten Clusters lassen sich softwaregeführt konfigurieren. Unter Linux finden auch grafikbasierte Managementkonsolen (GUIs – Grafisches User Interface) Verwendung, die jedoch weniger ausgereift sind als die Produkte der Windows Welt. Daher werden unter Linux meist textbasierte Skripte bzw. globale Konfigurationsdateien verwendet, die den gleichen Funktionsumfang besitzen wie eine grafische Konsole. transtec AG Seite 5/17 HA Cluster 3. ARCHITEKTUR 3.1 Allgemeines Für den Aufbau eines HA Clusters stehen drei unterschiedliche Architekturen zur Auswahl. Sie unterscheiden sich in der Art, wie die einzelnen Knoten auf Storagebereiche im Clusterverbund zugreifen. Die Herausforderung besteht darin, nach einem Knotenausfall diejenigen Storagebereiche, die zuvor in Besitz des fehlerhaften Knotens waren, dem überlebenden Knoten zur Verfügung zu stellen. Hierzu muss mit Shared Storage Lösungen gearbeitet werden, bei denen alle Knoten die Möglichkeit haben, die gesamten Storagebereiche des Clusters anzusprechen. Im folgenden werden die einzelnen Architekturen ausführlicher beschrieben. 3.2 Shared All Prinzip Beim „Shared All“ Prinzip haben alle Knoten Zugriff auf das gleiche Storagessystem 1. In diesem Fall besteht die Gefahr, dass beide Knoten in das gleiche Dateisystem schreiben. Ein solcher Zugriff ist unbedingt zu vermeiden, da dies leicht zu korrupten Daten führen kann. Daher wird bei Shared All Lösungen ein DLM (Distributed Lock Manager) verwendet, der den Zugriff der einzelnen Knoten steuert und parallele Zugriffe blockiert. Cluster Knoten A Cluster Knoten B Externe Storageeinheit SCSI oder Fibre Channel Abb. 1: HA Cluster mit Shared All Storage 1 In der Regel handelt es sich hierbei um ein externes RAID System, wie beispielsweise das transtec 5016. transtec AG Seite 6/17 HA Cluster Dieses Prinzip kennt man schon seit längerem aus dem Bereich der VAX VMS Cluster von Digital, die bereits vor 10 Jahren mit diesem Prinzip sehr stabil arbeiteten. Aktuell werden nur noch wenige Cluster nach diesem Verfahren eingerichtet. Sowohl unter Microsoft Windows also auch unter Linux wurde es vom nachfolgend beschriebenen „Shared Nothing“ Prinzip abgelöst. 3.3 Shared Nothing Prinzip Das „Shared Nothing“ Prinzip weist beiden Knoten ihre eigenen Storagebereiche zu. Die Clusterknoten2 haben jedoch die Möglichkeit, die Storagebereiche des anderen Knotens zusätzlich zu übernehmen. Zu keinem Zeitpunkt ist ein Datenbestand im Besitz von zwei Knoten gleichzeitig. Dadurch wird ein gemeinsamer Zugriff auf gleiche Datenbestände ausgeschlossen. Bei diesem Konzept ist es wichtig sicherzustellen, dass die Kommunikation der Knoten untereinander einwandfrei arbeitet. Es darf nicht nicht zu einer sogenannten „Split Brain“ Situation kommen, in der beide Knoten versuchen, denselben Storagebereich anzusprechen. Der Zugriff beider Knoten in einen Storagebereich führt zu einer Inkonsistenz des Dateisystems und somit zu Datenverlust. Die gegenseitige Überwachung wird über eine eigene Netzwerkverbindung (Heartbeat) gewährleistet. Um diesen Fehler sicher zu vermeiden geht man in manchen Clusterlösungen sogar soweit, den ausgefallenen Knoten über einen Powerswitch komplett vom Netz zu trennen um einen Crash des Clusters von vorneherein auszuschließen. Die transtec AG verwendet diese Powerswitch Lösung bei Ihren Linux Clustern. Bei Microsoft Lösungen wird dieser Fehler durch die Wertigkeit des Quorum Devices (seperater Bereich auf dem Loggin Informationen abgelegt werden ) geregelt. Cluster Knoten A Cluster Knoten B Datenbereich A Datenbereich B Externe Storageeinheit SCSI oder Fibre Channel Abb.2: Shared Nothing Prinzip 2 Hierbei kommen meist Dual Xeon Server wie der transtec 2600 zum Einsatz. transtec AG Seite 7/17 HA Cluster 3.4 Mirroring Prinzip Beim Mirroring Prinzip verfügt jeder Knoten über eigene Storagebereiche, die über eine dedizierte Netzwerkverbindung gespiegelt werden. Es handelt sich also um eine Serverbasierte RAID 1 – Lösung. Sowohl im Microsoft als auch im Linux Bereich existieren hierfür spezielle Lösungen. Unter Microsoft 2000 Server erlaubt z.B. der Legato Aadvanced Co-Standby Server, zwei Knoten permanent auf dem gleichen Stand zu halten3. Der in der Enterpriseversion des Windows 2000 Servers integrierte Clusterdienst verfügt nicht über diese MirrorFunktionalität. Verwendet man eine Linux Distribution, kann das Linux Paket DRBD zum Einsatz kommen, das Partitionen über das Netz synchronisiert. Wie bei RAID 1 üblich müssen die Storagekapazitäten doppelt vorhanden sein. Cluster Knoten A Cluster Knoten B Dedizierter Network Uplink SCSI oder Fibre Channel Storageeinheit SCSI oder Fibre Channel Storageeinheit Abb. 3: Mirroring Prinzip 4 3 Die MS Windows 2000 Server Enterprise Version wird hierfür nicht benötigt. transtec bietet für die Windows 2000 basierende Legato Lösung Produktbundles mit Vorortinstallation und Konfiguration an. 4 transtec AG Seite 8/17 HA Cluster 4. BETRIEBSMODI 4.1 Grundlagen Bei der Konzeptionierung eines HA Clusters muss zuerst der Betriebsmodus des Clusters festgelegt werden. HA Cluster Knoten können entweder „Aktiv“ oder „Passiv“ betrieben werden. • Aktiver Knoten: der Knoten ist aktiv und bedient Clients mit Ressourcen (z.B. File Sharing, DNS, Mail, Datenbank) • Passiver Knoten: der Knoten ist passiv, arbeitet auf “Standby” und überwacht aktive Knoten um deren Ressourcen im Fehlerfall zu übernehmen Daraus resultieren unterschiedliche Clustermodelle, die im folgenden näher beschrieben werden. 4.2 Aktiv – Passiv Clustermodell Auf dem „Aktiv-Passiv“ HA-Cluster arbeiten Dienste und Applikationen ausschließlich auf dem aktiven Clusterknoten. Im Fehlerfall werden sie automatisch auf den passiven Knoten transferiert. Solange der passive Knoten durch andere Aufgaben nicht belastet wird, sollte ein Failover ohne Probleme funktionieren . Eine Voraussetzung für das Betriebsmodell ist die identische Hardwareausstattung der Knoten. Cluster Knoten A Cluster Knoten B SQL Datenbank wandert im Fehlerfall zu Knoten B SCSI oder Fibre Channel SCSI oder Fibre Channel Externe Storageeinheit Abb. 3: Aktiv – Passiv Clustermodell transtec AG Seite 9/17 HA Cluster 4.3 Aktiv – Aktiv Clustermodell Auf dem „Aktiv-Aktiv“ HA-Cluster arbeiten Dienste und Applikationen auf beiden Clusterknoten. Im Fehlerfall stellen die Clusterknoten jeweils für den anderen die Redundanz zur Verfügung. Hierbei ist allerdings der Workload, mit dem die Clusterknoten betrieben werden, von entscheidender Bedeutung. In unserem Beispiel in Abb. 4 muss ein Clusterknoten im Fehlerfall die SQL- und die Maildienste übernehmen. Daher sind die Clusterknoten richtig zu dimensionieren, um für den Fehlerfall die benötigten Reserven zur Verfügung zu stellen. Empfehlenswert ist eine gleichmäßige Auslastung beider Knoten im Aktiv-Aktiv Betrieb. Dementsprechend sollte der Workload je Knoten nicht über 50 % liegen. Cluster Knoten A wandert im Fehlerfall zu Knoten B Cluster Knoten B SQL Datenbank Mail Server wandert im Fehlerfall zu Knoten A SCSI oder Fibre Channel SCSI oder Fibre Channel Externe Storageeinheit Abb. 4: Aktiv - Aktiv Clustermodell Sehr oft wird ein „Aktiv-Aktiv“ Cluster auch so verstanden, dass derselbe Dienst auf beiden Clusterknoten läuft und eine Art „Load Balancing“ der Clientanfragen geschieht. Dies ist nur sehr eingeschränkt möglich und wird nicht von allen Clustersystemen unterstützt. Die Ausnahme bietet Microsoft in den Produkten SQL Server 2000 und Exchange Server 2000/2003, die die Lastverteilung implementiert haben. Der Microsoft SQL Server 2000 erlaubt zum Beispiel die Partitionierung einer Datenbank und das Zuweisen einzelner Datenbankpartitionen an einen Clusterknoten. Von einem echten Load Balancing kann aber auch hier nicht gesprochen werden, da auch die Clientanfragen immer nur von einem Knoten bedient werden (solange sich Anfragen in einer Partition befinden). Dies gilt ebenso für den Exchange 2000/2003 Server, hier erfolgt die Partitionierung anhand der Organisationsstruktur. transtec AG Seite 10/17 HA Cluster Der Aufbau dieses pseudo Load Balanced Aktiv-Aktiv Cluster ist wesentlich aufwändiger und erfordert detaillierte Microsoft Windows Kenntnisse. Unter Linux ist diese Art der Aufteilung ebenfalls möglich, es kommt aber stark auf die Applikation an und ist im Einzelfall zu prüfen. Die transtec bietet sowohl Aktiv-Passiv also auch Aktiv-Aktiv Lösungen in Ihrem Produktspektrum an. 4.4 Gemischte Clustermodelle Zu den Clustermodellen „Aktiv-Passiv“ und „Aktiv-Aktiv“, die man durchaus als Standardmodelle bezeichnen kann, kommen noch spezielle Modelle hinzu, die von aktuellen Clusterlösungen ebenfalls unterstützt werden. Im Beispiel in Abb. 5 arbeiten die Knoten A, B und C als aktive Clusterknoten und stellen ihre Ressourcen zur Verfügung. Der Knoten D ist als einziger passiv, stellt jedoch für die anderen drei Clusterknoten den Failover Partner dar. In einem solchen Szenario kommen die Vorteile eines SAN (Storage Area Network) voll zum tragen, da diese Lösung über einen Fibre Channel Switch und ein Fibre Channel RAID System leicht realisiert werden kann. Eine Lösung auf SCSI Basis ist ebenfalls denkbar, sie erfordert im Vergleich dazu aber einen höheren technischen Aufwand, da je Clusterverknüpfung ( A-D, B-D, C-D ) eine eigene Shared Storage Lösung vorgesehen werden muss. Tritt der Fall ein, dass mehr als ein Knoten ausfällt und der Backupknoten zusätzliche Dienste übernehmen muss, sind seine Ressourcen in der Regel zu klein. Bei einer professionellen Lösung ist der Knoten D daher anders zu dimensionieren als die Knoten A bis C. Das Konzept des gemischten Clusters eignet sich aber auch hervorragend, um manuell Dienste zu verschieben und danach Wartungsarbeiten oder Hardware Upgrades an den Hauptservern vorzunehmen. Server A Server B Server D FC RAIDSystem Server C Abb. 5: Gemischter Cluster transtec AG Seite 11/17 HA Cluster Die gleiche Konstellation kann aber auch ganz anders verwendet werden: Der Knoten D ist ein Quad Xeon System auf dem aktiv ein Mailserver, eine SQL Datenbank und der zentrale DNS Server läuft. Es wäre möglich, die Knoten A, B und C als Single CPU Server auszuführen und jeweils für einen Dienst verantwortlich zu machen, hier wären die Knoten A, B und C passiv. Im Fehlerfall könnten die Dienste dann verteilt werden. • • • transtec AG D -> A = Mail Server D -> B = SQL Server D -> C = DNS Server Seite 12/17 HA Cluster 5. AUFBAU EINES REDUNDANTEN D IENSTES Der schematische Aufbau eines redundanten Dienstes in einem HA-Cluster ist relativ trivial. Ein einzelner Dienst (Ressource) ist die kleinste verwaltbare Komponente in einem Cluster. Bei einer Ressource kann es sich z.B. um eine IP Adresse, einen Netbios Namen oder eine physikalische Festplatte handeln. Ressourcen entwickeln untereinander Abhängigkeiten und werden in aller Regel zu logischen Gruppen zusammengefasst. Als Beispiel werden die Abhängigkeiten eines redundanten WWW-Dienstes aufgezeigt. Um einen WWW Server auf einem Cluster oder auch standalone System zu betreiben, benötigt man eine feste IP Adresse, einen Netzwerknamen unter dem der Server zu erreichen ist, einen Storagebereich auf dem sich die Daten des WWW-Dienstes befinden sowie den WWW-Dienst. WWWDienst Netzwerkname Storagebereich IP Adresse Abb. 6: Abhängigkeiten eines Dienstes Im Clustermanagement kann jede Ressource separat Online oder Offline geschalten werden. In unserem Beispiel kann der WWW-Dienst erst dann Online gehen, wenn die dazugehörige IP Adresse, der Netzwerkname und der Storagebereich zur Verfügung stehen. Somit entwickelt der WWW-Dienst Abhängigkeiten mit diesen drei Ressourcen. Die IP Adresse und der Storagebereich hingegen entwickeln keine Abhängigkeiten und können auch alleine Online gehen. Die Ressourcen, um einen Dienst redundant aufzubauen, werden über die Clustermanagement Software in logische Gruppen zusammengefasst. Um den Dienst auf einen anderen Clusterknoten zu verschieben, muss nur die Gruppe verschoben werden. Die Clustersoftware löst die Abhängigkeiten auf und schält nacheinander die Ressourcen Offline. transtec AG Seite 13/17 HA Cluster Reihenfolge der Offline Schaltung des WWW-Dienst: 1. WWW-Dienst 2. Netzwerkname 3. Storagebereich 4. IP Adresse In umgekehrter Reihenfolge werden die Ressourcen auf dem anderen Clusterknoten wieder Online geschaltet. Reihenfolge der Online Schaltung des WWW-Dienst: 1. IP Adresse 2. Netzwerkname 3. Storagebereich 4. WWW-Dienst Schlägt eine Online Schaltung fehl, so steht der Dienst auch nicht mehr zur Verfügung. transtec AG Seite 14/17 HA Cluster 5.1 Struktureller Aufbau bei mehreren Clustergruppen In einem HA-Cluster werden die einzelnen zusammengehörenden Ressourcen in Gruppen verwaltet. Über das Clustermanagement ist dann zu konfigurieren, auf welchem Knoten die einzelnen Gruppen „aktiv“ laufen. Diese logischen Gruppen werden in einem Fehlerfall, abhängig von Ihren Ressourcen, auf den überlebenden Knoten verschoben. Cluster Gruppe DHCP DHCP Dienst Netzwerkname IP Adresse A Storage Bereich A Gruppe WWW WWWDienst Netzwerkname IP Adresse B Storage Bereich B Gruppe SQL SQL Dienst Netzwerk Name IP Adresse C Storage Bereich C Abb. 7: Struktur der Abhängigkeiten transtec AG Seite 15/17 HA Cluster 5.2 Planung von Clusterressourcen Aus der schematischen Darstellung in 5.1 geht hervor, dass für jede Clustergruppe eine IP Adresse, ein Netzwerkname und ein separater Storagebereich zu planen ist. Die Planung des Storagebereiches bedarf besonderer Aufmerksamkeit. Wird ein externes RAID-System verwendet, so muss berücksichtig werden, dass für jeden redundanten Dienst ein eigenes RAID-Set konfiguriert wird, welches dann unabhängig von anderen Storagebereichen verschoben werden kann. Es ist im Prinzip auch möglich, mehrere Ressourcen in einer Clustergruppe zusammenzufassen, welche alle auf denselben Storagebereich zugreifen. Hierbei ist allerdings zu berücksichtigen, dass beim Failover einer Ressource, die als Abhängigkeit den Storagebereich inne hat, alle abhängenden Ressourcen verschoben werden müssen. Somit ist es nicht möglich, einzelne Dienste zu verschieben oder eine „aktiv-aktiv“ Konfiguration zu erstellen. transtec AG Seite 16/17 HA Cluster 6. W EBADRESSEN ZUM THEMA HA CLUSTERING Neuerungen beim Clustering mit Windows 2003 Enterprise Server: http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/clusterin g.mspx HA-Clustering und NLB (Network Load Balancing): http://www.microsoft.com/windows2000/technologies/clustering/ HA-Clustering unter Linux, mit dem Open Source Paket Failsafe: http://oss.sgi.com/projects/failsafe/docs/functionality/ Das Linux HA-Projekt: http://www.linux-ha.org/ Legato Co-Standby Server für Microsoft Windows: http://portal1.legato.com/products/costandbyserver/ Linux mit GFS (Global File System) für „Shared-All“ Clustering: http://www.sistina.com/products_gfs.htm Linux Paket DRBD Netwerk RAID 1 für „Shared-All“ Clustering: http://www.drbd.org transtec AG Seite 17/17
