Wer sich mit dem Citrix XenServer beschäftigt wird sich irgendwann auch die Frage stellen wie der XenServer mit seinem Festplattenspeicher (hier Storage Repository bzw. SR) umgeht und wie dieser administriert, verwaltet und überwacht werden kann. Zuerst allerdings klären wir mal die einzelnen Objekte, die der XenServer im Zusammenhang mit Storage Repositories verwendet.

Das wichtigste Objekt ist das Storage Repository (kurz: SR) selbst. Es bezeichnet ein Container Objekt in dem der XenServer die virtuellen Festplatten für die Nutzung der einzelnen virtuellen Maschinen (kurz: VM) ablegt. Für die Verbindung zu diesem SR benutzt der XenServer ein Objekt mit der Bezeichnung Physical Block Device (kurz: PBD). Dieses PBD representiert die Schnittstelle zwischen dem XenServer und dem SR. Für jedes konfigurierte SR existiert jeweils ein einziges PBD. Innerhalb des Storage Repositories werden die virtuellen Festplatten Images für die virtuellen Maschinen abgelegt. Diese Objekte werden als Virtual Disk Images (kurz: VDI) bezeichnet und repräsentieren Datei basierende Disk Images im Microsoft .vhd Format. Die Verbindung zwischen der VM und dem VDI stellt ein weiteres Objekt mit der Bezeichnung Virtual Block Device (kurz: VBD) zur Verfügung. Jede VM kann mehrere VBD's haben, die jeweils eine Verbindung zu einem VDI herstellen können. Das VBD nimmt I/O Anfragen von der VM entgegen und übersetzt diese in Datei Operationen für das VDI. Das nachfolgende Diagramm stellt diese Verbindungen etwas vereinfacht dar.

Für die virtuellen Disk Images habe sich diverse Formate etabliert. Das bekannteste Format ist das bereits vorher erwähnte .vhd Format, dass von Microsoft bereits 2005 entwickelt wurde. Prinzipiell handelt es sich hier um eine einzelne Datei, die strukturell wie eine physikalische Festplatte aufgebaut ist. Bis zur Version 5 benutzte der XenServer dieses .vhd Format allerdings nicht als Standard, sondern nutze den Linux LVM (Logical Volume Manager). LVM ist ein natives Linux Filesystem, dass eine abstrahierende Schicht für den Zugriff auf das physische Block Device den virtuellen Maschinen zur Verfügung stellt. LVM hat gegenüber dem Datei basierenden .vhd Format einige Vorteile. Typischer Weise wird den virtuellen Maschinen eine LUN für den Zugriff auf die physische Festplatte zur Verfügung gestellt, die wesentlich Performanter als die File basierte Lösung ist. Wer dennoch das .vhd Format nutzen wollte, mußte das lokale SR erst von LVM zu EXT3 konvertieren. Bei gemeinsam verwendete Storage (Shared Storage) unterstützen nur NFS basierte Storage Repositories (Network File System) das .vhd Format.

Da das .vhd Format aber universeller Einsetzbar ist z.B. für die Citrix Provisioning Services oder Microsoft Hyper-V, wird seit XenServer Version 5.6 standardmäßig das LVHD Format, eine Erweiterung des Linux LVM als Standard benutzt. LVHD bietet die Möglichkeit, dass .vhd Format auf LVM basierten Storage zu verwenden. Ein Update von XenServer bis Version 5 mit LVM auf das ab XenServer Version 5.6 verwendete LVHD Format ist problemlos möglich. LVHD ist auch abwärtskompatibel zu LVM und erweitert LVM um nützliche Funktionen wie Thin-Provisioning, Fast-Cloning und Snapshots.

Ein weiteres und in diesem Beitrag das letzte beschriebene VDI Format ist Citrix StorageLink, oder besser ausgedrückt LUN-per-VDI. Dieses Format findet ausschließlich bei Shared Storage (iSCSI oder FibreChannel) Verwendung und beschreibt eine direkt als VDI verbundene LUN auf einem Storage Array. Die speziell benötigten Plug-In's sind im XenServer bereits für Storage Arrays von NetApp und Equalogic integriert. Citrix StorageLink erweitert diese Plug-In's um weitere Array-Typen. Durch StorageLink kann der XenServer direkt über die API mit dem Storage Array kommunizieren und Speicherplatz auf dem Array erzeugen und verwalten. Die Architektur von Citrix StorageLink zeigt das folgende Bild.

Für das Management von Storage auf einem Citrix XenServer ist es wichtig zu verstehen, wie der XenServer sein lokales Storage Repository also die physikalischen Festplatten sieht. Hier helfen uns ein paar einfache Linux Kommandos weiter.

Schauen wir uns zuerst mal alle physischen Festplatten an, die dem XenServer Host bekannt sind. Dies erledigen wir mit dem folgenden Kommando:

[root@xenserver ~]# fdisk -l 

Die Ausgabe gibt uns einige wichtige Informationen über die physikalisch vorhandenen Festplatten.

Die Ausgabe zeigt uns, dass es sich um ein lokales physisches Laufwerk an einem internen HP RAID Controller handelt. Das physische Laufwerk hat drei Partitionen, wobei die erste Partition die Bootinformationen enthält.Verbunden ist das Laufwerk im Ordner /dev/cciss/c0d0. Wenn dem XenServer Host noch weitere Laufwerke bekannt sind z.b. ein verbundenes iSCSI Shared Storage, würde bei der Ausgabe noch zusätzliche Informationen über dieses Device stehen.

Disk /dev/sda: 107,3 GB, 107374182400 bytes 
255 heads, 63 sectors/track, 13054 cylinders 
Units = cylinders of 16065 * 512 = 8225280 bytes 

Disk /dev/sda doesn't contain a valid partition table 

Der große Unterschied hierbei ist, dass dieses physische Device über einen Linux sg beziehungsweise über einen Standard SCSI Treiber im System eingebunden ist. Da dieses Gerät nicht über LVM im System eingebunden ist, enthält es logischer Weise keine lesbare und somit auch keine gültige Partitionstabelle.

Informationen über dieses Gerät liefert uns die Ausgabe des folgenden Linux Kommandos:

[root@xenserver ~]# sg_map -x 

/dev/sg0     0  0  0  0  13 
/dev/sg1     0  0  0  1  0     /dev/sda 
/dev/sg2     0  0  0  2  0     /dev/sdb 
/dev sg3     1  0  0  0  13 
/dev/sg4     1  0  0  1  0     /dev/sdc 
/dev/sg5     1  0  0  2  0     /dev/sdd 

Hier sehen wir beim Device /dev/sg5 (1) die Hostnummer, (0) den Bus, (0) die SCSI ID, (2) die LUN sowie (0) den SCSI Typ. Interessant an dieser Ausgabe ist die LUN, denn diese kann mit der konfigurierten LUN auf dem SAN Device abgeglichen werden. Aber auch die Hostnummer kann beim dokumentieren der Disk Topologie verwendet werden, da hier die unterschiedlichen Hostnummer für die entsprechenden Pfade zur SAN stehen.

Das nächste sehr hilfreiche Linux Kommando ist:

ll /dev/disk/by-id

Die Ausgabe von ll zeigt lediglich den Inhalt des Verzeichnisses /dev/disk/by-id (was auch ein ls -al /dev/disk/by-id macht).

cciss-3600508b1001035373120202020200003 -> ../../cciss/c0d0
cciss-3600508b1001035373120202020200003-part1 -> ../../cciss/c0d0p1
cciss-3600508b1001035373120202020200003-part2 -> ../../cciss/c0d0p2
cciss-3600508b1001035373120202020200003-part3 -> ../../cciss/c0d0p3
scsi-360a98000503350642f4a553833616b57 -> ../../sda

Interessant an der Ausgabe ist hier die die SCSI ID vom Device /sda die wir so auch im XenCenter wieder finden. Wichtig zu Wissen ist, dass udev beim Booten dieses (und noch weitere) Verzeichnis mit den bekannten Blockgeräten füllt. Wer einen Blick in das Verzeichnis /dev/disk/ wirft, sieht dort noch weitere by- Verzeichnisse, die uns interessante Informationen enthüllen.

root@xenserver ~]# ls -l /dev/disk/
total 0
drwxr-xr-x 2 root root 120 Aug  6 15:26 by-id
drwxr-xr-x 2 root root  60 Dec 15 16:19 by-label
drwxr-xr-x 2 root root 140 Aug  6 15:26 by-path
drwxr-xr-x 2 root root  60 Aug  6 15:26 by-scsibus
drwxr-xr-x 2 root root  80 Dec 15 16:19 by-uuid

Gerade für LVM (also vor XenServer 5.6) stehen noch weitere nützliche Kommandos zur Verfügung. Zuerst schauen wir uns mal unserer lokales Storage an:

[root@xenserver ~]# xe sr-list 
uuid ( RO)                : 6e993889-4d1f-f5e0-15ae-9bd02b59d806
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): xenserver
                type ( RO): lvm
        content-type ( RO): user

Die Ausgabe von sr-list zeigt uns die UUID des Storage Repositories sowie den Type, in diesem Fall LVM. Auch im XenCenter können wir den Storage Typ erkennen. Hier mal z.B. ein EXT3 Storage Repository.

Ein Reihe von nützlichen Linux Kommandos enthüllen uns noch weitere Informationen über LVM Storage. Die ersten beiden Kommandos sind pvs zum Anzeigen der physischen Volumes sowie vgs zum Anzeigen der Volume Gruppen.

[root@xenserver ~]# pvs
  PV         VG                                                 Fmt  Attr PSize   PFree 
  /dev/sda3  VG_XenStorage-6e993889-4d1f-f5e0-15ae-9bd02b59d806 lvm2 a-   141.39G 23.18G
[root@xenserver ~]# vgs
  VG                                                 #PV #LV #SN Attr   VSize   VFree 
  VG_XenStorage-6e993889-4d1f-f5e0-15ae-9bd02b59d806   1   9   0 wz--n- 141.39G 23.18G
[root@xenserver ~]#

Interessant bei dieser Ausgabe ist, dass bei beiden die Größe von PSize (bei pvs) und VSize (bei vgs) identisch ist. Bei der Installation eines XenServers reserviert sich dieser 8 GB (4 GB für sich selbst und 4 GB für Backup/Upgrad) der komplette restliche freie Speicherplatz auf der physischen Festplatte wird als lokales Storage für VM's zur Verfügung gestellt. Aus diesem Grund ist die Größe der physischen Partition identisch mit der Größe der LVM Volume Group.

Ein weiteres nützlichen Kommando bei LVM Storage ist lvs. Eine Beispiel-Ausgabe von LVM sieht wie folgt aus:

VHD-c67a887f-3a1a-41f4-8d40-1b21f6307c4a VG_XenStor...    -wi---  24.00G
VHD-c9b919a7-b93b-49ea-abe5-00acb8240cf5 VG_XenStor...    -wi-ao   8.00G
VHD-f3d26dde-254f-4d80-a3bb-d993e904bd63 VG_XenStor...    -wi---  24.00G
LV-e056f479-b0f3-49f3-bc5d-6c226657ae6c  VG_XenStor...    -wi-ao  10.00G
LV-ebdcad46-66d9-4020-baa1-0d5b6ac439c7  VG_XenStor...    -wi-ao  24.00G

Diese Ausgabe liefert uns einige sehr nützliche Informationen. Wir sehen hier alle virtuellen Disk-Images mit den UUID's, die auch so in der XenServer Datenbank stehen, sowie deren Größen. Zu sehen ist auch, dass wir zwei unterschiedliche Typen von VDI's haben. Einmal VHD, diese stammen vom XenServer 5.5 sowie LV, sogenannte RAW LVM VDI's, die von einem XenServer vor Version 5.5 erzeugt wurden. Beide Formate werden von LVM im XenServer 5.5 unterstützt (XenServer 5.6 nutzt LVM nicht mehr, sondern benutzt stattdessen das neue LVHD Format). An den Attributen erkennen wir auch, welche VDI's active (a) und open (o) also einer laufenden VM zugeordnet sind.

Aber auch mit den XE Kommandos der Xen-API können wir einiges über die weitere Struktur erfahren. Zuerst listen wir alle Storage Repositories mit xe sr-list auf.

 
[root@xenserver ~]#  xe sr-list content-type=user params=name-label,uuid,PBDs,VDIs 

uuid ( RO)          : e786f641-7ceb-ea4b-023f-dc872a2dbddb 
    name-label ( RW): Local storage 
          VDIs (SRO): 500473b7-ed63-4018-bbe5-5a3f84adb01a; ab7eeb10-758f-4c52-866d-e69a7303d583; 15603090-b783-4669-aa06-55f290234394 
          PBDs (SRO): eb464549-dfed-818a-2b29-2d8fe37631bd 

Wichtig hier ist nur die PDB-UUID, die wir bereits von den Ausgaben der Kommandos pvs, vgs und lvs kennen sollten. Mit dieser UUID können wir jetzt das verknüpfte PBD abfragen (wir erinnern uns, ein PBD pro SR).

 
[root@xenserver ~]#  xe pbd-list uuid=eb464549-dfed-818a-2b29-2d8fe37631bd params=uuid,sr-uuid,device-config,currently-attached 
uuid ( RO)                  : eb464549-dfed-818a-2b29-2d8fe37631bd 
               sr-uuid ( RO): e786f641-7ceb-ea4b-023f-dc872a2dbddb 
         device-config (MRO): device: /dev/disk/by-id/cciss-3600508b1001037343220202020200001-part3 
    currently-attached ( RO): true 

Nachdem wir nun die Ausgabe des PDB's haben und hier ist wichtig das es Verbunden ist (currently-attached=true), können wir uns das entsprechende VDI anschauen. Auch wichtig ist der Device-Pfad der hier mit /dev/disk/by-id/cciss-3600508b1001037343220202020200001-part3 angegeben wird. Aus der Ausgabe von unserem xe sr-list Kommando haben wir auch die UUID's von unseren virtuellen Disk Images (wir erinnern uns, jedes VDI repräsentiert eine virtuelle Festplatte).

 
[root@xenserver ~]#  xe vdi-list uuid=500473b7-ed63-4018-bbe5-5a3f84adb01a params=uuid,sr-uuid,vbd-uuids 
uuid ( RO)         : 500473b7-ed63-4018-bbe5-5a3f84adb01a 
      sr-uuid ( RO): e786f641-7ceb-ea4b-023f-dc872a2dbddb 
    vbd-uuids (SRO): 221aa2ba-5399-2d6d-0283-7b2c58b83c7e 

Mit der VBD-UUID (wir erinnern uns, ein VBD pro VDI) können wir jetzt Abfragen welche virtuelle Maschine zu dem virtuellen Disk Image (VDI) gehört.

 
[root@xenserver ~]# xe vbd-list uuid=221aa2ba-5399-2d6d-0283-7b2c58b83c7e params=uuid,vm-uuid,vm-name-label,vdi-uuid,mode 
uuid ( RO)             : 221aa2ba-5399-2d6d-0283-7b2c58b83c7e 
          vm-uuid ( RO): 07b17b7c-7553-6995-3ea5-ea53aa3d6f68 
    vm-name-label ( RO): fragridxn01 
         vdi-uuid ( RO): 500473b7-ed63-4018-bbe5-5a3f84adb01a 
             mode ( RW): RW 

Schaut man sich den Aufbau und den Ablauf in der XenAPI an auf die alle xe Kommandos zugreifen, werden die Zusammenhänge ein wenig klarer.

Für lokale Storage Repositories gibt es eine Reihe von Linux Kommandos, die uns ein wenig beim Monitoring der Performance von lokalen Festplatten unterstützen können. Das erste nützliche Tool ist iostat, welches bei fast jeder Linux Distribution (so auch beim Citrix XenServer) enthalten ist.

 
[root@xenserver ~]# iostat -k 
Linux 2.6.32.12-0.7.1.xs5.6.90.230.170558xen (fraeqgdd2005)     02/08/2011 

avg-cpu:  %user   %nice %system %iowait  %steal   %idle 
           0.10    0.00    0.03    0.02    0.08   99.78 

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn 
cciss/c0d0        2.51         7.97        19.70   80463976  198884383 
cciss/c0d0p1      0.51         0.07         4.24     713113   42829632 
cciss/c0d0p2      0.00         0.00         0.00       6344          0 
cciss/c0d0p3      2.01         7.90        15.45   79744347  156054751 
dm-0              0.03         0.00         0.11       2533    1134900 

Die Ausgabe von iostat ist relativ selbsterklärend und zeigt eine Momentaufnahme was gerade so auf den lokalen Platten passiert. Allerdings liefert iostat bei externen Storage (iSCSI oder FC) keine verlässlichen Informationen, da externe Flaschenhälse wie z.B. das Netzwerk nicht berücksichtigt werden. Ein ähnliches Kommando ist hdparm.

 
[root@xenserver ~]# hdparm -t /dev/cciss/c0d0 

/dev/cciss/c0d0: 
 Timing buffered disk reads:  292 MB in  3.01 seconds =  96.86 MB/sec 

hdparm zeigt uns in der Ausgabe ebenfalls eine Momentaufnahme von sequentiellen Lesevorgängen auf das lokale Blockgerät. Für das reine Monitoring ist hdparm allerdings nicht zu gebrauchen, das es weder nicht-sequentielle Lesevorgänge noch Schreibvorgänge berücksichtigt. Für externes Storage berücksichtigt hdparm genauso wie iostat keine darunterliegende Busarchitektur und ist somit für iSCSI oder FC Storage nicht brauchbar. Um ein aussagekräftiges Ergebnis zu erhalten sollte hdparm in einer Schleife über einen längeren Zeitraum ausgeführt werden.

Fragt man im Linux-Umfeld welches Tool für das Monitoring von Festplatten benutzt werden sollte, erhält man zu etwa 90% als Anwort dd. Prinzipiell macht dd nichts weiter als RAW Block-Level Daten von A nach B zu kopieren und zu Messen wie lange dies dauert. Mit dd kann man sehr einfach und sehr zuverlässig den Datendurchsatz bei sequentiellen Lese- und Schreibvorgängen messen.

 
[root@xenserver ~]# dd if=/dev/cciss/c0d0 of=/dev/null 
143305920+0 records in 
143305920+0 records out 
73372631040 bytes (73 GB) copied, 800.925 seconds, 91.6 MB/s

Bei dd ist aber auch Vorsicht angesagt, denn dieses Tool bietet bei falscher Anwendung auch die Möglichkeit, eine Festplatte oder eine virtuelle Disk komplett unbrauchbar zu machen. Die Parameter sind dabei recht einfach:

• if= Die Quelle von der dd lesen soll z.B. /dev/cciss/c0d0.
• of= Das Ziel auf dem dd schreiben soll z.B. /dev/null.