Storage und Citrix XenServer: Wie es funktioniert und was schief laufen kann

Bei Citrix XenServer Storage kann es zu Problemen zwischen Datenbank und Repository kommen, wenn es zu Diskrepanzen bei den IDs oder UUIDs kommt.

Storage ist eine Schlüssel-Komponente in einer XenServer-Umgebung von Citrix Systems. Die Virtual Machine Disk Image-Dateien (VMDK) befinden sich darauf und wenn etwas damit nicht in Ordnung ist, startet die virtuelle Maschine (VM) ganz einfach nicht. Wenn Sie in Ihrem Data Center einen XenServer betreiben und etwas mit dessen Administration zu tun haben, dann müssen Sie verstehen, wie Speicher organisiert ist.

In einer XenServer-Umgebung sind die physischen Storage-Geräte über ein Repository verfügbar. Darüber sitzt eine Datenbank, die den XenServer-Hosts den Zugriff auf den Speicher ermöglicht. Treten Probleme beim Erkennen des Speichers auf, hängt das häufig mit einer Diskrepanz zwischen den IDs des physischen Storage und denen in der XenServer-Datenbank zusammen. Bevor wir aber erklären, wie Sie bei so einem Problem den Fehler finden und beheben, erörtern wir zunächst den Zusammenhang zwischen XenServer und Storage.

Bei einem XenServer ist der Storage als Storage-Repositories organisiert. Darin befinden sich die VMDKs, die physischen Block-Geräte (Physical Block Devices) und die virtuellen Block-Geräte (Virtual Block Devices). Die virtuelle Maschine kann den Storage auf diverse Arten nutzen:

  • als eine virtuelle Festplatten-Datei (Virtual Disk File), die im VHD-Format (Virtual Hard Disk) oder in der virtuellen Disk angelegt wurde.
  • als LVM (Logical Volume Manager)
  • als direkte Verbindung zu einem SAN via Citrix StorageLink

Sieht man sich den XenServer-Storage genauer an, so ist ein Storage-Repository eine Abstraktion des physischen Festplatten-Geräts, das entweder lokal oder in einem SAN vorhanden sein kann. Im Storage-Repository des XenServers werden Virtual Disk Images als eine Storage-Abstraktion von Objekten erschaffen, die dann der VM bereit gestellt werden können. Um dies zu realisieren, verbindet sich das Storage-Repository mittels dem so genannten Physical Block Device „connector object“ (Verbindungsobjekt) mit den Block-basierten Geräten, die sich auf der lokalen Maschine, einem SAN oder irgendwo anders befinden. Basierend auf dem Virtual Disk Image, lässt sich der Speicher der virtuellen Maschine zur Verfügung stellen. Dieser Storage wird als Virtual Block Device connector object dargestellt, welches die VM wiederum als ihre virtuelle Festplatte sieht.

Wie bereits erwähnt, gibt es für eine VM drei Möglichkeiten, auf den Speicher zuzugreifen. Der klassische Weg ist die Verwendung der VHD-Dateien. Diese Dateien sind im Storage-Repository gespeichert und zwar in dem Format-Standard, den Microsoft im Jahre 2005 definiert hat. Seit der Einführung von XenServer 5.5 im Jahre 2009, bietet Citrix auch Zugriff via LVHD oder LVM-basierte Virtual Hard Disk an. Der Vorteil hier ist, dass die darunterliegende LVM-Ebene eine Verwendung moderner Management-Funktionen zulässt, wie zum Beispiel Klonen und Snapshots. Die dritte Option ist, die VM direkt über eine LUN mit einem Storage-Array zu verbinden. Das funktioniert aber nur dann, wenn das Storage-Array über ein entsprechendes Plugin verfügt.

Ein häufiges Problem dieses Speichers, ist eine Diskrepanz bei der Identifikation des Storage. Sollte das passieren, ist der Zugriff zum gesamten Storage verloren. Auf der XenServer-Plattform lassen sich die Festplatten-Geräte auf verschiedene Weise von unterschiedlichen Komponenten des Systems ansprechen. Im XenCenter ist der Storage durch eine SCSI-ID gekennzeichnet, die der UUID entspricht, die Sie in der XenServer-Konsole sehen. Ist der Storage vom XenCenter aus nicht erreichbar, überprüfen Sie, ob die von XenCenter verwendeten UUIDs mit denen in der XenServer-Konsole übereinstimmen. Verwenden Sie hierfür das Verzeichnis /dev/disk/by-uuid.

Ist das Storage LVM-basiert, finden Sie die Storage-ID des Festplatten-Gerätes mithilfe des Befehls pvs in der XenServer-Konsole. Die individuellen virtuellen Maschinen sind mit individuellen Logical Volumes verbunden. Um einen Überblick zu erhalten, benutzen Sie den Befehl lvs. Dieser zeigt ebenfalls eine ID an, die identisch zu der ID im XenCenter ist.

Sollte etwas an der Konfiguration des Speichers falsch sein, könnte der Befehl xe auf dem Host hilfreich sein. Mithilfe dieses Befehls überprüfen Sie den Host direkt und erhalten Sie Informationen darüber, welche Storage-Geräte der Host sieht. Der grundlegende Befehl sieht wie folgt aus: xe sr-list. Er zeigt die UUIDs an, die sich derzeit in Verwendung befinden. Weiterhin sehen Sie die Typisierung und alle anderen Parameter, die bei der Identifikation des Storage-Typs helfen.

Sie können den Befehl xe verwenden, um weitere Informationen über angeschlossenen Storage zu bekommen.

Verwenden Sie xe sr-list mit zusätzlichen Parametern, können Sie das Storage-Repository abfragen. Somit bekommen Sie noch detailliertere Informationen. Zum Beispiel finden Sie mit xe sr-list params=name-label,uuid,VDIs,PBDs die verschiedenen UUIDs, die dem Storage-Gerät zugewiesen sind. Das Ziel ist es, die UUIDs der tatsächlich genutzten Geräte zu finden, die sich im Storage-Repository befinden und diese UUIDs mit denen des XenCenters zu vergleichen. Sollte es an dieser Stelle Unstimmigkeiten geben, müssen Sie die Storage-Geräte in die XenCenter-Management-Umgebung abermals importieren, um damit die Datenbank neu aufzubauen.

Der Befehl xe sr-list bietet erweiterte Abfrage-Möglichkeiten, um die IDs der Storage-Geräte zu finden.

Sehen wir uns nun ein Beispiel aus der Realität an, das zeigt, wie es zu so einer Unstimmigkeit kommen kann. Ich arbeite mit einem IT-Unternehmen, das nach einer Migration des XenServer-Hosts in ein neues Data Center sämtliche Verbindungen zu allen Storage-Geräten verloren hat. Nach der Analyse der Konfiguration stellte sich heraus, dass die Probleme durch Nicht-Übereinstimmung der tatsächlichen IDs auf dem Storage und den IDs in der Datenbank des XenServers verursacht wurden. Sobald das als Ursache ausgemacht war, ließ sich schnell eine Lösung finden. Mithilfe des Befehls xe sr-rescan erfolgte ein erneuter Scan der IDs auf den physischen Geräten und im Anschluss ein Neuaufbau der Datenbank.

Storage-Eigenschaften lassen sich mithilfe des XenCenters monitoren.

 

Artikel wurde zuletzt im August 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Datenspeicherlösungen für virtuelle Server

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close