Hochverfügbare Virtuelle Maschinen mit DRBD-mirrored Shared-Storage unter Linux

Inhaltsverzeichnis

1.Einleitung

2.Basistechnologien zur Realisierung hoch-verfügbarer virtueller Server-Systeme
2.1.Virtualisierung & Hochverfügbarkeit
2.2.IST-Zustand & Problemstellung
2.3.Voraussetzungen für eine Live-Migration

3.Entwurf eines hoch verfügbaren virtuellen Server-Systems
3.1.Aufbau des Storage-Cluster
3.1.1.Ausfalls-Szenario eines Storage-Servers
3.2.Aufbau des XEN-Clusters
3.2.1.Ausfalls-Szenario eines XEN-Servers
3.3.Interkonnektivität zwischen XEN-Cluster & Storage-Cluster
3.4.Netzwerk-Topologie zwischen Storage-Cluster, XEN-Cluster & Internet

4.Installation & Konfiguration
4.1.Storage-Cluster
4.2.XEN-Cluster

5.Zusammenfassung

6.Ausblick auf die 2. Bachelorarbeit im SS

Literaturverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Konfigurationsfiles für Storage-Server

storage.cfg

drbd.conf

cluster.conf

ietd.conf

ha.cf

authkeys

sdr_stonith

cib.xml

Konfigurationsfiles für XEN-Server

xenhost.cfg

cluster.conf

windows7

1. Einleitung

April 1994. Mein Vater, Dipl.-Ing. Friedrich Reichhart, und ich, Friedrich Reichhart, haben gerade erfolgreich ein OS/2 installiert und nach mühsamer Installationsprozedur mit einem 56K Modem ins Internet eingewählt. Das erste was wir uns anschauten, war ein Foto der Mona Lisa aus dem Louvre. Damals, gerade 14 Jahre alt, dachte ich mir ob man das jemals brauchen wird können? Webseiten, E-Mails,... Ich hatte damals eine E-Mail-Adresse, jedoch keiner meiner Freunde hatte eine und zum Teil nicht einmal einen Computer. Mit wem sollte ich also kommunizieren?

Dezember 2008. Ein Kunde hat mich gerade angerufen. Er kann seit 5 Minuten auf seine E- Mails nicht mehr zugreifen.

Gerade mal etwas mehr als 10 Jahre sind vergangen und E-Mail und Web-Seiten sind aus dem alltäglichen Leben nicht mehr wegzudenken.

Gekoppelt an diese Tatsache ist natürlich die Voraussetzung einer hoch verfügbaren ITLandschaft.

An sich, ist es nicht besonders komplex, eine ausfallsichere IT-Landschaft zu installieren. Vorausgesetzt, man hat das nötige Kleingeld. Dann reicht ein kurzer Anruf bei einem großen Distributor, man kauft sich die modernsten Clusterlösungen, dazu ein InstallationsDienstleistungsservice und dann lässt man sich auch noch mit dem entsprechenden Support eine permanente Verfügbarkeit garantieren.

Die andere Lösung, die auch für kleinere Betriebe und Firmen leistbar ist, und derer gibt es in Österreich überwiegend, findet sich im Bereich der OpenSource-Community.

Mein Vater und ich haben im Jahre 1999 die Firma sdr() - Software Development Reichhart GmbH gegründet. Diese beschäftigt sich neben der Entwicklung einer eigenen Software primär mit dem zur Verfügung stellen von Services, Diensten, Web-Applikationen und Spezial-Applikationen. Dabei geht es überwiegend um den Bereich Web-Dienste und CRM- Systeme, aber auch Spezial-Applikationen auf Basis JAVA und Apache-Tomcat. Die meisten dieser Dienste und Services laufen auf eigenen virtuellen Maschinen. Derzeit laufen bis zu 7 solcher Maschinen / Server mit durchschnittlich 512 - 1024 MB RAM. Da aber an den Ausbau dieses Geschäftsfeldes gedacht ist, muss diese gesamte Lösung erweitert und ausfallsicher gemacht werden.

Da wir uns also in meiner Firma seit einiger Zeit mit dem Thema der Virtualisierung beschäftigen und auch diverse virtuelle Server in Produktion haben, hat sich auch für uns intern die Frage nach einem ausfallsicheren System ergeben. Aus dieser Motivation heraus und dem interessanten Spezialisierungs-Schwerpunkt „Virtualisierung“ im Rahmen meines Bachelor-Studiums habe ich mich entschlossen mich in die Welt der Hochverfügbarkeit mit möglichst billiger Hardware und ausschließlich OpenSource-Software zu begeben.

Vor allem unter dem Fokus OpenSource-Software-Lösungen bin ich der Ansicht, dass diese Arbeit sehr am Puls der Zeit liegt, zumal die bisher verfügbare Version von DRBD, DRBD+ nur für den kommerziellen Einsatz verfügbar war, seit Mitte Dezember 2008 aber unter der GNU General Public Licence steht; auch die verwendete Version von Heartbeat ist eine sehr aktuelle.

Betrachtet man auf der anderen Seite die möglichen Virtualisierungstechnologien, wie z.B. XEN, KVM, VmWare Server oder VmWare ESXi so werden diese teilweise noch intensiv entwickelt, zum anderen sind in den letzten Monaten komplett neue Releases freigegeben worden oder wurden überhaupt erst dem nicht-kommerziellen Markt zur Verfügung gestellt.

In den nun folgenden Kapiteln möchte ich eine sowohl theoretische Abhandlung wie auch praktische Durchführung eines hoch verfügbaren Storage-Systems mit hoch verfügbaren virtuellen Systemen geben, unterschiedliche Ansätze für unterschiedliche Anforderungen diskutieren und ebenso Fallstricke und Probleme die während der Umsetzung aufgetreten sind erläutern.

Ziel meiner Arbeit soll nicht sein, eine möglichst breite Anleitung für möglichst viele Anforderungen zu werden, sondern viel mehr eine ganz spezielle Anleitung für eine konkrete Problemstellung - jedoch nicht auf den Verzicht von Skalierbarkeit des Systems; dies war immer schon in meinem Leben eine wichtige Rolle: Wenn ich etwas Neues geschaffen habe, dann musste es beliebig skalierbar sein - den aktuellen Stand der Technik natürlich vorausgesetzt.

2. Basistechnologien zur Realisierung hochverfügbarer virtueller Server-Systeme

Sucht man Lösungen für Problemstellungen so gibt es für mich immer zwei Möglichkeiten:

1. Die Bottom-Up-Varianten, also sich von unten nach oben zum Problem durcharbeiten
2. Die Top-Down-Varianten, sich vom Problem weg in die Tiefe zu arbeiten

Nachdem ich mich schon lange mit der Problemstellung auseinandergesetzt habe, dachte ich mir, ich könnte wiedereinmal ganz unten anfangen und die Variante 1 als Lösungsansatz wählen; jedoch musste ich inmitten der Tests und Experimente feststellen, dass ich am besten Weg dazu war, Anleitungen für möglichst viele Anforderungen zu finden, nicht jedoch für meine Problemstellung.

Mit dieser bitteren Erkenntnis habe ich dann kurzerhand alle bisherigen Tests und Experimente verworfen und mich nochmals der Basis-Theorie gewidmet. Diesmal - so hoffe ich - von der richtigen Seite: Top-Down.

Mein „Problem“ in einem Satz: Die Konzeption, Planung, Umsetzung und Implementierung eines hoch verfügbaren Computer-Cluster für virtuelle Maschinen.

Somit sind schon mal zwei Notwendigkeiten klar: Zum einen benötige ich ein Virtualisierungssystem, zum anderen einen Mechanismus, der mir die Hochverfügbarkeit überprüft und sicherstellt.

2.1. Virtualisierung & Hochverfügbarkeit

Überblick Virtualisierungs-Lösungen

Virtualisierungslösungen gibt es derzeit unterschiedlichste, von denen aus dem Bereich OpenSource und für meine Zwecke XEN, entwickelt von der Universität Cambridge, KVM, eine Kernel-based Virtual Machine, entwickelt vom israelischen Unternehmen Qumranet und im September 2008 von Red Hat gekauft oder die unterschiedlichen Container-Based Virtualisierungslösungen wie zum Beispiel bei Opensolaris.

Jede dieser unterschiedlichen Lösungen hat Vor- und Nachteile; zum einen überwiegen vielleicht die Vorteile, wie im Falle von KVM, jedoch ist diese Technologie noch zu jung für den Echt-Betrieb.

Einen detaillierten Überblick über die einzelnen Technologien im Bereich der Virtualisierung sowie konkrete Produkte dafür können Sie in der Arbeit „Virtuelle Maschinen - Migration“ von meinem Kollegen Ing. Clemens Auer finden (vgl. [AUE09] Kapitel 2.1, S 4ff).

Ein schönen Überblick über Container-Management zeigt mein Kollege Manuel Zach in seiner Bachelorarbeit „Container-Management am Beispiel von Opensolaris“ (vgl [ZAC09]).

Wie Sie sehen sind die Möglichkeiten bei den unterschiedlichen Virtualisierungslösungen sehr mannigfaltig; da wir jedoch schon seit Jahren XEN im Einsatz haben, muss ich derzeit weiter XEN einsetzen, solange z.B. KVM oder VMWare nicht die Möglichkeit bieten, XENImages zu übernehmen, was jedoch auf keinen Fall heißen soll, dass ich mit XEN unzufrieden bin. Ganz im Gegenteil! Seitdem wir XEN als Virtualisierungslösung einsetzen, haben wir noch keinen einzigen Absturz gehabt.

Da die in meiner Arbeit beschriebene Cluster-Lösung auch bald in den Echt-Betrieb gehen soll, habe ich mich ausschließlich mit XEN als Virtualisierungslösung auseinandergesetzt, jedoch wäre es relativ leicht möglich, andere Systeme ebenfalls an meinen Storage-Cluster anzubinden; weitere Möglichkeiten, sowie Performance-Unterschiede, werden Teilaspekte meiner 2. Bachelorarbeit sein.

Überblick über XEN

XEN ist ein von der Universität Cambridge entwickelter Virtual-Machine-Monitor. Darunter versteht man ein Monitoring-System, welches für die Ressourcenverwaltung der einzelnen virtuellen Maschinen zuständig ist. Der Virtual-Machine-Monitor verteilt die vorhandenen Hardware-Resourcen an die virtuellen Maschinen, sodass der komplette Hardwareumfang für jede einzelne Maschine zur Verfügung steht.

Dan Marinescu et.al. beschreiben in ihrer Arbeit „State of the art in autonomic computic and virtualiziation“ die Anforderungen an einen Virtual-Machine-Monitor: Equivalence, Control, Isolation, Performance und Encapsulation (vgl. [MAR07] Kapitel 2.2, S 3).

In Xen wird zwischen sogenannten privilegierten- und unprivilegierten G ä sten unterschieden. In jedem Xen System gibt es einen privilegierten Gast, dem sogenannten Dom0. Der Dom0 ü bernimmt das Management der anderen unprivilegierten Dom ä nen (DomU). Zu den Managementaufgaben z ä hlen unter anderem:

- Konfiguration der DomU
- Starten/Stoppen der DomU
- Migration der DomU auf andere Server

Weiters stellt der Dom0 s ä mtliche Hardware (z.B. Netzwerkkarten, RS 232, etc...) den Gastsystemen zur Verf ü gung. (vgl. [AUE09] S 18)

XEN bietet zwei Möglichkeiten zu virtualisieren: „Full Virtualization“ und „Paravirtualisierung“.

Full Virtualization

Die Full-Virtualization kann mit einer Art Emulation verglichen werden; es ist möglich, unveränderte Betriebssysteme in einer Virtuellen Maschine (VM) auszuführen. Im Gegensatz zur Emulation werden bei der Full-Virtualization nur Teile der Hardware simuliert; CPUBefehle können direkt auf der physikalischen Hardware ausgeführt werden. Aufgabe des Hypervisors, also des Virtual Maschine Monitor (VMM) ist es die Zugriffsberechtigungen zu verwalten sowie die Hardware für jede vorhandene VM zu simulieren. Um jedoch eine Full Virtualization verwenden zu können, wird eine gewisse Hardware vorausgesetzt: Die CPU muss entweder die Intel VT- oder die AMD-V-Technologie unterstützen. Genauere Details finden sie bei Ing. Clemens Auer [AUE09] Seite 4ff.

Paravirtualisierung

Der große Unterschied zur Full-Virtualization besteht darin, dass CPU-Befehle aus einer VM nicht direkt an die physikalische CPU weitergeleitet werden sondern es wird vom VMM ein modifiziertes Abbild der Hardware erzeugt; damit die VM Befehle ausführen kann, muss das Betriebssystem der VM modifiziert werden. Im Falle von OpenSource-Betriebssystemen wie Linux ist dies kein Problem, da diese Anforderungen standardmäßig unterstützt werden; jedoch im Falle von kommerziellen Betriebssystemen ist dies offiziell nicht möglich, da diese Änderungen im BS nicht vom Hersteller zur Verfügung gestellt werden. Eine tiefere Diskussion zu diesem Thema finden Sie auch bei Ing. Clemens Auer [AUE09] S. 5.

Hochverfügbarkeit

Hochverfügbarkeit oder wie es in der Fachwelt kurz mit HA (High Availability) abgekürzt wird befasst sich mit der Sicherstellung, dass gewisse Dienste permanent verfügbar sind und wenn ein Dienst - aus welchem Grund auch immer - nicht mehr erreichbar sein sollte, dafür zu sorgen, dass der Dienst eben irgendwie anders ausgeführt wird.

Auf meinen konkreten Bedarf abgebildet bedeutet dies, dass permanent überprüft werden muss, ob eine virtuelle Maschine noch am laufen ist bzw. ob der ganze Server, auf dem der VMM läuft noch einwandfrei funktioniert und wenn nicht, die VM auf einem anderen VMM zu starten.

Heartbeat

Genau diese Aufgaben übernimmt eine HA-Software, derer es natürlich jede Menge am Markt gibt. Eine der ältesten, geeignetsten, getesteten OpenSource-Lösungen ist Heartbeat aus dem HighAvailibility-Project.

Heartbeat - Herzschlag - dies ist genau, was die Software macht; in definierbaren periodischen Abständen werden die einzelnen Server eines Verbandes von den jeweiligen anderen Servern überprüft, ob sie noch am Leben sind. Wenn ja, also wenn es einen Heartbeat gibt, dann ist alles in Ordnung; wenn nicht, dann geht man davon aus, dass ein Server aus dem Verband „tot“ ist und muss demnach die Dienste übernehmen und auf den übrigen Servern zum Laufen bringen.

Heartbeat stellt für die Überprüfung diverse Möglichkeiten zur Verfügung: So kann neben der altbewährten seriellen Verbindung zweier Server auch die Überprüfung mittels Netzwerk stattfinden, und zwar mittels Unicast¹, Broadcast² und Multicast³. Die letzten 3 Begriffe stammen aus der Netzwerktechnologie und sind im wesentlichen 3 unterschiedliche Möglichkeiten, andere Netzwerk-Devices zu erreichen, abhängig von der jeweiligen Konfiguration des Netzwerkes; für unser konkretes Vorhaben haben die Unterschiede keine nennenswerte Bedeutung, weshalb ich auch nicht näher darauf eingehe.

Heartbeat gibt es derzeit in der Version 2.0 die sich von der Vorgängerversion durch 2 wesentliche Änderungen unterscheidet:

Zum einen die Möglichkeit den Cluster Ressource Manager - CRM zu verwenden, zum anderen, mehr als 2 Knotenpunkte im Cluster zu verwalten.

Zweiteres war für mich ausschlaggebend, da ich mein System beliebig skalieren möchte und deshalb verwende ich die Version 2.0 von Heartbeat mit dem CRM.

Mithilfe dieses CRM werden sogenannte Ressourcen definiert, die verschieden Dienste repräsentieren, wie z.B. eine virtuelle IP-Adresse. Standardmäßig ist diese virtuelle IPAdresse auf Server A verfügbar, wenn jedoch dieser Server nicht mehr erreichbar ist, also für die außen stehenden Server keinen Heartbeat mehr hat, muss die virtuelle IP-Adresse von einem anderen Server übernommen werden. Die diversen Default-Zustände, Abhängigkeiten, Reihenfolgen und diverse Zusatz-Logiken werden im XML-Konfigurationsfile definiert und der CRM steuert anhand dieser alle Aufgaben.

So wie es vorkonfigurierte Ressourcen für virtuelle IP-Adressen gibt, so gibt es noch jede Menge weitere nützliche Ressourcen, wie z.B. eine spezielle XEN-Ressource, die sich um den Start bzw. Stopp von VM kümmert und in weiterer Folge bei Bedarf auch diverse Migrationsaufgaben übernimmt.

Natürlich kann man sich selbst noch weitere Ressourcen bauen, dies ist aber in den meisten Fällen nicht notwendig; ich für meinen Teil komme fast ausschließlich mit den beiden oben besprochenen aus.

Quorum

Unter einem Quorum versteht man eine Komponente des Cluster Managers eines Computerclusters zur Wahrung der Datenintegrit ä t im Fall eines Teilausfalls. Bei Ausfall der Verbindung zwischen den Clusterknoten besteht das Risiko einer Aufspaltung des Gesamtsystems in unerw ü nschterweise autonom agierende Einheiten, die fast immer die Datenintegrit ä t bedroht. Durch wechselweises oder konkurrierendes Schreiben in die logische Struktur der Voting Disk wird im Falle eines unterbrochenen Interconnects entschieden, welcher Teil des Clusters ü berleben soll. Die Voting Disk liegt auf Shared Storage.

(vgl. http://de.wikipedia.org/wiki/Quorum_(Informatik ))

Entscheidungsfindung

Ein großes Problem im Bereich der Hochverfügbarkeit ist die Thematik der Entscheidungsfindung. Wenn ein Server im Verband nicht mehr erreichbar ist, so weiß man natürlich nicht, ober der Server irgendwelche Hardware-Probleme hat und deshalb nicht mehr reagiert oder ob er einfach nur überlastet ist.

Wenn der Verband aus mehr als 2 Servern besteht, so kann prinzipiell eine Mehrheit gefunden werden; z.B. kommen 2 weitere Server zu dem gemeinsamen Entschluss, dass Server A nicht mehr erreichbar ist.

Hat man aber insgesamt nur 2 Server in einem Verband, so glaubt jeder Server, dass der andere nicht mehr korrekt arbeitet und wird daher die Dienste des jeweils anderen übernehmen.

Wie auch immer die Entscheidung zustande kommt, eines ist wichtig: Der oder die Server, die der Meinung sind, dass ein Server nicht mehr funktioniert und aus diesem Grund dessen Dienste übernommen haben, müssen sich absolut sicher sein, dass der Server nicht doch irgendwann wieder zum Leben erweckt wird und auf einmal wieder weiterarbeitet, denn dann ergeben sich große Probleme.

Dies kann am simplen Beispiel der virtuellen IP-Adresse verdeutlicht werden: Wenn Server A nicht mehr reagiert, übernimmt Server B die virtuelle IP-Adresse; reagiert aber auf einmal Server A doch wieder, so ist ein und dieselbe IP-Adresse zwei mal im Netzwerk erreichbar, und dies ist keineswegs sinnvoll.

Stonith

Um daher das oben beschriebene Problem zu lösen und um absolut sicher zu sein, dass Server A nicht mehr am Leben ist werden sogenannte Stonith-Devices zum Einsatz gebracht.

Stonith steht „liebevoll“ für „shoot the other node into the head“; für unseren Fall heißt dies konkret, dass eine über Ethernet angeschlossene Steckdose abgeschaltet wird, sodass der Server A keinen Strom mehr hat und daher sicher nicht mehr weiterarbeiten kann.

Für den Fall, dass der Verband eine eindeutige Mehrheit finden kann, also zumindest aus 3 Teilnehmer besteht, ist klar, welcher Server abzuschalten ist.

Für den Fall, dass wir insgesamt nur 2 Server haben, muss es auf jeden Fall komplett unterschiedliche Kommunikationswege zwischen den beiden Servern geben, vorzugsweise eine serielle und eine Ethernet-Verbindung.

Dadurch kann gewährleistet werden, dass, wenn sich beide Server gegenseitig nicht mehr erreichen können, dass einer von beiden nicht funktionsfähig ist und daher der „richtige“ Server abgeschaltet wird.

Sobald ein abgeschalteter Server manuell oder auch automatisch neu gestartet wird und wieder voll einsatzfähig ist, werden die Dienste wieder von den temporären Server zum ursprünglichen Server zurück migriert.

2.2. IST-Zustand & Problemstellung

IST-Zustand

Derzeit haben wir zwei XEN-Server auf Basis Linux CentOS⁴ 5.2; als Hardware dienen uns Hewlett Packard HP ML 110 Server, die mit 6 bzw. 8 GB RAM ausgestattet sind und als Gast-Betriebssysteme laufen primär Linux CentOS-Betriebssysteme - sowohl als Paravirtualisierung wie auch als Vollvirtualisierung, jedoch auch Windows XP Professional ist im Einsatz.

Problemstellung

Nun geht es darum, dieses System ausfallsicher zu machen, d.h. wenn ein Teil eines Servers, z.B. eine Festplatte oder ein ganzer Server nicht mehr funktioniert bzw. einfach gewartet werden muss, sei es auf Seite der Hardware oder auf Seite der Software, so muss eben ein anderer Server die Funktionen übernehmen.

Daraus ergeben sich folgende Szenarien - alle folgenden Szenarien beziehen sich ausschließlich auf das Virtualisierungssystem sprich die Dom0 der XEN-Server; Fehler die in den einzelnen VM auftreten werden hier nicht behandelt, da man diese auf herkömmliche Art und Weise behandeln muss und in keiner Konstellation mithilfe eines ausfallsicheren Virtualisierungscluster gelöst werden können:

1. Wenn ein Server ausfällt, müssen die virtuellen Maschinen auf einem anderen Server gestartet werden können
2. Wenn ein Server aus Hardware-Gründen oder aus Software-Wartungsgründen heruntergefahren werden muss, muss eine Live-Migration aller virtuellen Maschinen auf den anderen Server durchgeführt werden.

Die Live Migration von XEN ist ein Feature, um virtuelle Maschinen von einer physikalischen Maschine auf eine andere zu migrieren, dies geschieht - aus User Sicht - unterbrechungsfrei. Dadurch ist es m ö glich, geplante Hardwarepflege zu betreiben, oder auch einen ü berlasteten Server zu entlasten und einen bestimmten Service auf eine neue Maschine zu verlagern. Andere Nutzungsm ö glichkeiten sind Test- und Entwicklungsumgebungen, Netzwerkund Cluster-Simulationen oder aus Sicherheitsgr ü nden separierte Ausf ü hrungsumgebungen (vgl. [JAU06] S 1).

3. In der aktuellen Konfiguration müssen sämtliche Probleme, die auftreten können

manuell erkannt werden und auch dementsprechend manuell gelöst werden. Probleme sind überwiegend im Bereich der Hardware zu finden, wie z.B. eine defekte Festplatte, aber auch jede andere defekte Hardware im Server. Neben Hardwareproblemen können auch Fehler in der Software auftreten, wie Fehler im Betriebssystem oder Sicherheitslücken die mit den diversen Updates und Patches behoben werden müssen.
4. Das aktuelle XEN-System, welches aus zwei unabhängigen XEN-Servern besteht ist sehr starr und kann in der derzeitigen Konfiguration nicht erweitert werden. Dies bedeutet, dass VM nicht von einem Server auf einen anderen migriert werden können, ohne eine lange Ausfallzeit; dies ist auch nur dann möglich, wenn beide XEN-Server einwandfrei funktionieren. Im Falle eines Hardware-Defekts eines XEN-Server müssen zuerst alle Probleme manuell beseitigt werden, bevor die einzelnen VM wieder gestartet werden können.

Nun geht es darum, die eben beschriebenen Probleme zu lösen; einer der wichtigsten Punkte hierfür ist alle Voraussetzungen zu schaffen, um eine ordentliche Live-Migration durchführen zu können. Sollte eine Live-Migration nicht mehr möglich sein, weil ein XEN-Server ausgefallen ist, sind die nun folgenden Punkte dennoch wichtige Voraussetzungen, um eine minimale Ausfallzeit garantieren zu können:

2.3. Voraussetzungen für eine Live-Migration

Es müssen einige Voraussetzungen erfüllt sein, damit eine Live-Migration möglich ist; diese beschreibt Jauslin Raphael in seiner Seminararbeit „XEN Live Migration“ (vgl. [JAU06], S 5):

1. Auf beiden XEN Hosts muss XEN installiert sein. Zus ä tzlich m ü ssen auf beiden Maschinen die ben ö tigten Ressourcen (Arbeitsspeicher) vorhanden sein.
2. Die XEN Hosts m ü ssen Zugriff auf das gleiche Dateisystem haben, Beispiele daf ü r sind NFS (Network File System), SAN (Storage Area Network) oder NAS (Network Attached Storage).
3. Beide XEN Hosts sollten im gleichen Subnet und zus ä tzlich mit dem Bridge Network Setup (kein privates Netzwerk innerhalb von XEN, sondern ö ffentliche Adresse) konfiguriert sein (IP und MAC Adresse werden ü bernommen).

Ressourcen / Speicher auf den XEN-Hosts

Eines der wichtigsten Dinge, die bei der Migration zu berücksichtigen sind, ist die Arbeitsspeicherverwaltung. Will man VM von einem Server auf einen anderen migrieren, so muss sicher gestellt sein, dass der nötige Arbeitsspeicher vorhanden ist.

Rein rechnerisch ergibt sich, je mehr Server man zur Verfügung hat, desto mehr Speicher kann pro Server genutzt werden.

Allgemein formuliert bedeutet dies, dass man im Idealfall in allen XEN-Servern überall den gleichen RAM hat und die Host-Betriebssysteme überall den selben RAM verwenden; XEN bietet hierfür die Möglichkeit, einen minimalen RAM-Platz für die Dom0 zu reservieren, dieser muss ebenfalls überall gleich konfiguriert sein, da es sonst wesentlich komplexer wird, den Überblick über alle System zu behalten und für den Problemfall auf der sicheren Seite zu sein.

RAM verfügbar pro Server abzüglich minimaler RAM für die Dom0 ist gleich theoretischer RAM für alle DomU's.

Da wir aber davon ausgehen müssen, dass ein XEN-Server ausfallen kann, so muss aus dem gesamten DomU-RAM-Platz immer ein Bereich reserviert bleiben, für DomU's von einem ausgefallenen Server.

Hat man N XEN-Server zur Verfügung, so ist der maximal nutzbare RAM für die „eigenen“ DomU's gleich N dividiert durch (N-1). Je mehr XEN-Server man hat, desto geringer wird das Verhältnis von Reserve-RAM zu verfügbaren RAM, jedoch geht dies nicht beliebig: es können natürlich immer nur ganze DomU's migriert werden, weshalb der kleinste Reserve- RAM zumindest so groß sein muss, wie die RAM-Größe einer durchschnittlichen DomU.

Deshalb sollten auch die Mehrheit der DomU's denselben RAM-Platz verwenden und in Ausnahmen immer ganze Vielfache der durchschnittlichen DomU, da sonst ein nicht verwendbarer RAM-Bereich übrig bleibt.

Wenn N die Anzahl an XEN-Servern ist, X der verfügbare RAM-Platz und Y der RAM- Speicherplatz der Dom0, so kann man für alle VM pro XEN-Server folgenden Speicher nutzen:

Z (Speicherplatz verwendbar) = (X-Y) * ((N-1) / N)

Wichtig ist zu berücksichtigen dass X - Z > durchschnittliche RAM-Größe einer DomU. Ein konkretes Anwendungsbeispiel samt Rechnung finden Sie im Kapitel 3.2.

Shared-Storage

Ein weiterer wichtiger Punkt ist das Vorhandensein eines gemeinsamen Festplatten-Speichers, dem sogenannten Shared-Storage. Für eine XEN-Live-Migration ist dies unbedingt erforderlich, aber auch im Falle eines Server-Ausfalls muss das XEN-Image, also die gesamten Daten, die ein Betriebssystem benötigt - zu vergleichen mit den Daten auf einer Festplatte in einem normalen PC - für den Failover-Server, das ist jener Server, der die VM des defekten Servers übernimmt, erreichbar sein.

Generell versteht man in der Informationstechnologie unter dem Begriff „Failover“ den ungeplanten Wechsel vom Haupt-Server zu einem Backup-Server.

Fällt das Stichwort „Shared Storage“ so kommen viele Schlagwörter ins Spiel, wie NAS (Network Attached Storage), SAN (Storage Area Network), NFS (Network File System), iSCSI (SCSI over Ethernet) und viele weitere.

Da wir uns mit XEN-Domains beschäftigen und die Daten innerhalb einer XEN-Domain in einem sogenannten XEN-Image gespeichert werden, so gibt es 2 Möglichkeiten, dieses Image zur Verfügung zu stellen.

1. Als (großes) File im Filesystem, z.B. /var/xenimages/windows_xp_01.img 2. Als Block-Device⁵, z.B. /dev/sda3 (also die 3. Partition auf der Festplatte) oder mit Hilfe des LVM (Logical Volume Manager) als Logisches Volume wie z.B. /dev/xenVG/windows_xp_01/

Für die Verwendung von Shared-Storage muss man zwischen fertigen Kauflösungen und selbst gebastelten Lösungen mithilfe von OpenSource-Software unterscheiden. Im weiteren werde ich mich ausschließlich auf die Möglichkeiten von OpenSource-Software beziehen.

Möglichkeiten, Shared-Storage anzusprechen gibt es viele, von denen für meine Verwendung unter anderem NFS, AoE, iSCSI, FCoE, NBD, GNBD und GFS auf GNBD geeignet sind.

Mein Kollege Roman Küstner hat in seiner Bachelorarbeit die diversen Möglichkeiten zur Anbindung an Shared-Storage-Devices untersucht. (vgl. [KÜS09])

Aufgrund seiner Expertise und auch etlichen Übereinstimmungen mit meinen eigenen Testergebnissen in diesem Bereich habe ich mich dazu entschlossen, für meine Arbeit iSCSI zu verwenden.

iSCSI - internet Small Computer System Interface

iSCSI (internet Small Computer System Interface) ist ein Storage-over-TCP-Verfahren f ü r Speichernetzwerke. Unterschieden wird das iSCSI-Target (der Server, der die Daten bereit stellt) und der iSCSI-Initiator, der auf einem System die Verbindung zu den Daten auf dem Target herstellt.

Nachteil der iSCSI-Technologie ist eine erh ö hte CPU-Belastung der Server und mehr Interrupts pro Datenmenge f ü r den Server. Es sind aber bereits Hardwarel ö sungen wie z. B. TCP/IP Offload Engine-Karten oder auch I/OAT verf ü gbar, die das TCP/IP Overhead-Problem der CPU vermindern. Der Nachteil einer geringeren Grundgeschwindigkeit (iSCSI mit 1 Gbit/s im Vergleich zu Fibre Channel mit 8 Gbit/s) ist mit der Einf ü hrung von 10 Gigabit/s Ethernet und den damit erreichbaren Durchs ä tzen von mehr als 800 MByte/s nicht mehr gegeben.

(vgl. http://de.wikipedia.org/wiki/ISCSI )

Der Vorteil von iSCSI gegenüber AoE oder FCIP besteht darin, dass es den serverseitigen Dienst, den iSCSI-Target schon länger gibt und man sich in produktiven Systemen eher drauf verlassen kann und zum anderen viele Systeme das iSCSI-Protokoll unterstützen, wie z.B. auch alle Virtualisierungsprodukte der Firma VMWare, aber auch im simplen Microsoft Windows ist es möglich auf iSCSI-Targets zuzugreifen.

Cluster-File-System

Um eine VM auf einem XEN-Server starten zu können, benötigt man neben einem XENImage - sei es File-basierend oder Block-basierend - eine Konfigurationsdatei.

Auf einem Stand-alone-XEN-Server befindet sich diese Konfigurationsdatei normalerweise im Verzeichnis „/etc/xen/“. Da wir aber Live-Migrationen durchführen wollen, bzw. nach einem Server-Crash die VM auf einem anderen XEN-Server neu starten wollen, sollten immer die gleichen Konfigurationsdateien auf allen XEN-Servern verfügbar sein.

Die Live-Migration bildet in diesem Fall ein wenig die Ausnahme, da während dem Vorgang der Live-Migration die Inhalte der Konfigurationsdatei mit übertragen werden, jedoch nicht die Datei selbst. Somit hätte man spätestens nach einem Absturz auf dem neuen Server das Problem, dass XEN nicht weiß, mit welchen Parametern die VM zu starten ist.

Um die Sicherheit zu haben, dass immer alle Konfigurationsdateien von allen XEN-Servern im Zugriff sind, ist es notwendig ein Cluster-File-System zu verwenden.

Cluster-File-Systeme haben den Vorteil, dass ein Filesystem auf unterschiedlichen Servern im Lese- und Schreibzugriff sein kann.

Ich verwende das GFS - Global File System - auf Basis von GNBD - Global Network Block Device.

GNBD - Global Network Block Device

Global Network Block Device ist mit anderen Network-Block-Device-Treibern vergleichbar.

Das Exportieren von Block Devices oder Verzeichnissen (z. B. Network File System, NFS) ist vergleichbar mit dem Freigeben von Verzeichnissen und Laufwerken unter Windows. Exportierte Block Devices k ö nnen dann auf einem anderen System importiert und gemountet (eingebunden) werden.

(vgl. http://de.wikipedia.org/wiki/Global_File_System )

Da XEN die Möglichkeit bietet, direkt in Block-Devices seine VM zu speichern, könnte man auch GNBD anstelle von iSCSI nutzen und direkt unter einem GNBD-Export seine VM verwalten. Ich habe mich auch mit dieser Möglichkeit in meinen Praxis-Tests auseinandergesetzt. Die Stabilität war gut, jedoch die Performance mit iSCSI nicht vergleichbar, weshalb ich mich dann doch entschlossen habe, iSCSI zu bevorzugen. Weiters ist im Falle von GNBD zu beachten, dass die Konfiguration wesentlich komplexer ist, als bei iSCSI.

GFS - Global File System

Das Global File System (GFS) ist ein Cluster-Dateisystem, das es Rechnern erm ö glicht, gleichzeitig auf das Dateisystem eines Storage Area Network zuzugreifen und zugleich die Konsistenz der enthaltenen Daten gew ä hrleistet. Das Datei-Locking, ohne das ein Cluster-Dateisystem nicht funktionieren w ü rde, ü bernimmt ein Locking- Modul von GFS.

Exportiert werden die lokalen Blockdevices meist ü ber GNBD (Global Network Block Device).

(vgl. http://de.wikipedia.org/wiki/Global_File_System )

Verwendet man XEN in Kombination mit Migration und File-basierten Images, so ist es ebenso möglich, diese in einem GFS abzulegen; dies bringt einige Vorteile mit sich, da man ein großes GFS erzeugen kann, und dort beliebig große Image-Files ablegen kann und natürlich auch die Image-Files jederzeit verkleinern und vergrößern kann.

Der wirklich große Nachteil von GFS in Kombination mit XEN-Images liegt im Bereich der Performance. Es ist schon ein extremer Performance-Unterschied zwischen GFS und GNBD zu bemerken. Die Differenz zwischen GFS und iSCSI ist überhaupt ganz extrem.

Dazu kommt noch der Aspekt des Sperrens von Dateien: Schreibt man z.B. in einer VM ein 1 GB großes File, so muss dieses natürlich auch in der XEN-Image-Datei geschrieben werden; während des Schreibvorganges konnte ich bei meinen Tests z.B. kein VerzeichnisListing des XEN-Image-Ordners machen, da diese Aktion so lange gesperrt war, solange die Schreibvorgänge noch nicht beendet waren.

Hoch verfügbares Shared Storage - Failover

Nun haben wir theoretisch die Aufgabenstellung der ausfallsicheren XEN-Hosts beschrieben, jedoch wie sieht das ganze mit dem Shared-Storage aus?

Auch beim Shared Storage muss man davon ausgehen, dass Hardware und / oder Software defekt werden kann. Bei Kauflösungen, wie fertigen Shared-Storage-Devices ist dies relativ einfach, denn diese sind meistens fast vollständig redundant ausgeführt. Dies bedeutet, dass der Festplatteninhalt auf andere Festplatten gespiegelt wird, Lüfter, Netzteile, Netzwerkkarten oder Festplatten-Controller ebenfalls alle redundant vorhanden sind und somit eigentlich fast nichts passieren kann. Und für den Fall der Fälle hat man zu dem Device sicher einen Top- Wartungsvertrag dazu gekauft, der einem möglicherweise eine Behebung des Problems innerhalb weniger Stunden garantiert. Beispiele hierfür sind NetApp (http://www.netapp.com/ de/) aber auch die großen Computerfirmen wie IBM, HP oder DELL haben eigene Produkte am Markt.

Wenn man nicht das nötige Kleingeld hat oder einfach nicht bereit ist, dieses auszugeben, dann muss man sich nach Alternativen umschauen.

Der einfachste Ansatz, einen Storage-Server ausfallsicher zu machen, ist einen zweiten identischen Storage-Server zu haben; nun müssen nur mehr die Daten zwischen den beiden Servern synchron gehalten werden.

Festplatten zwischen den Storage-Servern synchron halten

DRBD - das Distributet Replicated Block Device ist in diesem Kapitel unser magisches Wort.

Die Idee von DRBD ist es, die Daten redundant in jedem Knoten des Clusters abzulegen und alle Ver ä nderungen der Daten an alle Mitglieder des Clusters ü ber ein normales IP basiertes Netzwerk zu ü bertragen. (vgl. [REI00] S 17)

Dipl.-Ing. Philipp Reisner ist Entwickler der Clusterlösung DRBD und beschreibt in seiner Diplomarbeit die genaue Funktionsweise von DRBD (vgl. [REI00] S 17).

Abbildung 1 veranschaulicht die Arbeitsweise von DRBD:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Funktionsweise von DRBD

Für unsere Zwecke ist es wichtig zu wissen, dass DRBD uns die Möglichkeit bietet, jedes beliebige Block-Device, sei es eine ganze Festplatte, eine Partition auf einer Festplatte oder einfach nur ein LV via TCP/IP auf einen anderen Server zu spiegeln.

DRBD bildet somit eine Zwischenschicht zwischen physikalischem Speicher und dem

Filesystem; jedes mal wenn ein Datenblock geschrieben werden soll, wird dieser sowohl lokal auf das physische Volume geschrieben wie auch per Netzwerk zum 2. Storage-Server gesendet und dort ebenfalls auf das physikalische Volume geschrieben.

Je nach Einstellungen in der DRBD-Konfiguration wird im sichersten Modus dem Filesystem erst ein positiver Rückgabewert gemeldet, wenn beide Server die Daten tatsächlich auf die jeweiligen physikalischen Volumes geschrieben haben.

DRBD im Detail

Während meiner Test- und Implementierungsphase im November und Dezember 2008 war gerade die Version 8.2.x von DRBD aktuell; und diese unterstützte nur ein Modell mit insgesamt 2 Servern. Seit Mitte Dezember ist jedoch die Version 8.3 von DRBD erschienen und diese gibt auch den nicht-kommerziellen Nutzern von DRBD die Möglichkeit, den Storage-Cluster um einen 3. Server zu erweitern.

Da ich weder die Hardware für einen 3. Storage-Server zur Verfügung hatte und es außerdem schwerwiegende Änderungen im gesamten Ansatz des Systems bedingt durch einen 3. Storage-Server gegeben hätte, beziehe ich mich in allen weiteren Kapitel ausschließlich auf die Zwei-Server-Storage-Lösung.

Das Kapitel 6. meiner Arbeit beschäftigt sich mit einem Ausblick auf die 2. Bachelorarbeit, wo unter anderem Vor- und Nachteile sowie die Erweiterung auf einen 3. Storage-Server geplant sind.

Konzentrieren wir uns nun auf die beiden Storage-Server; DRBD bietet die Möglichkeit für 2 unterschiedliche Betriebsarten:

1. Primary-Secondary - Modus
2. Primary-Primary oder Dual-Primary- Modus

Unterschied Primary-Secondary zu Dual-Primary

Für eine XEN-Live-Migration ist es eine der Voraussetzungen, dass beide XEN-Server Lese- und Schreib-Zugriff auf das Storage haben. Verwendet man einen der beiden Storage-Server als Backup, so kann man ohne Probleme DRDB im Modus 1 - Primary-Secondary - Modus verwenden; auf dem Primary-Storage-Server kann geschrieben werden, auf dem Secondary nicht; sollte der Primary-Storage-Server ausfallen, werden die Rollen zwischen den DRBD- Server getauscht und der Secondary wird zum Primary gemacht und umgekehrt.

Will man aber die Last der Storage-Zugriffe auf beide Storage-Server verteilen, so muss man DRBD im Dual-Primary-Mode konfigurieren; in diesem Fall ist zu beachten, dass auf dem DRBD entweder ein Block-Device liegt, welches direkt von der VM verwendet wird oder ein Cluster-File-System wie das oben beschriebene GFS. Alle nicht Cluster-File-Systeme sind nicht dafür ausgelegt, dass Daten auf zwei oder mehrere Server gleichzeitig verändert werden können.

Für meine Aufgabenstellung empfiehlt sich der Dual-Primary-Modus, da ich sowieso nur mit Block-Devices unter XEN arbeite und die XEN-Konfigurationsdateien innerhalb eines GFS liegen. Somit kann ich zusätzlich den Vorteil der Lastverteilung auf beide Stoarge-Server nutzen.

Überlegungen zum Netzwerk zwischen den einzelnen Servern

Damit eine DomU von einem XEN-Server zu einem anderen XEN-Server migriert werden kann, müssen sich beide XEN-Hosts im selben Subnetz befinden, da ja die Dom-U die gleiche IP-Adresse (und MAC-Adresse) behalten soll.

Wenn die XEN-Server virtuelle Maschinen für das Internet zur Verfügung stellen, muss jeder XEN-Server eine offizielle IP-Adresse pro IP-Address-Bereich haben.

Aus Sicherheitsgründen ist es sinnvoll, zwischen den XEN-Server und den Storage-Server ein eigenes privates Netzwerk zu verwenden. Diese Kapselung hat aber nicht nur Sicherheitsvorteile sondern auch Performance-Vorteile, da über dieses eigene Storage- Netzwerk fast ausschließlich nur Storage-Traffic fließt und somit die gesamte Übertragungsrate genutzt werden kann. Empfehlenswert ist natürlich ein Gigabit-Netzwerk oder besser.

Zwischen den beiden Storage-Servern sollte auf jeden Fall ein weiteres eigenes privates Netzwerk vorhanden sein, am besten beide Storage-Server sind direkt mit einem ausgekreuzten Netzwerkkabel verbunden. Auch hier sollte die Geschwindigkeit mindestens im Megabit-Bereich liegen.

Um die Fehlertoleranz noch weiter zu erhöhen, sollten auf jeden Fall folgende Punkte berücksichtigt werden:

Der Switch, der das Netzwerk zwischen XEN-Server & Storage-Server verbindet ist derzeit ein sogenannter Single-Point-of-Failure (SPOF), also eine einzelne Fehlerstelle, die bei einem Defekt den Ausfall des gesamten Systems nach sich ziehen kann. Es sollte auf jeden Fall die Überlegung angestellt werden, diesen redundant auszuführen oder zumindest einen baugleichen immer verfügbar zu haben; denn wenn dieser Switch ausfällt, steht das gesamte System und keine einzige VM kann mehr weiterarbeiten.

Split-Brain⁶

Ein weiterer SPOF ist die Verbindung der beiden Storage-Server untereinander, sprich jene Verbindung, die DRBD für den Datenaustausch nutzt.

Um dies zu vermeiden sollte diese Netzwerkverbindung auf jeden Fall redundant ausgelegt werden. Diese Probleme könnten mit je 2 Netzwerkkarten pro Storage-Server und dem Bonding, einem Kombinieren von beiden Netzwerkkarten zu einer virtuellen Netzwerkkarte verhindert werden. Zugleich erhöht sich natürlich im fehlerfreien Fall die Übertragungsrate auf insgesamt 2 Gigabit.

Wenn DRBD im Dual-Primary-Modus verwendet wird und die DRDB-Verbindung zwischen beiden Storage-Server nicht mehr besteht, ist es trotzdem weiterhin möglich, dass die einzelnen XEN-Server Daten auf die Storage-Server schreiben; je nach Konfiguration kann es aus Lastverteilungsgründen sinnvoll sein, XEN-Server A auf den Storage-Server A zugreifen zu lassen und XEN-Server B auf den Storage-Server B. Alles funktioniert bestens, nur nicht die Synchronisation zwischen den beiden DRBD-Servern; aber gerade dies kann fatale Auswirkungen haben!

Man spricht dann von Split-Brain, also „geteilten Gehirnen“, weil Storage-Server A etwas weiß, was Storage-Server B nicht weiß und umgekehrt; und diese Probleme lassen sich im Dual-Primary-Modus eigentlich nicht sinnvoll auflösen.

Deshalb ist diese Netzwerkverbindung unbedingt redundant auszuführen und ebenso in die Überwachung von Heartbeat einzubauen. Eine simple Lösung im Fall, dass Heartbeat feststellt, dass die Verbindung unterbrochen wurde, ist mittels STONITH einen der beiden Storage-Server auszuschalten. Im Prinzip ganz egal welchen, es ist nur wichtig, dass nur mehr ein Storage-Server verfügbar ist, damit kein Split-Brain entstehen kann.

Nach der Behebung der Netzwerkprobleme kann der abgeschaltete Storage-Server wieder gestartet werden und dieser synchronisiert sich dann mit dem anderen Storage-Server, wie wenn ein ganz „normaler“ Server-Crash passiert wäre und das System läuft wieder einwandfrei und redundant.

Kombination von Storage-Server & XEN-Server

Zum Abschluss dieser Übersicht über die Basistechnologien sei noch erwähnt, dass es nicht notwendig ist, Storage-Server und XEN-Server auf unterschiedliche Server auszulagern; sofern man mit 2 XEN-Servern das Auslangen findet, kann man das gleich ebenso hoch verfügbare System mit nur 2 Server implementieren.

Als Basistechnologien benötigt man in diesem Fall ebenso XEN und DRBD, jedoch „erspart“ man sich die komplette Konfiguration der Storage-Anbindung, sei es mit iSCSI, GNBD oder GFS.

Da DRBD ein virtuelles Block-Device zur Verfügung stellt und XEN-VMs direkt auf BlockDevice-Ebene zugreifen können, reicht eine DRBD-Konfiguration im Dual-Primary-Mode und schon können die VM erstellt, gestartet und natürlich auch live-migriert werden.

Diese Variante kann theoretisch auch jederzeit erweitert werden, indem man die StorageFunktionalität belässt und die XEN-Funktion auf eigene XEN-Server auslagert.

Dass dies problemlos möglich ist, kann ich aus eigener Erfahrung bestätigen, da ich bei meinen praktischen Übungen genau so vorgegangen bin: Zuerst nur 2 Server mit DRBD und XEN und dann die XEN-Funktion auf eigene Server auslagern.

[...]

---

¹ http://de.wikipedia.org/wiki/Unicast

² http://de.wikipedia.org/wiki/Broadcast

³ http://de.wikipedia.org/wiki/Multicast

⁴ Community ENTerprise Operating System - CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor. CentOS conforms fully with the upstream vendors redistribution policy and aims to be 100% binary compatible. (CentOS mainly changes packages to remove upstream vendor branding and artwork.) CentOS is free. (vgl. [CEN09])

⁵ Block Device ist ein Storage Device, dass Lese- und Schreibvorgänge in fixen Blockgrößen unterstützt; Festplatten z.B. werden unter Linux immer als Block-Device angesprochen.

⁶ Der Begriff „Split-Brain“ - zu Deutsch: geteiltes Gehirn - kommt eigentlich aus der Medizin, genauer gesagt aus dem Bereich der Hirnforschung und wird dort als letztes Mittel zur Behandlung von Epilepsie eingesetzt.