Hochverfügbarkeits Cluster

Transkript

1 Hochverfügbarkeits Cluster Prüfling Stephan Erdmann Ausbildungsbetrieb Berufsförderungswerk Schömberg ggmbh

2

3 Projektübersicht: Thema Hochverfügbarkeits Cluster Bearbeiter Stephan Erdmann Beruf Fachinformatiker Systemintegration Ausbildungsbetrieb Berufsförderungswerk Schömberg ggmbh Bühlhof Schömberg Betreuer Dieter Göttisheim Zeitraum Beschreibung Firma Mustermann GmbH betreibt ein Intranet mit einem Datenbankserver auf MySQL Basis und musste im vergangenen Quartal einen vollständigen Serverausfall über mehrere Stunden aufgrund einer defekten Hardwarekomponente erleben. Während dieses Ausfalls konnten keine Zugriffe auf die Datenbank gewährt werden, wodurch ein erheblicher Produktivitätsausfall hingenommen werden musste. Aufgrund dieser Erfahrungen beauftragt besagte Firma den Projektdurchführenden damit die Durchführbarkeit der Portierung der bestehenden Serverstruktur auf einen Hochverfügbarkeits Cluster in einer Testumgebung zu zeigen.

4

5 Eidesstattliche Versicherung zur Durchführung und Dokumentation der betrieblichen Projektarbeit im Rahmen der Abschlussprüfung in den ITAusbildungsberufen Thema der Projektarbeit: Hochverfügbarkeits - Cluster 1. Prüfling: Der Prüfungsteilnehmer/die Prüfungsteilnehmerin: Erdmann, Stephan Name, Vorname geb. am Geburtsort erklärt durch Unterschrift, dass er die im Rahmen seiner Prüfung angefertigte Dokumentation sowie die zu Grunde liegende Projektarbeit in der vom Prüfungsausschuss genehmigten Form selbständig und ohne fremde Hilfe bearbeitet hat. Die hierfür in der Verordnung vorgesehene Richtzeit von max. 35 Stunden wurde nicht überschritten. Ihm ist bewusst, dass unwahre Angaben zum Nichtbestehen der Prüfung führen können. Ort, Datum Unterschrift 2. Ausbildungsbetrieb: Der für die Ausbildung Verantwortliche erklärt durch Unterschrift, dass er die Verordnung bzw. den Richtlinien der Kammer überwacht und insbesondere auf die Einhaltung der maximal zulässigen Prüfungszeit geachtet hat. Das in der Dokumentation beschriebene Projekt wurde vom Prüfling selbstständig, ohne fremde Hilfe, bearbeitet. Ort, Datum Stempel, Unterschrift

6

7 Hochverfügbarkeits - Cluster Verzeichnisse Inhaltsverzeichnis 1 Einleitung Aktive / Passiv Aktiv / Aktiv Planung Projektszenario Ist Analyse Soll-Zustand: Sollplanung Zeitplanung Wirtschaftlichkeitsanalyse Einteilung in Verfügbarkeitsklassen Ausfallzeit Kostenplanung Durchführung Distribution Vorbereitung Installation DRBD Pacemaker / Heartbeat MySQL Abweichungen Ergebnisse Projektergebnisse Qualitätssicherung Fazit Quellenverzeichnis Glossar Anhang Testprotokoll Konfigurationsdateien Stephan Erdmann Montag, 20. Dezember 2010 Seite - 7 -

8 Verzeichnisse Hochverfügbarkeits - Cluster Seite Montag, 20. Dezember 2010 Stephan Erdmann

9 Hochverfügbarkeits - Cluster Verzeichnisse Abbildungsverzeichnis Abbildung 1 Single Point of Failure Abbildung 2 Redundantes System Abbildung 3 bisheriges Funktionsschema Abbildung 4 zukünftiges Funktionsschema Abbildung 5 Projektablauf Abbildung 6 Zeitplanung Abbildung 7 Verfügbarkeitsverlauf Abbildung 8 Break - Even Analyse Abbildung 9 Basisinstallation Abbildung 10 Arbeiten in der Shell Abbildung 11 Master / Master Prinzip Abbildung 12 Realer Zeitbedarf Abbildung 13 Vergleich Tabellenverzeichnis Tabelle 1 Ausfallwahrscheinlichkeit Einzelsystem Tabelle 2 Ausfallzeit Tabelle 3 Verfügbarkeit Tabelle 4 Fixkosten Tabelle 5 Hardwareauswahl Tabelle 6 Relative Kosten Tabelle 7 Ausfallkosten Tabelle 8 Testumgebung Tabelle 9 RAID Konfiguration Tabelle 10 Netzwerkkonfiguration Tabelle 11 Softwarepakete Tabelle 12 Heartbeat Ressourcen Tabelle 13 Glossar Tabelle 14 Testprotokoll Stephan Erdmann Montag, 20. Dezember 2010 Seite - 9 -

10 Verzeichnisse Hochverfügbarkeits - Cluster Seite Montag, 20. Dezember 2010 Stephan Erdmann

11 Hochverfügbarkeits - Cluster Einleitung 1 Einleitung Aufgrund bemerkbarer Tendenzen der IT Branche hin zur wachsenden Bedeutung der Themen Ausfallsicherheit und Linux wurde ein Hochverfügbarkeits Cluster als Thema dieses Projektes gewählt. Das Prinzip von Hochverfügbarkeit basiert auf Redundanz. Hierbei gilt es möglichst alle Single Point of Failure zu beseitigen um zu verhindern dass der Ausfall einer einzelnen Komponente zum Ausfall des Systems führen kann. Ein solcher Sinlge Point of Failure wie in Abbildung 1 dargestellt ist eine Komponente des Gesamtsystems welche für die Funktionalität des Gesamtsystems unerlässlich ist. Beispielsweise könnte hierbei die Stromversorgung genannt werden, da kein Computer ohne Strom arbeiten kann. Abbildung 1 Single Point of Failure Für ein hochverfügbares System ist es unerlässlich solche Komponenten zu vermeiden, denn ein Ausfall einer einzelnen Komponente ist stets zu erwarten und muss selbst bei hochwertigsten Komponenten eingeplant werden. Wie in Abbildung 2 ersichtlich kann dies erreicht werden, indem redundante Systeme als Ausweichmöglichkeit in das Gesamtsystem integriert werden. Fällt hier eine einzelne Komponente aus, so kann die Ersatzkomponente genutzt werden um die Funktionalität aufrechtzuerhalten. Abbildung 2 Redundantes System Zu diesem Zwecke wurde ein typisches Szenario entworfen, welches diese Art von Projekt als Auftrag vorsehen würde, konkret genannt wäre dies eine Marketingfirma deren Datenbankserver auf Basis von Linux, PHP und MySQL das zentrale Arbeitsmittel darstellt. Ein Dienst innerhalb eines Firmennetzwerkes also, dessen Ausfall einen unmittelbaren und erheblichen Ausfall der Produktivität eines Unternehmens darstellen würde, der damit sämtliche Bedarfskriterien für Hochverfügbarkeit erfüllt. Prinzipiell gibt es zwei unterschiedliche Ansätze einen solchen Cluster zu planen. Stephan Erdmann Montag, 20. Dezember 2010 Seite

12 Planung Hochverfügbarkeits - Cluster 1.1 Aktive / Passiv Hierbei laufen sämtliche Anfragen zunächst auf einem aktiven primären Node, während ein zweiter, passiver Node als Backupsystem fungiert. Fällt der primäre Node aus, so werden die Dienste auf dem sekundären Node gestartet und diese Aufgaben übernommen. Hiermit kann also eine prinzipielle Verfügbarkeit innerhalb kurzer Zeit gewährleistet werden. Eine durchgehende Verfügbarkeit ist jedoch nicht erzielbar, da vom Moment des Erkennens eines Ausfalls bis zum Starten der Dienste auf dem sekundären Node etwas Zeit verstreicht. Auch etwaige Performanceverbesserungen sind nicht möglich, da immer lediglich ein aktiver Node zur Verfügung steht. 1.2 Aktiv / Aktiv Hierbei handelt es sich um einen Cluster aus zwei oder mehr Nodes, die sich eine gemeinsame Aufgabe teilen können. Der Vorteil dieser Methode besteht neben einer Performancesteigerung aufgrund von Lastverteilung darin, dass die potentielle Ausfallzeit auf null gesetzt werden kann. Da mindestens ein zweiter Node nach wie vor die Aufgaben abarbeitet wird lediglich die Rechenleistung auf dessen Kapazität beschränkt. Ein Ausfall der Funktionalität tritt nur dann ein, wenn während der Wartungstätigkeiten an einem Node alle übrigen Nodes ebenfalls ausfallen. 2 Planung 2.1 Projektszenario Die Firma Mustermann GmbH ist ein mittelständisches, profitorientiertes Unternehmen mit zehn Mitarbeiter, welches sich darauf spezialisiert hat im Auftrag verschiedener Kunden Marktforschung zu betreiben. In ihrem Unternehmensprofil bietet die Firma unter Anderem die Erstellung, Erfassung, Analyse und Auswertung von Befragungsbögen an, anhand derer neue Produkte auf ihre Markttauglichkeit untersucht werden und neue Produkte entwickelt werden. Zu diesem Zweck arbeitet die Firma Mustermann GmbH seit geraumer Zeit mit einem Datenbanksystem zur Erfassung dieser Datensätze und der anschließenden Auswertung dieser Informationen. Da die Firma zu Beginn ihrer Unternehmung über eine geringe Liquidität verfügte hatte sie damals ein IT Unternehmen damit beauftragt ihnen eine kostenniedrige und stabile Lösung hierfür einzurichten. Hierzu wurde damals ein Server auf Basis von Linux, konkret gesagt die Distribution Debian mit der Codebezeichnung Lenny, aufgesetzt. Der Server arbeitet mit dem Datenbanksystem MySQL während das Frontend aus Webformularen mittels PHP besteht, die auf einem Apache Webserver arbeiten. Dieser Web- und Datenbankserver arbeitet ausschließlich innerhalb des Intranets der Firma und wird auf einem dedizierten Host betrieben, der mittels RAID 5 und USV grundsätzliche Prinzipien der Sicherheit gegen Datenverluste erfüllt. Seite Montag, 20. Dezember 2010 Stephan Erdmann

13 Hochverfügbarkeits - Cluster Planung 2.2 Ist Analyse Die Firma musste im vergangenen Quartal einen vollständigen Serverausfall aufgrund einer defekten Hardwarekomponente erleben. Während dieses Ausfalls konnten keine Zugriffe auf die Datenbanken gewährt werden, was einen erheblichen Produktivitätsausfall zur Folge hatte. Abbildung 3 bisheriges Funktionsschema Abbildung 3 bietet eine anschauliche Darstellung des funktionellen Zustandes vor Projektbeginn. 2.3 Soll-Zustand: Bei einem Ausfall des Servers soll gewährleistet werden, dass die Datenbank weiterhin genutzt werden kann. Hierzu wurde spezifiziert, dass dies mittels eines Serverclusters erreicht werden soll, der geplant, installiert, konfiguriert, getestet, dokumentiert und präsentiert werden soll. Desweiteren soll die Wirtschaftlichkeit dieses Projektes dargelegt werden Abbildung 4 zukünftiges Funktionsschema Abbildung 4 zeigt die gewünschte Funktionalität wie sie nach Abschluss des Projektes erzielt werden soll Stephan Erdmann Montag, 20. Dezember 2010 Seite

14 Planung Hochverfügbarkeits - Cluster 2.4 Sollplanung Um die Ziele des Projektes zu erreichen wurde die einzelnen Arbeitsschritte zunächst grob und später explizit aufgeschlüsselt um den Projektablauf planen zu können. Abbildung 5 Projektablauf Seite Montag, 20. Dezember 2010 Stephan Erdmann

15 Hochverfügbarkeits - Cluster Wirtschaftlichkeitsanalyse 2.5 Zeitplanung Insgesamt waren 35 Stunden für das Projekt inklusive Dokumentation vorgesehen. Da vorab zwar eine große Menge an Recherche betrieben wurde konnte das Thema zwar inhaltlich sehr gut geplant werden, aber eine zeitliche Einteilung erwies sich als weit weniger er einfach. 10 h 6 h Planung Durchführung 5 h 14 h Testphase Dokumentation Abbildung 6 Zeitplanung Abbildung 6 zeigt den geplanten zeitlichen Anteil der einzelnen Projektschritte. 3 Wirtschaftlichkeitsanalyse 3.1 Einteilung in Verfügbarkeitsklassen Grundlegende Vorüberlegungen ergaben, dass das Projekt zunächst auf seine Wirtschaftlichkeit geprüft werden muss. Diese Erkenntnis ergab sich vorab aus den verschiedenen Ansatzmöglichkeiten. Da ein hinreichender Belastungstest der verschiedenen Lösungsansätze den Rahmen dieses Projektes um mehrere Jahre überschreiten würde, wurde stattdessen eine mathematische Analyse mittels der Wahrscheinlichkeitslehre erstellt. Obwohl eine Performancesteigerung nicht notwendig ist, wurde dennoch ein Aktiv/Aktiv Cluster als Projektaufgabe festgelegt. Zum Einen weil der nur unwesentliche Mehraufwand gegenüber einer Aktiv/Passiv Lösung die zusätzlich verringerte Ausfallzeit am Mehrwert nicht überschreitet, zum Anderen weil ein Folgeprojekt zu einem Load Balancing Cluster nicht gänzlich ausgeschlossen werden sollte. Hierbei wurden die verschiedenen Lösungsansätze eingestuft auf branchenweit anerkannte Verfügbarkeitsklassen, die sich nach der Formel berechnen lassen. Die Einteilung der Klasse folgt dem Muster der Anzahl der aufeinander folgenden neunen. So zählt eine Verfügbarkeit von 0,9 oder einfacher ausgedrückt 90% als Klasse 1 wohingegen eine Verfügbarkeit von 99,99% zur Klasse 4 gezählt wird. Stephan Erdmann Montag, 20. Dezember 2010 Seite

16 Wirtschaftlichkeitsanalyse Hochverfügbarkeits - Cluster 3.2 Ausfallzeit Reparaturzeit Während sich in der Berechnung der Verfügbarkeit die Arbeitszeit anhand statistischer Werte zur Anzahl der Arbeitstage über mehrere Jahre abschätzen lässt muss die tatsächlich zu erwartende durchschnittliche Ausfallzeit pro Jahr komplizierter berechnet werden Zunächst einmal muss ein Wert für die durchschnittliche Reparaturzeit eines einzelnen Servers bei einem Ausfall geschätzt werden. Ein Ausfall könnte durch ein versehentliches manuelles Herunterfahren wie auch durch eine defekte Hardwarekomponente, die nachbestellt, werden müsste, verursacht sein. Da sich hierbei extrem unterschiedliche Zeiten ergeben wurde erfahrungsgemäß festgelegt, dass ein Ausfall nach durchschnittlich zehn Tagen behoben wäre Ausfallwahrscheinlichkeit eines einzelnen Servers Im Gegensatz zu einem Hochverfügbarkeitscluster kann ein einzelner Computer als eine Sammlung von Single Point of Failure betrachtet werden. So können einzelnen Komponenten des Servers wie CPU oder Mainboard, bzw. die Sammlung im Verbund arbeitender Komponenten wie Netzteile als mögliche Ursachen eines Ausfalls betrachtet werden. Da jede dieser Komponenten eine jährliche Ausfallwahrscheinlichkeit gemäß ihrer durchschnittlichen Lebenserwartung haben kann also die Wahrscheinlichkeit eines Ausfalls des einzelnen Servers im Jahr bei n Komponenten als Summe der Kehrwerte der Lebenserwartung berechnet werden. Da jedoch nicht von einem 24/7 Betrieb ausgegangen wird muss diese Wahrscheinlichkeit auf die Arbeitszeit verteilt werden um die zur Berechnungsgrundlage dienende Wahrscheinlichkeit P des einzelnen Servers auszurechnen Das zugehörige Wahrscheinlichkeitsmodell hierzu wäre das mehrmalige Ziehen von Losen mit zurücklegen aus einem Topf. Unschwer erkennen lässt sich, dass langlebige hochwertige Komponenten wie ECC Speicher oder redundante Komponenten wie mehrere Netzwerkkarten die Ausfallwahrscheinlichkeit drastisch senken. Komponente erwartete Lebensdauer Wahrscheinlichkeit eines Ausfalls pro Jahr CPU 10 7% Mainboard 10 7% Arbeitsspeicher 5 14% RAID 10 7% Netzwerkkarte 10 7% USV 6 11% Stromversorgung 5 14% Netzwerkkabel 15 5% Switch 10 7% Summe 78% Tabelle 1 Ausfallwahrscheinlichkeit Einzelsystem Seite Montag, 20. Dezember 2010 Stephan Erdmann

17 Hochverfügbarkeits - Cluster Wirtschaftlichkeitsanalyse Ausfallwahrscheinlichkeit eines Clusters Als Berechnungsgrundlage für den Clusterausfall dient die Ausfallwahrscheinlichkeit des einzelnen Servers. Hinzu kommt die Verteilung der Ausfälle auf Ausfallfenster. Erst wenn der zweite Server ausfällt während der erste Server repariert wird fällt der Cluster aus. Hierzu muss der Quotient aus Reparaturzeit zu Arbeitstagen mit einbezogen werden und das Wahrscheinlichkeitsmodell eines Würfelwurfes mit mehreren Würfeln betrachtet werden. Dies ergibt folgende Formel zur Berechnung der Wahrscheinlichkeit des Clusterausfalls: Ausfallzeit berechnen Will man nun die tatsächlich zu erwartende Zeitspanne die ein System pro Jahr ausfällt berechnen um mit ihr die Verfügbarkeitsklasse zu bestimmen, so muss nun die Wahrscheinlichkeit des Ausfalls noch mit der Reparaturzeit multipliziert werden. Anzahl der Nodes Wahrsch. des Einzelausfalls pro Jahr 77,626% 77,626% 77,626% durchschnittliche Ausfallzeit pro Jahr in Stunden in Minuten in Sekunden 43,470 h 2608,22 min ,2 sek 0,026 h 1,59 min 95,2 sek 0,001 h 0,03 min 2,1 sek Tabelle 2 Ausfallzeit Stephan Erdmann Montag, 20. Dezember 2010 Seite

18 Wirtschaftlichkeitsanalyse Hochverfügbarkeits - Cluster Verfügbarkeit Gemäß der zuvor genannten Formel zur Berechnung der Verfügbarkeit können die Lösungen wie folgt in Verfügbarkeitsklassen eingeteilt und statistisch betrachtet werden. durchschnittliche Ausfallzeit pro Jahr Anzahl der Nodes in Stunden in Minuten in Sekunden Verfügbarkeit Klasse 1 43,470 h 2608,22 min ,2 sek 99,280706% 2 2 0,026 h 1,59 min 95,2 sek 99,999559% 5 3 0,001 h 0,03 min 2,1 sek 99,999990% 7 Tabelle 3 Verfügbarkeit Grafisch ließe sich dieser Verlauf wie folgt darstellen: Verfügbarkeitsverlauf 99,950% 99,850% 99,750% 99,650% 99,550% 99,450% Verfügbarkeitsverlauf 99,350% 99,250% Anzahl der Nodes Abbildung 7 Verfügbarkeitsverlauf Wie sich sowohl in Tabelle 3 als auch in Abbildung 7 sehr gut sehen lässt kann mit der Erweiterung eines Client Server Netzwerkes auf ein Cluster basiertes System ein deutlicher Anstieg der Verfügbarkeit gewährleistet werden. Gleichzeitig zeigt sich jedoch auch, dass eine weitere Aufwertung durch zusätzliche Nodes nur noch minimale Verbesserungen erzielt werden können. Seite Montag, 20. Dezember 2010 Stephan Erdmann

19 Hochverfügbarkeits - Cluster Wirtschaftlichkeitsanalyse 3.3 Kostenplanung Entstehende Kosten bei der Realisierung Die Firma Mustermann GmbH müsste bei einer Realisierung dieses Projektes innerhalb ihrer Produktivumgebung mit mehreren Kostenfaktoren rechnen. Neben den reinen Hard und Softwarekosten kämen insbesondere Arbeitsstunden für die Implementierung und Überprüfung der Funktionalität sowie eine Schulung der Administratoren des Servers hinzu. Da für eine Realisierung zwar zwei Server benötigt werden, die bisherige Lösung jedoch bereits über einen verfügt wurde hierbei lediglich die zusätzlich benötigte Hardware erfasst. Kostenpunkt Menge Einzelpreis Gesamtpreis Server , ,00 Switch 1 300,00 300,00 Patchkabel 2 2,50 5,00 Arbeitsstunden 20 50, ,00 Produktionsausfall , ,00 Summe ,00 Tabelle 4 Fixkosten Zu berücksichtigen gilt bei der Kostenplanung, dass dieses Projekt, wie beantragt, im Wesentlichen eine Machbarkeitsstudie ist. Demzufolge konnten keine tatsächlichen Liefer- und Preisbedingungen verhandelt werden und mussten als statistischen Mittelwert der letzten Tage und Wochen der folgenden Komponenten erfasst werden. Gesamt Bezugs preis quelle 364,00 kg computing 332,98 amazon Komponente Bezeichnung CPU Intel Xeon E5620 (4 Kerne, 2,40 GHz, 12 MB L3, 80 W) Mainboard Asus Rampage III Extreme 90-MIBC10- G0EAY00Z Mainboard Sockel 1366 Intel X58 Arbeitsspeicher Kingston Valueram 2GB Arbeitsspeicher (1333MHz, DDR3, ECC CL9) Netzwerk Intel Pro/1000MT Netzwerkkarte (PCI-e, 2x karte LAN 10/100/1000TX) Festplatte Western Digital WD20EARS Caviar Green 668,12 kg computing 335,40 amazon RAID- Controller 2TB interne Festplatte 3ware Escalade 9650SE-4 Controller RAID PCI-Express Men Einzelpreis ge 1 364, , , , , ,15 304,15 rexstone Netzteil Seasonic SS-520H2U 520 Watt 2 121,29 Gesamtpreis 2423,87 Tabelle 5 Hardwareauswahl 176,64 okluge 242,58 amazon Stephan Erdmann Montag, 20. Dezember 2010 Seite

20 Wirtschaftlichkeitsanalyse Hochverfügbarkeits - Cluster Da die Hardware Kosten deutlichen Schwankungen unterliegen könnten diese Werte also sowohl nach oben als auch nach unten abweichen je nach Zeitpunkt der Bestellung. Neben diesen Fixkosten müssen auch hinzukommende relative monatliche Kosten berücksichtigt werden. Hierbei handelt es sich wie in Tabelle 6 zu sehen um zusätzlichen Strombedarf und zusätzliche Arbeitsstunden für die IT Abteilung der Firma bei der Administration des Systems. Kostenpunkt Menge pro Monat Einzelpreis Gesamtpreis Strom 144 KWh 0,26 37,44 Arbeitsstunden 2 h 50,00 100,00 Summe 137,44 Tabelle 6 Relative Kosten Gewinnplanung Neben zusätzlichen Kosten generiert eine Realisierung dieses Projektes aber auch, betriebswirtschaftlich gesehen, tatsächliche Einnahmen. Als solcher Gewinn darf zum Einen natürlich die kaum fassbare Vermeidung eines Imageverlustes bei Ausfallzeiten der Produktivität eines Unternehmens betrachtet werden. Dieser Gewinn sollte zwar nicht unerwähnt bleiben, soll aber aufgrund dieses nicht quantifizierbaren Wertes nicht in die Break Even Analyse einfließen. Was konkret als tatsächlich messbarer Gewinn genannt werden kann sind die zu zahlenden nicht produktiv genutzten Arbeitsstunden der Mitarbeiter während eines Serverausfalls. Anzahl der Nodes durchschnittliche Ausfallzeit pro Jahr Produktivität pro Stunde Kosten pro Jahr Ausfallkosten pro Monat 1 43,470 h 500, , ,26 2 0,026 h 500,00 18,88 1,10 3 0,001 h 500,00 1,16 0,02 Tabelle 7 Ausfallkosten Wie Tabelle 7 zeigt kann man die Differenz der Ausfallkosten, die pro Monat bei den jeweiligen Lösungen entstehen würden gegenüber dem Einzelserver, als tatsächlichen Gewinn verbuchen. Ebenfalls kann hier gesehen werden dass der vermutete Mehrwert der Erweiterung des Clusters auf 3 oder mehr Nodes nur noch minimales Einsparpotential bietet, weshalb an dieser Stelle der Lösungsansatz eines Clusters mit zwei Nodes festgelegt wurde. Seite Montag, 20. Dezember 2010 Stephan Erdmann

21 Hochverfügbarkeits - Cluster Wirtschaftlichkeitsanalyse Break Even Analyse Anhand der bekannten Fix und Relativkosten sowie den monatlichen Einsparungen bei einer Aktiv/Aktiv Cluster Lösung lässt sich grafisch wie in Abbildung 8 dargestellt feststellen, dass sich im Laufe des neunten Monats nach der Realisierung des Projektes dieses seine Kosten wieder amortisiert hat , , , , , , , , , , , , Cluster Einzelner Server Cluster Einzelner Server Cluster Einzelner Server Monate Abbildung 8 Break - Even Analyse Damit wäre die Wirtschaftlichkeit des Projektes nachgewiesen, da mit einer deutlich längeren Einsatzzeit der Server als lediglich neun Monate zu rechnen ist. Für den restlichen Nachweis dieser Machbarkeitsstudie wäre somit nur noch zu zeigen, dass ein solches System in der kalkulierten Zeit implementierbar ist und alle Funktionen erreicht werden können. Stephan Erdmann Montag, 20. Dezember 2010 Seite

22 Durchführung Hochverfügbarkeits - Cluster 4 Durchführung Im Laufe des Projektes wurde sowohl auf virtuellen Maschinen als auch auf realer Hardware die Installation und Konfiguration eines Linux HA-Clusters durchgeführt. Im ersten Schritt galt es mittels virtueller Maschinen zu testen und zu zeigen, dass ein solches Projekt prinzipiell im Rahmen der Vorgaben realisierbar ist. In einem zweiten Schritt wurde annähernd parallel dieses Projekt in einer realen Hardwareumgebung umgesetzt, da eine virtuelle Umgebung naturgemäßen Einschränkungen bei mehreren Testszenarien unterliegt. Hierbei wurden zwei baugleiche netzwerkfähige PCs mit folgender Hardwarekonfiguration gewählt: Komponente Bezeichnung Menge CPU AMD Opteron Mainboard ASUS A8R-MVP 1 Chipsatz ATI RD480 Netzwerkkarte Intel Pro/1000MT Netzwerkkarte (PCI-e, 2x LAN 1 10/100/1000TX) Festplatte 500GB Western Digital Caviar Blue (WD5000AAKS) 3,5", Serial-ATA/300 (3Gb/s), 16 MB Cache 4 Tabelle 8 Testumgebung Diese Testumgebung wurde gewählt, da sie in ausreichender Menge zur Verfügung stand und das Mainboard laut Hersteller über einen On Board RAID - Controller verfügt, welcher RAID 5 beherrscht, sowie über eine On Board LAN Karte verfügt. 4.1 Distribution Als Grundsystem der einzelnen Nodes wurde Linux in der Distribution Debian mit der Codebezeichnung Lenny gewählt. Zum Einen wird diese Wahl darin begründet, dass so eine kleinstmögliche Abweichung zum bisherigen System und damit einem kleinstmöglichen Schulungsbedarf gewährleistet wird, zum Anderen jedoch bietet Debian mit eine der stabilsten Linux varianten aufgrund einer sehr strengen Paketverwaltungspolitik. 4.2 Vorbereitung RAID Als überraschende Schwierigkeit im Rahmen des Projektes zeigte sich die RAID Konfiguration. Das Mainboard verfügte zwar über einen hauseigenen RAID Controller und das Aufrufen und Konfigurieren des RAID BIOS bestätigte zwar die RAID 5 Fähigkeit, aber beim Installieren von Linux wurde dieses RAID nicht erkannt. Bei einer Testinstallation mit Windows XP wurde festgestellt, dass sich überraschend ein RAID - Treiber als Notwendigkeit für ein Erkennen der Festplatte erwies. Nach einiger Recherche entpuppte sich also besagter RAID Controller als ein sogenannter Fake RAID. Hierbei handelt es sich um ein Software RAID, welches durch geschicktes Marketing als echtes Hardware RAID vertrieben wird. Seite Montag, 20. Dezember 2010 Stephan Erdmann

23 Hochverfügbarkeits - Cluster Durchführung Da die Treibersuche für Linux mitunter sehr aufwendig werden kann und mit einer besseren, weil kompatibleren Variante, Performance durch das Betriebssystemeigene Software RAID zu rechnen war, wurde besagtes RAID aufgelöst und bei der Installation von Linux hierdurch ersetzt. Aufgrund der Natur eines Software RAIDs stellten sich hier neue Aufgabenstellungen. Die ursprünglich geplante RAID Konfiguration wie in Tabelle zu sehen konnte so nicht mehr aufgebaut werden, da das RAID 5 der boot Partition erst nach hochfahren des Betriebssystems verarbeitet werden kann. Die Aufteilung der Datenpakete konnte so nicht gemacht werden, weshalb die kompliziertere Partitionierung notwendig wurde Partition Mountpunkt Geplant Boot /boot RAID 5 Verbund a 2% pro Festplatte System / RAID 5 Verbund a 45% pro Festplatte DRBD /drbd RAID 5 Verbund a 45% pro Festplatte SWAP - RAID 5 Verbund a 3% pro Festplatte Tabelle 9 RAID Konfiguration Realisierung RAID 1 Verbund a 2% pro Festplatte RAID 5 Verbund a 45% pro Festplatte RAID 5 Verbund a 45% pro Festplatte RAID 5 Verbund a 3% pro Festplatte Notwendig wurde diese kompliziertere Partitionierung, da in der Boot Partition der grub bootloader installiert wird. Grub ist hierbei dafür verantwortlich Linux zu starten, muss also bereits vor dem Hochfahren des Betriebssystem und damit des RAIDs verfügbar sein. Das RAID Level 1, bei dem die Komponenten des RAID Verbundes alle die vollständigen Daten enthalten bot sich als optimale Lösung hierfür an. Bei einer Realisierung in einem Produktivumfeld wird selbstverständlich ein echtes Hardware RAID empfohlen was diese aufwendige Lösung überflüssig macht, da hierbei das RAID bereits auf Hardwareebene verfügbar ist Netzwerk Da die Netzwerktopologie eines Clusters sowohl einen externen Zugang als auch eine interne Replikation untereinander vorsieht war es unumgänglich mindestens zwei Netzwerkkarten einzubauen und zu konfigurieren. Vorgesehen hierbei ist die Anbindung in zwei Subnetze, die wie folgt aufgebaut sind: Server 1 Server 2 Netzwerkkarte IP Adresse Subnetmaske IP Adresse Subnetmaske eth eth Tabelle 10 Netzwerkkonfiguration Hierbei spielt die Netzwerkkarte eth0 jeweils die Rolle der physischen Anbindung an das firmeneigene Intranet, während eth1 für ein extra Subnetz genutzt wird über welches die einzelnen Nodes sich gegenseitig synchronisieren. Stephan Erdmann Montag, 20. Dezember 2010 Seite

24 Durchführung Hochverfügbarkeits - Cluster 4.3 Installation Basisinstallation Zunächst wurde im Expertenmodus eine Grundinstallation durchgeführt. Hier konnten gleich die später notwendigen Pakete Open-SSH und ein manuelles Partitionierungsmodul mit installiert werden. Auf eine grafische Oberfläche und Komponenten wie DNS - oder DHCP Server wurde selbstverständlich verzichtet, da sie reine Verschwendung von Resourcen darstellen würden. Von hier ab galt es also in der Shell zu arbeiten. Abbildung 9 Basisinstallation Abbildung 10 Arbeiten in der Shell Sourceliste Linux bietet die vielseitige Möglichkeit ein Betriebssystem genau auf die Bedürfnisse angepasst zu bauen. Dies geschieht vorwiegend über die Einbindung von Softwarepaketen, welche gemäß eines Eintrages in eine Liste von Bezugsquellen unter ~/etc/apt/sources.list über das bordeigene Paketverwaltungstools aptitude bezogen, eingebunden und installiert wird. Bei diesem Projekt wurden neben den eigentlichen Installations DVDs noch der Eintrag deb lenny-backports main contrib non-free benötigt und bekannt gemacht werden über die Shell Befehle wget O apt-key add - apt-key adv keyserver pgp.mit.edu recv-key 1CFA3E8CD7145E30 Ein anschließendes Aufrufen von apt-get update band diese Quellen ein. Seite Montag, 20. Dezember 2010 Stephan Erdmann

25 Hochverfügbarkeits - Cluster Durchführung Softwarepakete Neben dem eigentlichen Betriebssystem mussten folgende Pakete daraufhin mittels aptitude eingebunden und installiert werden: Paketname Linux-image Linux-headers Linux-source sysv-rc-conf ssh bzip2 make gcc fakeroot git-core debconf-utils sp docbookutils docbook flex dpatch debhelper xsltproc autotoolsdev automake autoconf libtool docbook-xsl-doc-text docbook-xsl module-assistant Verwendungszweck Update des Linux Kernels auf Version DRBD ntpdate pacemaker heartbeat Heartbeat / Pacemaker xorg fluxbox pacemaker-mgmt pacemaker-mgmt-client GUI von Pacemaker graphviz Tabelle 11 Softwarepakete 4.4 DRBD DRBD dient als Replikationslaufwerk für die PHP Dateien. Folglich wird hier später der Apache Webserver so konfiguriert, dass er die Anfragen auf die Formulare hier finden soll Installation Neben den bereits installierten Paketen muss noch die passende Version aus dem GIT Repository geholt werden um die zu installierenden Pakete drbd8-utils.deb und drbd8- modules.deb zu bauen. Dies geschieht über die Befehlszeile git clone git://git.drbd.org/drbd-8.3.git tar xfvj drbd-8.3.tar.bz2 cd drbd-8.3 dpkg-buildpackage rfakeroot b uc Um die Pakete zu installieren genügte anschließend der Befehl dpkg i *.deb Sowie der folgende Befehl um die Module im Kernel einzubinden module-assistant auto-install drbd8 Abschließend musste noch in der Datei /etc/modules ein Eintrag erfolgen um das Laden der Module beim Starten des Betriebssystems zu gewährleisten. Stephan Erdmann Montag, 20. Dezember 2010 Seite

26 Durchführung Hochverfügbarkeits - Cluster Konfiguration Die Konfiguration von DRBD geschieht über eine Resource t3 welche als Datei /etc/drbd.d/t3.res erstellt werden muss. Hier muss neben dem Namen der Resource angegeben werden auf jeweils welchem Node sich welches device auf welcher Partitionierung und über welche Leitung replizieren soll. Diese Datei muss ebenso wie die globalen Einstellungen der Datei /etc/drbd/global_common.conf identisch auf beiden Nodes sein. Der Einfachheit halber werden sie also einfach auf den anderen Node kopiert Initialisierung Um DRBD letztlich zum Laufen zu bekommen muss die Resource t3 nun erstellt und initialisiert werden. Mit drei einfachen Befehlen ist dieser Vorgang abgeschlossen: drbdadm create-md t3 drbdadm -- --overwrite-data-of-peer primary t3 mkdir.ext3 /dev/drbd0 4.5 Pacemaker / Heartbeat Installation Mit der Installation des Softwarepaketes wurde die eigentliche Installation bereits abgeschlossen. Zu Berücksichtigen galt hierbei die Bedeutung von NTPdate, welches die Uhren der Nodes synchronisiert und so ein unbeabsichtigtes veraltetes Update verhindert. Apache und MySQL können zu diesem Zeitpunkt bereits installiert worden sein, jedoch sollte die detaillierte Konfiguration erst später erfolgen Konfiguration Um das Managementtool mit grafischer Oberfläche zu nutzen muss der pacemaker GUI ein auf beiden Nodes identisches Passwort für den Clusteruser vergeben werden. Konfiguriert wird Heartbeat / Pacemaker mittels der Datei /etc/ha.d/ha.conf in welcher die Nodes, die Kommunikation zwischen den Nodes (mit dem Begriff bcast), ein Netzwerktest mittels ping und die Fähigkeit durch die GUI verwaltet zu werden eingetragen sein müssen. Die gegenseitige Authentifizierung erfolgt als Eintrag in der Datei /etc/ha.d/authkeys. Wichtig hierbei stellt sich eine ausreichend sichere Rechtevergabe dar ohne die Heartbeat den Dienst verweigert. Abschließend gestartet werden kann Heartbeat nun mit dem Befehl /etc/init.d/heartbeat start Seite Montag, 20. Dezember 2010 Stephan Erdmann