Clusterbau mit Linux-HA Version 3 - Hochverfügbare Server einrichten
Buchausgabe: 39,90€
Download-Version: 32,00€
(Preis inkl. Mwst. )
| Autor(en): | Michael Schwartzkopff |
| Verlag: | O'Reilly Verlag |
| Version: | 2. Auflage, 2009 |
| Umfang: | 372 Seiten |
| Format: | PDF: 3,97MB |
| Gewicht: | 776 g |
| ISBN: | 3897219190 |
| Bestell-Nr.: | 89721919P |
| Artikeltyp: | E-Book |
Das Buch erläutert, was Hochverfügbarkeit eigentlich bedeutet, führt die zentralen Begriffe ein und erklärt, worauf es beim Einrichten von Clustern ankommt. Sie erfahren dann, wie heartbeat, OpenAIS und pacemaker funktionieren und welche Aufgaben diese für Sie lösen können.
Nach der Installation und Konfiguration der Software geht es um die Einrichtung und Verwaltung Ihrer Ressourcen. Gemäß dem Motto `If we manage it, it`s a resource` tragen Sie in der zentralen Cluster Information Base (CIB) alle Dienste ein und legen Verknüpfungen fest. Sei es mit der GUI oder über die Kommandozeile - nun haben Sie Ihre Ressourcen und die Knoten des Clusters fest im Griff.
Grau ist alle Theorie! Am meisten lernt man doch von Menschen mit reicher Praxiserfahrung: Neben den Tipps und Tricks zu Planung und Betrieb ist das Kapitel mit typischen konkreten Szenarien besonders wertvoll. Die Konfiguration folgender Anwendungsfälle wird vollständig erklärt:
* Distributed Redundant Block Devices (DRBD) als Grundlage der Datenspeicherung im Cluster
* DRBD in einem NFSv4-Dateiserver oder einem iSCSI-SAN
* Virtuelle Rechner, die im Fehlerfall als komplette Einheit auf den anderen Knoten verschoben werden
* Eine redundant aufgebaute Firewall, die im Fehlerfall die Tabelle der bestehenden Verbindungen mit übernehmen kann und somit echte Hochverfügbarkeit bietet
Leseprobe:
KAPITEL 2 Grundlagen (S. 17-18)
Was ist ein Cluster? Wie funktioniert ein Cluster in der Praxis? Welche Probleme kann ich damit lösen, und wo sind die verborgenen Fallstricke, die man unbedingt vermeiden muss, damit das Gesamtsystem auch in kritischen Situationen noch wie erwartet funktioniert? Wie der Linux-HA diese Fragen angeht, soll ebenso Gegenstand dieses Kapitels sein wie die Veränderungen, die das Projekt beziehungsweise die Nachfolgeprojekte in den letzten Jahren erfahren haben. Im letzten Teil wird noch auf die innere Architektur der Clustersoftware eingegangen.
Theorie
Ein hochverfügbarer Cluster ist ein Zusammenschluss von mehreren Computern, die einen bestimmten Dienst auch dann noch anbieten sollen, wenn eine oder mehrere Einzelkomponenten ausfallen. Der Gedanke der Redundanz stand beim Design von Clusterlösungen klar im Vordergrund.
Aufbau und Funktion
Auf jedem einzelnen Rechner (auch Knoten des Clusters genannt) können bestimmte Ressourcen ausgeführt werden. Normalerweise läuft eine Ressource auf einem Knoten, und ein anderer Knoten läuft als Reservesystem nebenher. Die Clustersoftware sorgt nun dafür, dass der Status der Knoten ständig überprüft wird. Dazu können Kriterien wie Netzwerkanbindung, Prozessorlast, freier Speicher- oder Festplattenplatz oder der Zustand einer Applikation herangezogen werden. Falls ein Problem auf dem gerade aktiven Knoten auftritt, wird die Ressource auf dem passiven System gestartet, und der Dienst kann weiter angeboten werden. Unterschiedliche Ressourcen können natürlich auch auf verschiedenen Knoten des Clusters ausgeführt werden.
Die Alternative zu solchen sogenannten Aktiv/Passiv-Clustern bilden Systeme, bei denen alle Knoten aktiv sind und eine zentrale Instanz oder die Clustersoftware dafür sorgt, dass die Last gleichmäßig auf alle Knoten verteilt wird. Solche Load-Balancing-Systeme bieten den Vorteil, dass die Leistung des Clusters mit der Anzahl der Knoten im Cluster skaliert. Allerdings muss man beim Design eines solchen Clusters darauf achten, dass die verbliebenen Knoten die Last beim Ausfall eines (oder mehrerer) Knoten übernehmen können. Eine intelligente Umsetzung des Load-Balancing-Konzepts ist in den Produkten der Firma Stonesoft gelungen.
Was sich in der Clustertheorie so einfach anhört, zeigt in der praktischen Umsetzung einige Probleme, die von den Entwicklern und Administratoren berücksichtigt werden müssen. Alle Knoten eines Clusters müssen sich beispielsweise gegenseitig voll vertrauen: Deshalb müssen sie sich gegenseitig authentifizieren, bevor Systemmeldungen von einem anderen Knoten angenommen werden. Natürlich sollte auch die Kommunikation untereinander verschlüsselt sein.
Die Kommunikation der Knoten untereinander muss besonders zuverlässig sein, da Verbindungsausfälle zu schwerwiegenden Konsequenzen führen (siehe dazu den Abschnitt »Split Brain«). Der Datenaustausch zwischen den Knoten kann über die Schnittstelle erfolgen, über die auch die Clients auf das System zugreifen. Besser ist es allerdings, den Datenaustausch zwischen den Knoten über eine eigene Netzwerkschnittstelle zu führen. Wenn die Clients einmal eine hohe Last erzeugen, kommt es dennoch zu keinen Verzögerungen in der Unterhaltung der Knoten untereinander. Am besten erfolgt die Clusterkommunikation über redundante Wege, also über zwei Schnittstellen.
Falls der Cluster nur aus zwei Knoten besteht, können diese mit einen Crossover- Kabel verbunden werden. Die MTBF für ein einfaches Kabel ist unschlagbar hoch gegenüber anderen Komponenten im Netzwerk.
Ein Knoten muss natürlich auch im Fehlerfall überwacht werden. Wurde die Störung beseitigt, sollte die Clustersoftware den Knoten automatisch wieder als »online« markieren und eventuell die Ressourcen neu verteilen. Allerdings ist die Neuverteilung von Ressourcen ein kontrovers diskutiertes Thema.
Der besondere Tipp
Denken Sie nicht an einen blauen Elefanten!
Anhand verblüffender Experimente und einfacher Übungen lernen Sie, wie unsere Umwelt die Gedanken und die Gedanken unsere Umwelt beeinflussen.
Früher: 12,00€
bei uns nur: 4,99€

