Xen-Installation-Seite-5

aus PUG, der Penguin User Group
Wechseln zu: Navigation, Suche

Aufteilung

Aufgrund der Länge habe ich die Anleitung nun aufgeteilt. Am Ende der jeweiligen Seite findet einen Link zur nachfolgenden Seite.

Offline/Online Migration

Überblick

Ein wesentlicher Vorteil der Virtualisierung besteht in der Möglichkeit, die Gäste bei Bedarf auf andere physische Rechner zu verschieben. Dabei finden sich verschiedene Methoden in der Anwendung wieder.
Da wären zum einen die Datei Variante, welche zugleich am einfachsten zu realisieren ist. Dabei wird der Gast, welcher in einer Datei residiert, einfach auf einen anderen Xen Wirt kopiert und von dort erneut gestartet.
Der Nachteil an dieser Vartiante besteht in der Verfügbarkeit der Gäste. Für den Zeitraum der Migration wird der Gast heruntergefahren und auf dem neuen physischen Host wieder gestartet. Diese Variante läuft ausschließlich manuell, da dies nur ein normaler Datei- Kopiervorgang ist.
Der Vorteil ist jedoch nicht außer Acht zu lassen, denn so lassen sich auch Backupkopien erzeugen. Des weiteren spielen auch unterschiedliche CPU Architekturen keine wesentliche Rolle, sofern der Kernel z.B. auf ix86 getrimmt wurde. Ein gemeinsamer Speicherort ist ebenfalls keine zwingende Voraussetzung.
Da diese Methode eine lange nicht Verfügbarkeit' nach sich zieht, ist Xen in der Lage Gäste ebenfalls zu migrieren, und kann so diesen Zeitraum der nicht Verfügbarkeit, minimieren.
Dabei wird der Gast für den Vorgang pausiert, wobei der Inhalt des Arbeitsspeichers in eine Datei gesichert wird, um dann auf dem anderen Wirt erneut geladen zu werden. Die Bedingung für einen solchen Vorgang ist ein gemeinsamer Speicherort, selbe CPU Architektur und eine entsprechende Konfiguration des Xen Daemons.
Im Optimalfall dauert die Migration dann nur wenige Sekunden, doch auch dieser Vorgang ist eine Offline Variante.
Die Crème de la crème besteht in der Online Migration. Dabei wird ein Gast sozusagen lebend auf einen anderen Wirt übertragen. Anwender bzw. die Applikationen merken von diesem Umzug in der Regel nichts. Im einfachsten Fall gehen ein, maximal drei, Pings verloren.
Die Aufgabe des Xen Daemons besteht dann darin, die Speicherinhalte nach und nach auf den neuen Host zu übertragen. Der Gast läuft auf dem Quellrechner nachwievor weiter und auch die Speicherinhalte ändern sich permanent, bis zu dem Punkt, an dem der Xen Daemon den Gast für einen winzigen Augenblick pausiert und die restlichen Änderungen auf den Zielrechner überträgt, um ihn dann dort fortzusetzen.
Dabei werden durch Arp Broadcasts die Änderung der MAC Adresse den Anderen mitgeteilt. Ohne die Bekanntmachung am schwarzen Brett würde die Kommunikation abbrechen und die Anwender sowie Applikationen ins Leere laufen.

In der Praxis

Die Offline Möglichkeit mittels der Imagedatei kopieren, muß ich nicht weiter erläutern, da es dort nichts zu beachten gibt.
Vorbereitung - ISCSI - Einführung
Um die Xen- eigene Migration zu verwenden, bedarf es in jedem Fall eines gemeinsamen Speicherortes. Dieser könnte auf NFS, od. einem SAN liegen. Da die NFS Variente eher selten anzutreffen ist, kommt in dieser Anleitung die SAN basierte Lösung zum Einsatz.
Da ein richtiges SAN in der Regel mit mehreren tausend Euro zu Buche schlägt, kommt das Preisgünstige ISCSI zum Einatz.
Es erlaubt Festplatten, Partitionen und Volumes, gleich welcher Art (IDE, SCSI, SATA), zu exportieren und Clients als SCSI Gerät zur Verfügung zu stellen.
ISCSI sendet SCSI Protokoll- Befehle über ein herkömmliches TCP/IP Netz und kann damit die vorhandene Infrastruktur nutzen. Mittels VPN lassen sich so schnell (De)Zentrale Speichernetze über das Internet aufbauen.
Damit Speicher im Netz über ISCSI verfügbar gemacht werden kann, bedarf es zweier Komponenten:
  • IET - ISCSI Enterprise Target
Der IET ist ein Daemon, der den Speicher über ISCSI verfügbar macht und entsprechend exportiert. Im ISCSI Jargon wird er Target genannt. Ihn benötigen wir daher auf dem Rechner mit dem Speicher.
Er bildet das Gegenstück zum IET. Auch er ist ein Daemon und seine Aufgabe ist es, den vom IET zur Verfügung gestellten Speicher auf dem Client (dem Xen Dom0 Host) einzubinden. Dieser wird Initiator genannt.
Vorbereitung - ISCSI - Installation - Server
Die nachfolgenden Schritte bedürfen einiger Kompilierarbeit und sollten daher dringend auf einer seperaten Maschine, oder einem virtuellen Gast vorgenommen werden. Denn ansonsten würde unser Wirt nur unnötig mit Ballast beladen werden.
Dieser Teil der Anleitung basiert im wesentlichen auf dem englischen Original und wurde nur übersetzt.
Für Debian (Sid/Etch) und Ubuntu Dapper stehen uns inoffizielle Pakete vom IET für Apt zur Verfügung. Um diese Nutzen zu können, müssen wir Apt einen neuen Server mitgeben:
  • /etc/apt/sources.list
Ascii.png
 
 # Für Debian Etch
  deb http://debian.hug.cx/debian/ unstable/
 
 # Für Ubuntu Dapper
  deb http://debian.hug.cx/debian/ dapper/
Je nach Distribution sollte die entsprechende Zeile eingebunden werden, um dann die Datenbank per apt-get update auf den neusten Stand zu bringen.
IET Kernel Modul
Da wir entsprechende Module benötigen, für IET, müssen wir diese passend zu unserem Kernel installieren:
Gnome-terminal.png
 
 dom0:# apt-get install module-assistant debhelper linux-source-2.6.18 dpkg-dev \
kernel-package libncurses-dev libssl-dev linux-headers-2.6.18-4-xen-vserver-686
Wurde ein anderer Kernel verwendet, sind entsprechend andere Kernel Headers zu installieren.
Als nächstes entpacken wir die Quellen und installieren sowie übersetzen das Modul für den IET.
Gnome-terminal.png
 
dom0:# cd /usr/src/
dom0:# tar xjf linux-source-2.6.18.tar.bz2
dom0:# ln -s linux-source-2.6.18 linux
Gnome-terminal.png
 
dom0:# apt-get install  iscsitarget iscsitarget-source
dom0:# tar xzf iscsitarget.tar.gz
dom0:# m-a a-i iscsitarget
Es laufen einige Scripte ab, die das Modul iscsi_trgt.ko übsetzen und als Debian Paket (iscsitarget-module-2.6.18-4-xen-vserver-686...deb) zur Installation bereitstellen.
IET Konfiguration
Damit der Daemon nun weiß, welchen Speicher er zur Verfügung stellen darf, müssen wir ihm dies durch eine neu erstellte Konfigurationsdatei mitteilen:
  • /etc/ietd.conf
Ascii.png
 
Target iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk
        Lun 0 Path=/dev/mapper/daten-vm03--disk,Type=fileio
        IncomingUser vm03 geheim
        Alias vm03-disk

Target iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap
        Lun 0 Path=/dev/mapper/daten-vm03--swap,Type=fileio
        IncomingUser vm03 geheim
        Alias vm03-swap
Wir können an diesem Beispiel sehen, dass wir zwei Speicher Einheiten freigeben. So ein Eintrag baut sich im folgenden auf:
Target iqn.2007-06.local.mainframe.rohan:storage.lvm.vm03-disk
Hier wird der Rechner angegeben, mit einer eindeutigen Zuordnung, der sogennanten IQN (ISCSI Qualified Name), ähnlich der MAC einer Netzwerkkarte. Diese muss in der Regel offiziell beantragt werden, doch im internen Umfeld spielt es keine Rolle.
Sie setzt sich zusammen aus:

iqn.<Datum der Target Aktivierung jjjj-mm>.<rekursiver DNS Name>:[freier String] 

Lun 0 Path=/dev/mapper/daten-vm03--disk,Type=fileio
Hier wird dem IETD mitgeteilt, welchen Datenträger er exportieren soll. Wie zu erkennen ist, wurde ein LVM Volume exportiert. Der Type fileio nutzt den Seitenspeicher (Page Cache) zum lesen und kopieren und ist daher in der Regel ein wenig schneller, also die Block Variante, die direkt die Blöcke auf den Datenträger schreibt, ohne Zwischenspeicher (Page Cache).
Laut dieser Mail eignet sich fileio gut zum lesen und schreiben von Blöcken mit weniger als 64k, während blockio besser für 64k und größere Blöcke ist.
IncomingUser vm03 geheim
Hier können wir einen User und ein Kennwort bestimmen, welches benötigt wird, um auf diesen Speicher zugriff zu haben.
Alias vm03-disk
In der letzten Zeilen können wir einen Alias vergeben, welcher dann von den Clients gesehen wird. Er ist nützlich für die Zuordnung und beugt einer Fehlkonfiguration vor.
Nach dieser Anpassung, können wir den IET Daemon (neu)starten:
Gnome-terminal.png
 
 rohan:# /etc/init.d/iscsitarget start
 Starting iSCSI enterprise target service: succeeded.
Im Syslog finden sich dann folgende Zeilen:
Gnome-terminal.png
 
 May 30 09:03:38 rohan kernel: iSCSI Enterprise Target Software - version 0.4.13
 May 30 09:03:38 rohan kernel: iotype_init(90) register fileio
 May 30 09:03:38 rohan kernel: iotype_init(90) register nullio
Da in meinem Fall der Rechner Rohan ebenfalls ein Xen Dom0 Wirt ist, bekommt der Rechner ebenfalls den Initiator, in Form von Open-ISCSI, installiert.
Vorbereitung Open-SCSI - Initiator
Open-SCSI wird unter Etch bereits mitgeliefert und bedarf nur eines einfachen Aufrufs zur Installation:
Gnome-terminal.png
 
 apt-get install open-iscsi
Danach stehen folgende Programme zur Verfügung:
  • iscsid - Ist der ISCSI Initiator Daemon
  • iscsiadm - Ist unser Verwaltungswerkzeug
Da die Node Verwaltungs- Informationen in einem nicht sonderlich lesbaren Format abgelegt worden sind, werden alle Parameter bezüglich der einzelnen Nodes, über das iscsiadm Werkezug verwaltet.
Open-SCSI - Konfiguration
Eine besonders wichtige Datei ist die /etc/initiatorname.iscsi. Sie enthält einen eindeutigen Namen, der in keinem Fall zwei Mal im SAN auftauchen darf. Daher ist es notwendig einen Blick in diese zu werfen:
  • /etc/initiatorname.iscsi
Ascii.png
 
 ## DO NOT EDIT OR REMOVE THIS FILE!
 ## If you remove this file, the iSCSI daemon will not start.
 ## If you change the InitiatorName, existing access control lists
 ## may reject this initiator.  The InitiatorName must be unique
 ## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
 InitiatorName=iqn.2007-05.local.mainframe.rohan:01-storage-server
Normalerweise ist der letzte Teil nach dem : ein eindeutiger String, wie z.B. 01.189fbf1f2ac1, aber in diesem Fall wurde er ausgetauscht.
Bei der Installation wurde eine Standard Konfigurationsdatei für den Daemon angelegt, welche folgenden Inhalt hat:
  • /etc/iscsid.conf
Ascii.png
 
node.active_cnx = 1
node.startup = manual
#node.session.auth.username = dima
#node.session.auth.password = aloha
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.MaxConnections = 0
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536
#discovery.sendtargets.auth.authmethod = CHAP
#discovery.sendtargets.auth.username = dima
#discovery.sendtargets.auth.password = aloha
Bis auf Benutzername und Passwort sollten die Werte belassen werden, es sei dann, man weiß, woran man dreht.
Um zu überprüfen, ob unsere IET Konfiguration erfolgreich lief, können wir mit dem iscsiadm entsprechend das System scannen:
Gnome-terminal.png
 
rohan:~# iscsiadm -m discovery -t st -p 192.168.1.2
192.168.1.2:3260,1 iqn.2007-06.local.mainframe.rohan:lvm.vm03-disk
192.168.1.2:3260,1 iqn.2007-06.local.mainframe.rohan:lvm.vm03-swap
Hier können wir erkennen, das uns der Rechner zwei Datenspeicher anbietet. Über die IQN Nummer können wir die Datenträger zuordnen.
Nach dem absetzen des Befehls wurden automatisch Dateien erstellt, welche sich unterhalb von /etc/iscsi/nodes/ und /etc/iscsi/send_targets befinden. Darin enthalten sind die Informationen des jeweiligen iSCSI Target und dessen Speicherfreigaben.
Nun können wir diese Speicher mit unserem System verbinden und eingliedern. Dazu genügt folgender Aufruf:
Gnome-terminal.png
 
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk --portal 192.168.1.2 '''-l'''
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap --portal 192.168.1.2 '''-l'''
Diese Informationen können wir z.B. über folgenden Befehl abfragen:
Gnome-terminal.png
 
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk --portal 192.168.1.2
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap --portal 192.168.1.2
Danach stellen sich folgende Werte für z.B. lvm.vm03-disk da:
Gnome-terminal.png
 
node.name = iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk
node.transport_name = tcp
node.tpgt = 1
node.active_conn = 1
node.startup = manual
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.auth.username = <empty>
node.session.auth.password = <empty>
node.session.auth.username_in = <empty>
node.session.auth.password_in = <empty>
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 192.168.3.1
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.active_timeout = 5
node.conn[0].timeo.idle_timeout = 60
node.conn[0].timeo.ping_timeout = 5
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
Wie wir erkennen können, ist der Wert node.startup = manual auf Handbetrieb gestellt. Um diesen auf Automatik umstellen zu können, bedarf es folgenden Befehls:
Gnome-terminal.png
 
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -o update -n node.conn[0].startup -v automatic -p 192.168.1.2
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -o update -n node.conn[0].startup -v automatic -p 192.168.1.2
Nach einem erneuten überprüfen, sehen wir den Wert von node.conn[0].startup = auf automatic stehen. Damit sollte beim erneuten Start des Software- Initiators Open-ISCSI, die Speicher lokal eingebunden werden.
Möchten wir, dass dieser Modus automatisch eingetragen wird, müssen wir in der /etc/iscsid.conf den Wert node.conn[0].startup = automatic eintragen.
Für einen manuellen Login bzw. Verbinden, reicht es einfach, wenn wir folgendes eingeben:
Gnome-terminal.png
 
iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -p 192.168.1.2 -l
iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -p 192.168.1.2 -l
Nun können wir uns mittels dmesg davon überzeugen, dass neue SCSI Geräte eingebunden worden sind.
Zum trennen eines Speichers, reicht folgender Befehl:
Gnome-terminal.png
 
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -p 192.168.1.2 -u
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -p 192.168.1.2 -u
Mit dieser Konfiguration hatte ich leider einen sehr hohen Timeout von bis zu 8 Minuten. Das Bedeutet, es vergehen rund 8 Minuten bis ISCSI einen Fehler meldet und Multipath auf den zweiten Weg umschaltet. Um dem ein wenig entgegen zu wirken, habe ich folgende Änderungen vorgenommen:
Gnome-terminal.png
 
iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -o update -n node.conn[0].timeo.noop_out_interval -v 5 -p 192.168.1.2
iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -o update -n node.conn[0].timeo.noop_out_interval -v 5 -p 192.168.1.2

iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -o update -n node.conn[0].timeo.noop_out_timeout -v 10 -p 192.168.4.1
iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -o update -n node.conn[0].timeo.noop_out_timeout -v 10 -p 192.168.4.1
Zusätzlich habe ich es in die Konfiguration eingetragen:
  • /etc/iscsid.conf
Ascii.png
 
[...]
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 20
[...]
Die Neuste Version von ISCSI soll wesentlich schneller auf Verbindungsabbrüche reagieren. Daher sollte in Erwägung gezogen werden, diese im produktiven Einsatz zu verwenden, statt der von Debian Etch.
Wir haben dann vier Datenträger.
Multipath - ISCSI
Überblick
Ein Problem welches eintreten kann, ist der Ausfall einer Netzwerk- Komponente, wie der einer Netzwerkkarte oder einem Switch. In solch einem Fall würden die jeweiligen VMs unweigerlich über die Klippe springen. Um einem solchen Vorfall vorzubeugen, können wir Multipath einsetzen. Multipath baut mehrere Wege zu einem Speicher im Netzwerk auf und kann so den Ausfall eines Weges kompensieren.
Unter dieser Technik werden mehrere Varianten verwendet:
  • Fixed
Fällt ein Weg aus, wird auf den nächsten Weg umgeschaltet. Sollte der Erstere wieder funktionieren, schaltet Multipath wieder auf den alten Pfad zurück.
  • MRU (Most Recently Used)
Hier wird ebenfalls auf den neuen Pfad umgeschaltet, mit dem Unterschied, dass Multipath den Weg beibehält, auch wenn der alte Weg wieder aktiv sein sollte.
Praxis
  • Hinweis
Die vorhandene Anleitung ist dem englischen Howto entnommen und wurde nur übersetzt und angepasst.
Linux bietet diese Technik ebenfalls, in Form der multipath-tools und kann unter Debian leicht nachinstalliert werden:
Gnome-terminal.png
 
 dom0:# apt-get install multipath-tools
Das System stellt zwei Netzwerkkarten zur Verfügung:
Gnome-terminal.png
 
dom0:~# ip addr show eth0
5: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:13:ce:a4:e9:ab brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.150/24 brd 192.168.3.255 scope global eth0
    inet6 fe80::213:ceff:fea4:e9ab/64 scope link 
       valid_lft forever preferred_lft forever

dom0:~# ip addr show eth1
2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:16:36:12:37:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.150/24 brd 192.168.4.255 scope global eth1
    inet6 fe80::216:36ff:fe12:37c0/64 scope link 
       valid_lft forever preferred_lft forever
Unser Speichersystem verfügt ebenfalls über zwei Netzwerkkarten und beide sind mit einem Crosslink Kabel verbunden worden.
Wenn beide Netzwerke funktionieren, verbinden wir über dieses Netzwerk die Speicher:
Gnome-terminal.png
 
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk --portal 192.168.'''4.1'''
 dom0:# iscsiadm --mode node --targetname iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap --portal 192.168.'''4.1'''
Und schalten sie gleich auf automatisch:
Gnome-terminal.png
 
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-disk -o update -n node.conn[0].startup -v automatic -p 192.168.'''4.1'''
 dom0:# iscsiadm -m node -T iqn.2007-05.local.mainframe.rohan:lvm.vm03-swap -o update -n node.conn[0].startup -v automatic -p 192.168.'''4.1'''
Als nächstes müssen eine Konfigurationsdatei /etc/multipath.conf anlegen. Zwei Beispieldateien finden sich unter /usr/share/doc/multipath-tools/examples. In diesem Fall verwenden wir folgende Konfiguration:
  • /etc/multipath.conf
Ascii.png
 
defaults {
    user_friendly_names yes
}
defaults {
        udev_dir        /dev
        polling_interval 5
        default_selector        "round-robin 0"
        default_getuid_callout  "/sbin/scsi_id -g -u -s /block/%n"
        failback        immediate
}
blacklist {
        wwid   SATA_TOSHIBA_MK8032G_163W3498T
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z][[0-9]*]"
        devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
multipaths {
        multipath {
                '''wwid                1494554000000000000000000010000001b1600000d000000'''
                alias                   vm03-disk
                path_grouping_policy    failover
                path_checker            readsector0

           }
       multipath {
                '''wwid               149455400000000000000000002000000261600000d000000'''
                alias                   vm03-swap
                path_grouping_policy    failover
                path_checker            readsector0
            }
}
Der hervorgehobene Teil, die wwid, muss entsprechend angepasst werden. Diese Nummer erfährt man z.B. über folgenden Weg:
Gnome-terminal.png
 
 dom0:# /sbin/scsi_id -g -u -s /block/sdb
 1494554000000000000000000010000001b1600000d000000
 
 dom0:# /sbin/scsi_id -g -u -s /block/sdc
149455400000000000000000002000000261600000d000000
Beide sind die entsprechenden ISCSI Speicher und die wwid muss sich mit den beiden anderen Datenspeichern decken, in meinem Fall /dev/sd[de]
Nach einem obligatorischem:
Gnome-terminal.png
 
 dom0:# /etc/init.d/multipath-tools reload
Sollte sich folgendes Bild zeigen:
Gnome-terminal.png
 
dom0:/etc/xen# multipath -ll
vm03-disk (1494554000000000000000000010000001b1600000d000000) dm-9 IET,VIRTUAL-DISK
[size=1.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=1][enabled]
 \_ 14:0:0:0 sdb 8:16  [active][ready]
\_ round-robin 0 [prio=1][enabled]
 \_ 15:0:0:0 sdc 8:32  [active][ready]

vm03-swap (149455400000000000000000002000000261600000d000000) dm-10 IET,VIRTUAL-DISK
[size=128M][features=0][hwhandler=0]
\_ round-robin 0 [prio=1][enabled]
 \_ 16:0:0:0 sdd 8:48  [active][ready]
\_ round-robin 0 [prio=1][enabled]
 \_ 17:0:0:0 sde 8:64  [active][ready]
Hier lassen sich wunderbar die Laufwerke aufzeigen, wer zu wem gehört ,und das beide Speicher auf zwei Wegen aktiv sind.
Nachdem reload haben wir nun außerdem zwei neue Laufwerke gewonnen, die sich unter /dev/mapper finden. Sie haben den Alias Namen erhalten, in diesem Beispiel also:
Gnome-terminal.png
 
 dom0:# ls -l /dev/mapper/vm03-*
 brw-rw---- 1 root disk 254,  9 2007-06-02 01:05 /dev/mapper/vm03-disk
 brw-rw---- 1 root disk 254, 10 2007-06-02 01:05 /dev/mapper/vm03-swap
Genau diese Laufwerke sind es, die wir in die Client Konfiguration dann eintragen:
  • /etc/xen/vm03.cfg
Ascii.png
 
 [...]
 disk    = [ 'phy:/dev/mapper/vm03-disk,sda1,w', 'phy:/dev/mapper/vm03-swap,sda2,w' ]
 [...]
Alternative - Bounding
Überblick
Wem die multipath-tools nicht zusagen, der kann auch die Netzwerk-Redundanz über das Verbinden zweier Netzwerkkarten (od.mehr) zu einem Interface über das Kernel Modul bounding.ko realisieren. Bereits seit dem Kernel 2.0 wurde dieses Modul innerhalb eines Linux Clusters Projekt (Beowulf) vom Autor Ronald Becker, der auch für sehr viele Netzwerkkarten Treiber zuständig ist, entworfen.
Im Gegensatz zu den Windows Systemen, spielt es unter Linux keine Rolle, welche Karte zum Einsatz kommt. Zwar empfiehlt es sich, zwei gleiche Modelle einzusetzen, ist jedoch kein muss.
Dabei stehen unterschiedliche Variante zur Auswahl, wie zum Beispiel Lasten Ausgleich (Load Balancing) oder einfaches Umschalten auf die funktionierende Leitung (fallback).

Xen Gäste migrieren

Da die Vorbereitungen soweit abgeschlossen wurden, können wir uns nun der Migration über Xen's eigene Schnittstellen beschäftigen.
Damit der Xen Daemon entsprechende Anfragen entgegen nehmen darf, bedarf es einiger Anpassungen in der Konfigurationsdatei:
  • /etc/xen/xend-config.sxp
Ascii.png
 
[...]
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[...]
Diese Konfiguration erlaubt schlicht jedem anderen Xen Hosts, sich mit diesem zu verbinden und Xen Gäste auf diesen zu übertragen. In einem Produktivsystem sollte davon Abstand genommen werden und der Parameter xend-relocation-address an eine dedizierte Netzwerkkarte gebunden werden, über welche ausschließlich die Xen Daemonen kommunizieren können.
Nach einem Neustart des Xend via /etc/init.d/xend restart, können wir auch schon den ersten Gast anpassen. Das wichtigste was es zu beachten gilt, ist, dass die Xen Gäste immer ihre Datenträger finden. Beim ISCSI können unter Umständen die Reihenfolgen vertauscht werden.
Um dem vorzubeugen nutzen wir entweder multipath oder die UUID des Speichers, welcher beim erstellen des Dateisystems generiert wurde.
Diese finden sich auf einem udev basierten System unter /dev/disk/by-uuid/.... Mittels dem Programm hwinfo (apt-get install hwinfo && hwinfo --disk | grep iscsi) können wir dies einfach überprüfen.
Nachdem wir nun die UUID ausgelesen habe, tragen wir sie entsprechend in die Konfigurationsdatei des Clients ein:
  • /etc/xen/vm03.cfg
Ascii.png
 
 [...]
 disk    = [ 'phy:/dev/disk/by-uuid/48436b4e-ab2a-4e93-b579-5bdc703b3e03,sda1,w', 'phy:/dev/disk/by-uuid/48436b4e-ab2a-4e93-b579-5bdc703b3e03,sda2,w' ]
 [...]
Damit sollte der Client nun immer die Platte richtig zuordnen, unabhängig davon, wie das System sie erkannt hat. Diese Datei muss auf jedem Xen Host gleich sein. Am einfachsten ließe sich dies mit einer NFS Freigabe bewältigen.
Als ersten Versuch werden wir einen gestarteten Xen Gast - vm03 - vom Wirt rohan auf dom0 übertragen. Dazu starten wir den Gast auf Rohan:
Gnome-terminal.png
 
rohan:/etc/iscsi# xm create vm03.cfg
Using config file "/etc/xen/vm03.cfg".
Started domain vm03
rohan:/etc/iscsi# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0      232     1 r-----     94.6
vm03                                          3       64     1 -b----      2.8
Messagebox info.png
 Es ist unbedingt darauf zu achten, dass alle Xen Wirte die selbe Uhrzeit haben, welches sich mittels eines Zeitserver sicherstellen lässt
Dialog-warning.png
 Stimmen die CPU oder Arbeitsspeicher Voraussetzungen auf dem Quell- und Zielsystem nicht überein, so wird der Gast verschwinden. Ein Rollback wird nicht ausgeführt.


Nun migrieren wir den Gast vm03, auf den zweiten Wirt dom0
Gnome-terminal.png
 
 rohan:# xm migrate vm03 dom0
Wird schnell ein Blick auf den Rechner rohan und dom0 geworfen, können wir folgendes beobachten:
Gnome-terminal.png
 
 rohan:/etc/iscsi# xm list
 Name                                      ID Mem(MiB) VCPUs State   Time(s)
 Domain-0                                   0      930     1 r-----    135.2
 migrating-vm03                             6       64     1 ---s--      8.8
Gnome-terminal.png
 
 dom0:# xm list
 Name                                      ID Mem(MiB) VCPUs State   Time(s)
 Domain-0                                   0      230     1 r-----     30.2
 vm03                                       1       64     1 --p---      0.0
Der Gast vm03 wird während der Übertragung pausiert (Status s steht eigentlich für Shutdown aber er wird auch beim migrieren angezeigt) und auf dem zweiten Host sehen wir ihn mit dem Status p für pausiert. Wurde der Vorgang abgeschlossen, findet sich der Gast auf dem neuen Wirt wieder.
Dies war eine klassische Offline Migration. Soll das System aber möglichst ohne Downtime migriert werden, genügt folgender Aufruf für eine Online Migration:
Gnome-terminal.png
 
 rohan:# xm migrate --live vm03 dom0
Der zusätzliche Parameter --live sorgt dafür, dass die Zeit der nicht Verfügbarkeit auf ein Bruchteil reduziert wird.
Per Broadcast wird der Switch darüber informiert, dass sich der Anschluß- Port, der entsprechenden MAC Adresse geändert hat. Dies sollte in der Regel zügig gehen. Ist dies nicht der Fall, kann es bis zur Reanimation der DomU ein wenig dauern.

Systemüberwachung

Eines der derzeit größten Mankos an der freien Xen Version besteht in der Überwachung der Wirte sowie dessen Gäste. Xen selbst bietet keine eingebaute Möglichkeit, eine umfassende Analyse der Auslastung zu erhalten. Es existert lediglich die Möglichkeit, der Echtzeitüberwachung, mittels xentop (xen top). xentop bietet zumindest einen schnellen Einblick in die derzeitige Auslastung und bietet folgendes Bild:
Xentop.png
Wer mehr möchte, muss stattdessen externe Software für diese Aufgabe bemühen.
Derzeit gibt es zwei interessante Anwendungen, die ihre Aufgabe mehr oder weniger ausführlich erfüllen:
Diese Anwendung bietet eine Webschnittstelle, basiert auf Python und wird auf dem Wirt installiert. Dies hat natürlich zur Folge, dass auf diesem dann entsprechend ein Webserver installiert wird. Hier sollte man sich ernsthaft fragen, ob dies immer noch dem Grundsatz So wenig wie möglich gerecht wird.
Wer ihn verwenden möchte, muss lediglich seiner Apt Quellen- Liste einen weiteren Eintrag hinzufügen:
  • /etc/apt/sources.list
Ascii.png
 
 deb ftp://ftp.gplhost.com/debian stable xen # US main ftp
 deb ftp://ftp.gplhost.sg/debian stable xen # Singapore mirror (for asian users)
 deb ftp://ftp.gplhost.fr/debian stable xen # Paris mirror (for european users)
Nach einem apt-get update' genügt der Aufruf apt-get install dtc-xen und die nötigen Anwendungen werden auf das System gespielt.
Die nachfolgenden Fragen können in der Regel durch gewunken werden und am Ende kann über die IP-Adresses der Dom0 auf die Software zugegriffen werden.
  • Nagios ist da weitaus mächtiger und bietet mehr Möglichkeiten als dtc-xen. Diese Software selbst gehört nicht zu Xen, sondern fragt Werte mittels Plugins (jede Sprache, die auf dem Client vorrätig ist) ab. Damit ist es nicht nur möglich Xen selbst zu überwachen, sondern ebenfalls die darin laufenden Gäste. Damit nicht genug: stimmt etwas nicht, kann entschieden werden, was passieren soll. Dies kann sich nicht nur in einer E-Mail od. SMS Nachricht manifestieren, sondern ebenfalls in der Auslösung einer Aktion. Einer dieser Aktionen könnte es sein, einen Gast von einem überlasteten Wirt, auf einen weniger ausgelasteten zu übertragen.
Im Falle von Nagios wird in der Regel ein eigener Rechner verwendet, um keinen SPoF (Single Point of Failure) zu bilden.
Doch all diese Parameter müssen zunächst einmal konfiguriert werden. Da Nagios ein größeres Verständnis voraussetzt, ist dies nichts, um es mal eben aufzusetzen, sondern verlangt Zeit. Hat man diese Software jedoch erst verstanden, so lässt sich damit so ziemlich alles überwachen, von SNMP Geräten angefangen, bis hin zu Serverdiensten und verschiedenen Betriebssystemen.
Ein Blick ist Nagios alle Mal wert und ich hoffe in nächster Zeit, eine auf Xen abgestimmte Minimal- Konfiguration für einen leichteren Einstieg anbieten zu können.
  • Mittlerweile kommen aber mehr und mehr Produkte auf den Markt, mit einer freundlichen Lizenz. Interessante Produkte wären z.B. Enomalism, OpenQRM sowie VirtualIron3

Quellen

ToDo

  • Windows installieren
  • Andere Wirte als Debian
  • SuSE als Gast
  • CentOS als Gast
  • Anleitung in kleine Teile stückeln

Zurück zur Seite 4 Zurück zum Start

--Denny 00:01, 28. Jul. 2007 (CEST)

Abgerufen von „https://www.pug.org/mediawiki/index.php?title=Xen-Installation-Seite-5&oldid=8114“