Home 
ORDIX News 2/2007 Open/Source
ORDIX News 2/2007 Open/Source
ORDIX News 2/2007 Open/Source
mit dem Thema Virtualisierung auseinandersetzen möchten.
| Wirt Physikalisches System auf dem der XEN Kernel läuft und von dem die Gäste gesteuert und kontrolliert werden. |
| Gast Virtuelles System, das auf derselben Hardware wie der Wirt läuft. |
| MAC-Adresse Physikalische Adresse einer Netzwerkkarte, die für die Kommunikation genutzt wird. |
| OpenSolaris Von einer Community fortgesetzte Weiterentwicklung von Solaris mit neuen Funktionalitäten, die von Sun geprüft und in das offizielle Solaris implementiert werden. |
| Block Device Ein Block Device ist eine spezielle Datei (Gerätedatei), mit deren Hilfe auf die Hardware, z. B. Festplatte zugegriffen wird. Ein Block Device im Netzwerk lässt sich wie ein lokales Gerät nutzen. |
Ein Gastsystem innerhalb eines XEN-Servers stellt in der Regel kein Stand-Alone-System dar. Die Kommunikation über das Netzwerk ist eine wesentliche Voraussetzung für einen sinnvollen Einsatz der virtuellen Maschine. Hierfür stellt XEN virtuelle Netzwerkkarten zur Verfügung, welche auf verschiedene Arten genutzt werden können. Jede Netzwerkkarte bekommt eine eigene MAC-Adresse, die entweder automatisch vergeben oder fest zugewiesen werden kann. Insgesamt können einem Gast in der aktuellen XEN-Version 3.0.3 bis zu drei Netzwerkschnittstellen zugewiesen werden. Dabei stehen drei verschiedene Möglichkeiten der Nutzung zur Verfügung:
Beim Bridging bzw. Switching werden die Netzwerkkarten der Gäste und das physikalische Interface des Wirtes mit einer virtuellen Bridge verbunden. Jeder Gast bekommt eine IP-Adresse aus dem Subnetzbereich des Firmennetzwerkes und ist direkt von außen ansprechbar (siehe Abbildung 1).
 |
| Abb. 1: Bridging bzw. Switching mit XEN. |
Als Alternative zum Bridging kann auch ein Routing (siehe Abbildung 2) eingerichtet werden. Beim Routing befinden sich Gast und Wirt in einem gemeinsamen, virtuellen Subnetz. Das Wirtsystem fungiert dabei als Router zwischen den Gastsystemen und der Außenwelt.
 |
| Abb. 2: Routing mit XEN. |
NAT wird in Verbindung mit dem Routing eingesetzt. Mit NAT werden die Gäste komplett hinter der IP-Adresse des Wirtes versteckt. Auf dem Wirt findet dabei eine IP-Adressumwandlung statt, wobei in jedem Paket die Adresse des Gastes durch die des Wirtes ersetzt wird. Für die Rechner im Unternehmensnetzwerk stellt es sich so dar, als ob alle Pakete vom Wirtrechner kommen.
Wie die meisten XEN-basierten Einstellungen, werden auch die Netzwerkeinstellungen in der Datei /etc/xen/xend-config.sxp durchgeführt. Hier ist der richtige Ort, um Änderungen an der Netzwerkkonfiguration durchzuführen. Insgesamt ist die Datei sehr gut dokumentiert und mit Beispielen versehen. Der Verwendungszweck der Einträge ist recht schnell ersichtlich. In der mitgelieferten Konfiguration wird standardmäßig eine Bridge mit Namen xenbr0 über die Einträge (network-script network-bridge) und (vif-script vif-bridge) konfiguriert. Die Einträge werden immer in runden Klammern in der Form (Schlüsselwort Wert) angegeben.
Abbildung 3 zeigt für jeden Netzwerktyp die Einstellungen. network-bridge und vif-bridge sind Shell-Skripte, welche sich im Verzeichnis /etc/xen/scripts befinden und individuell angepasst werden können. Das Skript network-bridge erstellt die Bridge xenbr0 und verbindet das physikalische Interface des Wirts damit, vif-bridge verbindet die Gäste mit der Bridge.
# Einträge für eine Bridge (network-script network-bridge) (vif-script vif-bridge) # Einträge für das Routing (network-script network-route) (vif-script vif-route) # Einträge für das NAT (network-script network-nat) (vif-script vif-nat) |
| Abb. 3: Auszug aus der Datei /etc/xen/xend-config.sxp. |
Mit der Bridging-Konfiguration ist es möglich, eine benutzerdefinierte Bridge zu erstellen, die für XEN-Gäste genutzt werden kann. Auch ohne XEN kann eine Bridge auf dem Wirt als virtuelle Netzwerkschnittstelle genutzt werden. Für die Konfiguration wird das Paket bridge-utils benötigt, welches mit dem Betriebssystem mitgeliefert wird und für XEN zwingend Voraussetzung ist: Mit dem Kommando brctl haben Sie die Möglichkeit, eine Bridge für XEN-Gäste einzurichten bzw. generell eine virtuelle Netzwerkschnittstelle zu erstellen. Anhand eines dokumentierten Beispiels (siehe Abbildung 4) möchten wir aufzeigen, wie eine Bridge erstellt und mit einer Netzwerkkarte auf Wirt- und Gastseite verbunden wird.
# Bridge mit Namen mybridge erstellen brctl addbr mybridge # Bridge mit phys. Interface eth1 verbinden brctl addif mybridge eth1 # Der Bridge kann auch eine IP zugewiesen werden ifconfig mybridge 192.168.1.2 |
| Abb. 4: Konfiguration einer eigenen Bridge und Bindung an eine Netzwerkkarte. |
Wie Abbildung 4 zeigt, lässt sich mit wenigen Befehlen eine Bridge erstellen und mit einer Netzwerkkarte verbinden. Genauso einfach wird auch ein Gast mit der Bridge "verheiratet". Dazu muss in der Konfigurationsdatei des Gastes der Eintrag der Netzwerkkarte abgeändert werden. Angenommen, /etc/xen/suse1.cfg sei unsere Konfigurationsdatei, muss innerhalb der Netzwerkeinstellungen die Bridge mit angeben werden, z. B. vif = ['AA:BB:CC:DD:EE:FF, bridge=mybridge']
Eine für hochverfügbare Umgebungen ausgelegte Funktion ist die Live-Migration von einem XEN-Wirt auf einen anderen. Hierbei wird der Gast während des laufenden Betriebes von einem Wirt auf den anderen übertragen. IP-Adresse, MAC-Adresse und RAM bleiben die ganze Zeit über nutzbar. Technisch gesehen wird erstmals der komplette vom Gast genutzte Arbeitsspeicherinhalt auf den 2. Wirt übertragen. In weiteren Durchgängen wird dann immer wieder der geänderte Teil des Arbeitsspeichers übertragen, bis dieser so klein ist, dass der Gast kurz angehalten werden kann, das letzte Delta übertragen und der Gast auf dem 2. Wirt wieder fortgesetzt werden kann.
In der Praxis entsteht bei der Live-Migration eine kleine Pause im Millisekundenbereich. Der Anwender, der den Gast gerade nutzt, bekommt nur ein kurzes "Ruckeln" zu sehen, seine Arbeit wird dadurch aber nicht beeinträchtigt. Es gibt aber einige Voraussetzungen, die für eine erfolgreiche Migration erfüllt sein müssen.
Das Gastsystem muss vor und nach der Migration auf sein Dateisystem zugreifen können. Damit auf beiden Servern identische Daten zur Verfügung stehen, muss sich das Gastbetriebssystem auf einem gemeinsam genutzten Netzwerkspeicher oder Netzwerkdateisystem befinden. Als gemeinsames Medium kommen hier z. B. SAN, NAS, iSCSI, Infiniband oder NFS (siehe Abbildung 5) in Frage. Für das Clustering würde sich als Dateisystem GFS oder OCFS2 anbieten. Möchte man die XEN-Gäste hochverfügbar auslegen, benötigt man noch einen Dienst, der für das Umschalten bei Ausfall eines Knotens sorgt. Hierfür bietet sich die Open Source Lösung Heartbeat an. Als gemeinsamer Datenspeicher kann DRBD verwendet werden.
 |
| Abb. 5: Gemeinsamer Speicher bei zwei XEN-Servern. |
Bei einer Migration muss XEN den vom Gast genutzten Arbeitsspeicherinhalt von einem Wirt auf den anderen übertragen. Der Dateisysteminhalt bleibt dabei unberührt. Das ist auch der Grund für den gemeinsam genutzten Datenspeicher. XEN unterscheidet hierbei Migration und Live-Migration. Nur die Live-Migration ermöglicht das kontinuierliche Weiterarbeiten mit dem Gast.
Eine normale Migration führt im Gegensatz zu einer Live-Migration zwar zu einer Unterbrechung bei der Ausführung, aber zum selben Ergebnis. Diese normale Migration könnte auch manuell durchgeführt werden: xm save suse1 /tmp/save würde den Gast suse1 pausieren und den Arbeitsspeicherinhalt in die Datei /tmp/save schreiben. Nun müsste /tmp/save auf die Zielmaschine kopiert werden und dort mit dem Befehl xm restore /tmp/save wiederhergestellt werden. Bei der Migration werden IP-Adresse, MAC-Adresse und die aktuelle Gastkonfiguration mit übertragen.
Um einen XEN-Server für den Empfang von Gästen vorzubereiten, müssen in der XEN-Konfigurationsdatei des Empfangsservers /etc/xen/xend-config.sxp (siehe Abbildung 6) einige Einträge vorgenommen werden. Mit (xend-relocation-port '8002') kann der Port, über den kommuniziert wird, festgelegt werden. Mit (xend-relocation-address '192.168.1.2') wird der Zugriff über eine bestimmte Netzwerkkarte zugelassen. Der Quellserver, von dem die Übertragung zugelassen wird, kann mit (xend-relocation-hosts-allow '192.168.1.1') angegeben werden.
(xend-relocation-port '8002') (xend-relocation-address '192.168.1.2') (xend-relocation-hosts-allow '192.168.1.1') |
| Abb. 6: Konfiguration des XEN-Wirtes für den Empfang von XEN-Gästen. |
Wichtig ist, dass XEN die Änderungen mit /etc/init.d/xend restart mitgeteilt werden. Jetzt kann auf dem Quellserver mit xm migrate suse1 192.168.1.2 bzw. mit xm migrate –live suse1 192.168.1.2 das suse1-Gastsystem mit oder ohne Unterbrechung auf den Zielserver migriert werden.
Während einer Migration sollen drei wichtige Punkte erfüllt sein:
Der aktive Gast läuft auf dem XEN-Wirt 1. Jetzt wird eine Verbindung zu XEN-Wirt 2 aufgebaut, der für den Empfang des Gastes bereit ist und die nötigen Ressourcen (RAM, CPU, etc.) verfügbar hat.
XEN-Wirt 1 sendet eine Anfrage an XEN-Wirt 2, mit der die notwendigen Ressourcen auf XEN-Wirt 2 überprüft werden. Anschließend wird ein Container reserviert, welcher dem Container des Gastes auf XEN-Wirt 1 entspricht.
In der ersten Iteration werden alle Arbeitsspeicherseiten (Pages) übertragen. Anschließend werden nur noch die übertragen, die sich seit der letzen Iteration verändert haben.
Der Gast auf XEN-Wirt 1 wird gestoppt und der Netzwerkverkehr auf XEN-Wirt 2 umgelenkt. Danach wird der CPU-Zustand sowie der übrig gebliebene, geänderte Arbeitsspeicherinhalt übertragen. Nach Ausführung dieses Schrittes sind auf XEN-Wirt 1 und 2 zwei identische virtuelle Maschinen, XEN-Wirt 1 ist aber immer noch der aktive Server.
XEN-Wirt 2 bestätigt, dass er einen identischen Gast besitzt. Somit kann XEN-Wirt 1 seinen Gast beenden und XEN-Wirt 2 wird aktiver Server.
Der Gast auf XEN-Wirt 2 ist aktiv.
Dieser Ablauf garantiert, dass immer nur ein Server aktiv ist und einen voll funktionsfähigen Gast besitzt. Bei möglichen Fehlern können so keine Daten verloren gehen.
In der ORDIX News 1/2007 haben wir berichtet, wie ein Linux Betriebssystem als XEN-Gast installiert und konfiguriert werden kann. Im Prinzip gibt es drei Möglichkeiten:
XEN für OpenSolaris, welches aktuell nur für die Intel-Architektur verfügbar ist, kann sowohl als Wirt als auch als Gast konfiguriert werden. Die aktuelle Planung von SUN lässt erwarten, dass XEN Mitte des Jahres 2007 im offiziellen Solaris in beiden Architekturen enthalten sein wird. Wir möchten Ihnen aufzeigen, wie man OpenSolaris unter einem Linux XEN-Wirt als Gast ins Rennen schickt.
Da man OpenSolaris nicht einfach ad hoc unter Linux installieren kann, muss hier ein anderer Weg zur Installation eines Gastes gewählt werden. Eine Möglichkeit wäre, den Gast wie bei Linux mit Unix-Mitteln auf Datei- oder Sektorebene zu klonen. Das hätte aber den großen Nachteil, dass nachträglich sehr viele manuelle Anpassungen durchgeführt werden müssten. Dies betrifft vor allem den Kernel mit den dazugehörigen Modulen.
Für OpenSolaris ist ein anderer Weg zu einem lauffähigen System vorgesehen, bei dem alle notwendigen Maßnahmen automatisch durchgeführt werden. Am besten man installiert OpenSolaris erst einmal auf ganz normalem Weg auf einem Alternativsystem. Die XEN-Pakete für OpenSolaris sind momentan noch nicht auf den Installations-CDs enthalten und müssen separat heruntergeladen [1] und von Hand installiert werden. Die OpenSolaris XEN-Pakete müssen immer installiert werden - vollkommen unabhängig von der Nutzung als Wirt oder als Gast.
Die Pakete müssen auf das OpenSolaris System übertragen werden. Dort angekommen, werden die Pakete mit dem Befehl bunzip2 entkomprimiert und mit dem Befehl pkgadd –d Paketname installiert.
Nun sind alle Vorbereitungen getroffen, um den XEN-Gast für eine Migration vorzubereiten. Die XEN-Pakete für OpenSolaris werden vor allem wegen des Werkzeugs vbdcfg benötigt, welches einen Prototyp eines OpenSolaris Betriebssystems erstellt. Der Ablauf beim Erstellen eines Gastes teilt sich in drei Teile auf (siehe Abbildung 7):
# Erstellung des Flash-Archivs nach /backup/system.flar # des gesamten Betriebssystems # /backup/system.flar selbst wird aber Excluded flar create –n XENflarimage –x /backup/system.flar /backup/system.flar # Erstellung eines Prototype Images aus dem Flash-Archiv vbdcfg mkproto –f –a /backup/system.flar XENproto # Erstellung des Festplatten-Images aus dem Protoytpe # Image auf Festplattenpartition vbdcfg mkdomU –d /dev/hda5 -e 00:00:11:AA:BB.CC XENproto solaris1 |
| Abb. 7: Erstellung von Flash-Archiv, Prototype Image und Festplatten-Image. |
Sie sehen, für die Erstellung eines Solaris-Gastes sind mehrere Schritte nötig. Aber alles in allem ist es leicht zu meistern. Sowohl das Erstellen des Flash-Archivs als auch das Erstellen des Templates benötigen einige Zeit zur Ausführung. An Plattenplatz sollte für das Flash-Archiv etwa die Größe des Gastes bereitgestellt werden, für das Prototype Image etwa das 2 - 3-fache der Größe des Gastes. Gerade bei Solaris bietet es sich an, ein einmal erstelltes Gast-Image zu sichern und bei Bedarf für einen neuen Gast als Vorlage zu nehmen. Das Ausführen des Befehls vbdcfg mkproto erstellt ein Kernel Image und eine Konfigurationsdatei, die sofort für XEN genutzt werden kann, im Verzeichnis /export/xc/xvm/solaris1.
XEN bietet eine ganze Menge Funktionen und Möglichkeiten, die vor allem für den Firmeneinsatz interessant sind. Wenn man die aktuelle XEN-Entwicklung beobachtet, tut sich Einiges. Im nächsten stabilen Linux Kernel 2.6.20 wird eine Schnittstelle für XEN enthalten sein, so dass kein Kernel Patch mehr notwendig sein wird, um XEN zu betreiben. Mitte 2008 wird auch Sun Solaris XEN beherrschen. Und auch einige weitere, interessante Funktionen stehen auf der Warteliste, über die wir in einer zukünftigen ORDIX News berichten.
Christian Fertsch (info@ordix.de).