Aufbau eines auf Linux basierenden Hochverfügbarkeitssystems

Transkript

1 Dokumentation der betrieblichen Projektarbeit Aufbau eines auf Linux basierenden Hochverfügbarkeitssystems Dennis Wisnia Auszubildender zum Fachinformatiker Fachrichtung Systemintegration Prüflingsnummer: Projektverantwortlicher: Achilleas Anastasiadis Hostway Deutschland GmbH Am Mittelfeld Hannover

2 Inhalt 1 Einleitung Projektumfeld Projektbeschreibung Projektdefinition Abweichung vom Projektantrag Ist-Analyse Soll-Konzept Projektrealisierung Installation Server Installation DRBD Installation Heartbeat Installation MySQL Projektkonfiguration Konfiguration DRBD + Heartbeat DRBD Heartbeat Konfiguration MySQL Master-Slave Tests Projektabschluss und Fazit Anhang Begriffserklärung STONITH Verfahren Hardware Konfiguration der Server Quellen... 14

3 1 Einleitung 1.1. Projektumfeld Das Projekt fand in der technischen Abteilung der Firma Hostway Deutschland GmbH statt. Hostway ist einer der größten Internet Service Provider (ISP) weltweit. Hostway verfügt über mehrere Standorte auf der ganzen Welt, unter anderem in Hannover. Dieser umfasst zwei Rechenzentren, die gemeinsam über Webauftritte bereitstellen. Die Firma wurde unter dem Namen Server-Service im Jahre 1999 gegründet und fusionierte 2005 mit der Hostway Corporation, 2008 fand dann die Umfimierung in Hostway Deutschland GmbH statt Typografische Konventionen In Courier New geschriebene Wörter sind direkte Befehle oder Pakete aus Linux. Ein Teil der Fremdwörter wird im Anhang in der Begriffserklärung erklärt. 2 Projektbeschreibung 2.1. Projektdefinition Die Webpräsenz der Firma Hostway Deutschland liegt momentan auf einem einzelnen Server. Dieser Server ist am Ende seines Lebenszyklus und bedarf einer Überholung. Da ein einzelner Server zudem keine Ausfallsicherheit bietet, entstand der Bedarf nach einem redundanten System. Ein Ausfall der Firmenwebsite hätte eine Schädigung des Firmen-Images und wirtschaftliche Einbußen zur Folge. Die Website hat pro Monat mehrere tausend Aufrufe, die ein Server mit aktueller Hardware ohne weiteres verarbeiten kann. Um die Verfügbarkeit im Falle eines Hardwaredefekts gewährleisten zu können, fiel die Wahl auf ein Hochverfügbarkeitssystem mit DRBD, ein System welches ein RAID 1 über Netzwerk ermöglicht, und Heartbeat, welches die Systeme kontrolliert und dementsprechend die einzelnen Dienste abhängig vom Status des Servers verwaltet. Um einen Ausfall auf Netzwerkbasis zu umgehen, werden die Server in verschiedenen Racks stehen und somit das Risiko eines Ausfalls minimieren. Seite 3 von 14

4 2.2. Abweichung vom Projektantrag Die Umsetzung des Projektes hat im Gegensatz zur Dokumentation aufgrund meiner Erfahrung in diesem Bereich nicht die erwartete Zeit beansprucht. Daher konnte ich die gewonnene Zeit in der Umsetzung für die Projektdokumentation einsetzen. Die Vorbereitung und Planung funktionierten wie geplant. Genauso wie der Projektabschluss und abschließende Tests. Arbeitsschritt geplanter Zeitaufwand (in Stunden) tatsächlicher Zeitaufwand (in Stunden) Vorbereitung 1 1 Planung 2 2 Umsetzung Dokumentation 6 11 Projektabschluss 6 6 Summe: Ist-Analyse Die Firmenseite läuft momentan nur auf einem Server, was im Falle eines Hardwaredefekts oder Versagens der Netzwerktechnik einen Ausfall der Firmen-Webpräsenz zur Folge hat. Der Server ist zudem ein älteres Modell und somit am Ende seines Lebenszyklus Soll-Konzept Aufgabe war es, ein Projekt vom Anfang bis zum Ende selbstständig zu planen und durchzuführen. Ich entschied mich für das Thema HA (High Availability) - also ein Hochverfügbarkeitssystem. Das System wird auf Linux (Debian GNU Linux) aufbauen und mit zwei Servern umgesetzt. Als Software kommen "DRBD" und "Heartbeat" zum Einsatz. Mit DRBD ist man in der Lage, ein Raid 1 (Zwei Datenträger werden gespiegelt, über DRBD geschied dies auf Basis von TCP/IP) zu erstellen, Heartbeat steuert den Master und den Slave und regelt, wann welcher Server die Rolle des Masters übernimmt. Seite 4 von 14

5 Gespiegelt wird lediglich das /var/www Verzeichnis, in welchem die für die Website relevanten Daten liegen. Als Webserversoftware kommt Apache in Version 2 zum Einsatz. Abbildung 1: Server und Switches sind redundant und replizieren sich über die Crossover Verbindung Das System wird auf zwei identischen Servern laufen. Identisch bedeutet, dass beide Server gleich aufgesetzt sind, die gleiche Hardwareausstattung haben und identisch partitioniert sind. Beide Systeme sind in verschiedenen Racks mit redundanter Netzwerkanbindung angebunden, um einen Ausfall durch einen defekten Switch auszuschließen zu können. Untereinander werden die Server mit einem Crossoverkabel (CAT-5) verbunden, um die Daten nahezu in Echtzeit zu synchronisieren und die öffentlichen Netzwerkverbindungen nicht unnötig zu belasten. Des weiterem bringt dies höhere Übertragungsraten mit sich, da z.b. Jumbo Frames benutzt werden können. Seite 5 von 14

6 3 Projektrealisierung 3.1. Installation Server Die Server wurden in unterschiedlichen Racks im Rechenzentrum Hannover mit einer automatisierten Installationsroutine installiert und grundkonfiguriert. Durch diese Installationsroutine wird ein Debian Linux mit dem Codenamen Lenny automatisch mit den neuesten Updates installiert. Die wichtigsten Tools für den Serverbetrieb werden mitinstalliert, um nach kurzer Zeit einen funktionsfähigen Server zur Verfügung zu stellen. Danach mussten lediglich die IP-Adressen, Hostname und Passwort angepasst werden, um für das Projekt vorbereitet zu sein Installation DRBD Bei der Installation von DRBD wurde auf Pakete aus den offiziellen Debian-Quellen gesetzt. Nach der Installation aus den Paketquellen wurde DRBD zwar installiert, jedoch fehlten noch die Kernelmodule. Diese mussten neu kompiliert werden. Das Verhalten war außerplanmäßig und bedurfte einer kleinen Nachbesserung. Die Pakete drbd8-modulesource drbd8-source build-essential linux-headers-2.6 schafften Abhilfe und nach der Installation dieser wurde das korrekte Kernelmodul geladen und DRBD konnte von nun an konfiguriert werden Installation Heartbeat Die Installation von Hearbeat verlief ohne Probleme und war nach einem aptitude install heartbeat erledigt. Im Gegensatz zu DRBD war Heartbeat danach funktionsfähig Installation MySQL Die Entscheidung fiel zu Gunsten einer Master/Slave Replikation. Sollte der Fall eintreten, dass der Slave übernimmt, so ist dennoch menschliches Eingreifen nötig, um den vorherigen Zustand widerherzustellen. Bei einem Ausfall des Masters übernimmt vorerst der Standby- Server. Der Slave ist allerdings ein Read Only System was die Auslierferung der aktuellen Website übernimmt, aber eine Änderung der Daten nicht zulässt. Sobald der Master repariert wurde, können die Inhalte der Website wieder angepasst werden. Hierzu muss zunächst der Master/Slave Zustand manuell widerhergestellt werden. Bei der gewollten Konfiguration von MySQL, also der Master/Slave Variante, verlief auf beiden Servern die Installation von MySQL gleich. Es wurde lediglich das Paket mysqlserver benötigt, was eine schnelle und einfache Installation durch Aptitude mit allen Seite 6 von 14

7 Abhängigkeiten ermöglicht. Nach dem setzen des MySQL Root Passworts war die Grundinstallation abgeschlossen und es konnte mit der Konfiguration begonnen werden. 4 Projektkonfiguration 4.1. Konfiguration DRBD + Heartbeat DRBD Nachdem die Konfigurationsdatei angepasst wurde, erstellt man mit drbdadm createmd ressourcenname die Metadaten für den Container, der über das DRBD gespiegelt werden soll. Nachdem die Metadaten auf beiden Servern geschrieben wurden, ernennt man den Master Server (web01) zum primären System. drbdsetup /dev/drbd0 primary --overwrite-data-of-peer Danach kann man kann mit mkfs.xfs /dev/drbd0 das Dateisystem (in diesem Fall das Dateisystem XFS) auf dem neuen Server erstellen. Gemountet werden kann es erst, nachdem formatiert wurde. Danach ist die Konfiguration von DRBD abgeschlossen, für den automatischen Wechsel zwischen Primary und Secondary ist Heartbeat verantwortlich Heartbeat Am Anfang muss eine Authkey -Datei angelegt werden, diese enthält einen Schlüssel, um die Server untereinander zu autorisieren. Nachdem dies geschehen ist, legt man fest, dass nur User mit root -Rechten darauf Zugriff haben. Anschließend konfiguriert man in wenigen Zeilen Heartbeat selbst. Die kommentierte Hauptkonfiguration von Heartbeat sieht man hier: Seite 7 von 14

8 debugfile /var/log/ha-debug #Das Debugfile für die Fehlermeldungen logfile /var/log/ha-log #Logfile für sämtliche Aktivitäten von Heartbeat logfacility local0 #Einstellung fürs Logging keepalive 1 #Die Zeit ab wann der andere Node für Toterklärt wird (in Sekunden) deadtime 10 #Die Zeit bis er Umschaltet warntime 4 #Die Zeit bis er anfängt zu warnen initdead 60 #nach 60 Sekunden wir der andere Server für Tod erklärt udpport 694 #Der Port auf dem Heartbeat lauscht ucast eth #Die IP des anderen Nodes bcast eth1 #Das Interface über das Heartbeat läuft (Crossover verkabelung) ping_group switch_link #die IP die nicht erreichbar sein darf bis heartbeat eingreift respawn hacluster /usr/lib/heartbeat/ipfail #Das Script was prüft ob der andere Server vorhanden ist. auto_failback off #Sobald der primäre Server wieder erreichbar ist wird nicht wieder zurückgeschaltet, weil nicht garantieren werden kann, dass der Primäre Server wieder vollkommen funktionstüchtig ist node web01 #Primärer Server node web02 #Sekundärer Server Die Konfiguration ist auf beiden Servern nahezu identisch. Es ändert sich lediglich die IP, die ping_group und der der Hostname(node). Diese ist immer die des jeweils entgegengesetzten Nodes. Die Anweisung für Heartbeat, was im Fall einer Ausfallsituation des Masters veranlasst werden soll, gibt man in der /etc/heartbeat/haresources an. Dort sind folgende Zeilen anzugeben: web01 drbddisk::www \ /28 \ Filesystem::/dev/drbd0::/var/www::xfs::noatime,nodiratime apache2 Seite 8 von 14

9 Diese Datei regelt folgende Aktionen: gibt an, dass die DRBD-Ressource www auf dem System eingebunden wird (Wechsel des Primär/Sekundär Status) bindet die IP als virtuelles Netzwerkinterface auf eth0 weitere Informationen zum DRBD mit den Angaben zum Filesystem und dem Mountpunkt startet Apache2 Alle Dienste werden im Falle des Slave Status auch gleichzeitig wieder deaktiviert und gestoppt. Hierbei sollte man noch erwähnen, dass Apache2 nicht mehr vom System gestartet wird, sondern dass Heartbeat die Steuerung der Dienste übernimmt. Um dies sicher zustellen muss der automatische Start mit dem folgenden Befehl auf beiden Systemen deaktivert werden. update-rc.d f apache2 remove Andernfalls würde der Apache2 zwar starten jedoch würden die Daten für den Webauftritt fehlen, was fatale Auswirkung auf den Betrieb hätte. Bevor man Heartbeat das erste Mal mit DRBD startet, bedarf es noch einer kurzen Anpassung der Rechte: chgrp haclient /sbin/drbdsetup chmod o-x /sbin/drbdsetup chmod u+s /sbin/drbdsetup chgrp haclient /sbin/drbdmeta chmod o-x /sbin/drbdmeta chmod u+s /sbin/drbdmeta Hier werden Heartbeat die Rechte für die Steuerung von DRBD gegeben. 4.2 Konfiguration MySQL Master-Slave Nachdem die Installation auf beiden Server gleich verlaufen ist, wird zunächst auf dem Master Server skip-networking und bind-address auskommentiert und die Server-ID auf 1 gesetzt. Hier ist zu beachten, dass man am Ende noch das Binäre Logging ( Log-Bin ) aktiviert und an einen Platz verlegt, wo man ausreichend Platz hat. In der Binären Logdatei werden alle Querys, also Zugriffe und Abfragen mit geschnitten um diese an den Slave zu übergeben dass dieser die selben Vorgänge vornehmen kann. Seite 9 von 14

10 Beim Slave Server ist zusätzlich hinzuzufügen master-host = master-user =repli master-password =Passwort master-connect-retry =60 Die Konfiguration ist an diesem Schritt fast abgeschlossen. Man benötigt lediglich noch einen Replikationsuser, der ähnlich wie root über alle nötigen Rechte auf allen Datenbanken verfügt. Am Ende konfiguriert man die Replikation mit wenigen Zeilen in der MySQL CLI. Wichtig hierbei ist, dass die Daten, master_log_file und master_log_pos auf beiden Systemen identisch sein müssen. CHANGE MASTER TO MASTER_HOST=' ', MASTER_USER='repli', MASTER_PASSWORD='Passwort', MASTER_LOG_FILE='mysql-bin ', MASTER_LOG_POS=98; START slave; Den Status der Replikation kann man jetzt mit dem SQL Befehl SHOW slave STATUS; kontrollieren und die laufende Replikation beobachten. 5 Tests Fall Master herunterfahren Slave herunterfahren Externes Netzwerkkabel ziehen Internes Netzwerkkabel trennen Ergebnis Heartbeat stellt es fest und schaltet auf den Slave Heartbeat stellt es fest und unternimmt keine Aktion Heartbeat unternimmt nichts. Splitbrain Situation Heartbeat erkennt automatisch eine sogenannte Split-Brain-Situation. Diese entsteht, wenn das interne Kabel defekt ist oder gezogen wurde. Ein vernünftiger Wechsel ist dann nicht mehr möglich. Man benötigt dann ein System in der Mitte, was ein STONITH Verfahren auslöst. Darauf wurde in diesem Fall verzichtet, weil die Wahrscheinlichkeit, dass das Kabel in der Mitte ausfällt, sehr gering ist. Dieses System kann zum Beispiel über IP gesteuerte Seite 10 von 14

11 Steckdose sein, die dann beim fehlerhaften System ausgeschaltet wird, um die Stromzufuhr zu unterbrechen. 6 Projektabschluss und Fazit Mit DRBD und Heartbeat kann man auf schnelle und kostengünstige Weise ein Hochverfügbarkeitssystem erstellen. Man hat alle wichtige Funktionen und Eigenschaften, die man für ein Hochverfügbarkeitssystem braucht. Man kann das STONITH Verfahren noch perfektionieren, aber da die Server zwar in verschiedenen Racks stehen, die wiederum nicht weit voneinander entfernt sind, ist die Wahrscheinlichkeit für einen Schaden am internen Kabel gering. Die Software die hier verwendet wurde ist komplett frei verfügbar weil alles auf OpenSource basiert. Somit benötigt man lediglich die Hardware. Hier ist drauf zu Achten dass diese Identisch ist um Fehlerquellen auszuschließen. Nach der Vorstellung der neuen Plattform vor der Geschäftsleitung der Hostway Deutschland GmbH und einigen Live-Tests wurde das System erfolgreich in Betrieb genommen und stellt seitdem die Verfügbarkeit des Webauftritts sicher. Seite 11 von 14

12 7 Anhang 7.1. Begriffserklärung Server Linux DRBD Heartbeat RAID MySQL Split-Brain STONITH Crossover- Verbindng aptitude ein Computer, der auf lange Laufzeiten und Performance ausgelegt ist ein freies Betriebssystem Distributed Replicated Block Device, was eine Erstellung eines Raid 1 über ein Netzwerk ermöglicht steuert DRBD und regelt die Dienste auf dem jeweiligen Master Server anhand der verschiedenen Raid Level kann man festlegen, in welcher Form die Daten über mehrere Laufwerke verteilt werden eine freie Datenbank-Engine, die es für sämtliche großen Betriebssysteme gibt beide Nodes gehen davon aus, dass sie die Masterrolle bekommen haben (engl. Shoot the other node in the head) bedeutet, dass Heartbeat, sobald es feststellt, dass ein anderes Device versucht, die Daten zu beschreiben, es einfach deaktiviert Eine direkte Server zu Server Verbindung ohne einen Switch dazwischen. Ein Paketmanager für Debian GNU Linux. Basiert auf apt-get und ist um einige Funktionen erweitert worden. So merkt sich Aptitude die Abhängigkeiten eines Paketes und beim Deinstallieren eines Programms werden alle Abhängigkeiten sauber mit entfernt. Seite 12 von 14

13 7.2. STONITH Verfahren Das STONITH Verfahren (Shoot the other node in the head) ist die Ausweitung des Themas. In dem Fall war es nicht notwendig weil der Kosten / Nutzen eher gering ist. Das STONITH Device kann eine über IP gesteuerte Steckdose sein. Diese wird dann im Fall eines Split- Brains von dem Slave ausgelöst um den Strom des Master Server zu deaktivieren, damit der Slave seinen Betrieb aufnehmen kann. Abbildung 2: Zwischen den Servern befindet sich das STONITH Device was in der Lage ist die Stromzufuhr der Server zu trennen. Seite 13 von 14

14 7.3. Hardware Konfiguration der Server Servertyp Dell Poweredge 850 CPU Arbeitsspeicher Pentium 4 2,80Ghz 1 GB DDR2 Festplatte 73 GB SCSI RAID 1 Netzwerk 2x 1 Gbit/s 7.4. Quellen auf-debian-etch/ Desweiteren wurden interne Quellen aus der Firmeninternen Wiki bezogen. Seite 14 von 14