Citrix Hypervisor

Speicher

In diesem Abschnitt wird beschrieben, wie physische Speicherhardware virtuellen Maschinen (VMs) zugeordnet wird, und die Software-Objekte, die von der Management-API zum Ausführen von speicherbezogenen Aufgaben verwendet werden. Detaillierte Abschnitte zu den unterstützten Speichertypen enthalten die folgenden Informationen:

  • Verfahren zum Erstellen von Speicher für VMs mit der Befehlszeilenschnittstelle mit typspezifischen Gerätekonfigurationsoptionen
  • Generieren von Snapshots für Backupzwecke
  • Best Practices für die Speicherverwaltung
  • QoS-Einstellungen (Quality of Service) für virtuelle Festplatte

Speicher-Repositories (SRs)

Ein Speicher-Repository (SR) ist ein bestimmtes Speicherziel, in dem Virtual Machine (VM) Virtual Disk Images (VDIs) gespeichert werden. Ein VDI ist eine Speicherabstraktion, die ein virtuelles Festplattenlaufwerk (HDD) darstellt.

SRs sind flexibel und unterstützen die folgenden Laufwerke:

Lokal verbunden:

  • IDE
  • SATA
  • SCSI
  • SAS

Remote verbunden:

  • iSCSI
  • NFS
  • SAS
  • Fibre-Channel

Mit den SR- und VDI-Abstraktionen können erweiterte Speicherfunktionen auf Speicherzielen verfügbar gemacht werden, die diese unterstützen. Beispielsweise erweiterte Funktionen wie Thin Provisioning, VDI-Snapshots und schnelles Klonen. Für Speichersubsysteme, die erweiterte Vorgänge nicht direkt unterstützen, wird ein Software-Stack bereitgestellt, der diese Funktionen implementiert. Dieser Software-Stack basiert auf Microsofts Virtual Hard Disk (VHD) Spezifikation.

SR-Befehle bieten Operationen zum Erstellen, Löschen, Ändern der Größe, Klonen, Verbinden und Entdecken der einzelnen VDIs, die sie enthalten.

Ein Speicher-Repository ist eine persistente Datenstruktur auf dem Datenträger. Bei SR-Typen, die ein zugrunde liegendes Blockgerät verwenden, umfasst das Erstellen einer SR das Löschen vorhandener Daten auf dem angegebenen Speicherziel. Andere Speichertypen wie NFS erstellen parallel zu vorhandenen SRs einen Container auf dem Speicher-Array.

Jeder Citrix Hypervisor-Server kann mehrere SRs und verschiedene SR-Typen gleichzeitig verwenden. Diese SRs können zwischen Hosts gemeinsam genutzt oder für bestimmte Hosts reserviert werden. Gemeinsam genutzter Speicher wird zwischen mehreren Hosts innerhalb eines definierten Ressourcenpools gepoolt. Eine gemeinsam genutzte SR muss für jeden Host im Pool ein Netzwerk zugänglich sein. Alle Server in einem einzelnen Ressourcenpool müssen mindestens eine gemeinsam genutzte SR haben. Freigegebener Speicher kann nicht zwischen mehreren Pools gemeinsam genutzt werden.

CLI-Vorgänge zum Verwalten von Speicher-Repositories werden unter beschrieben SR-Befehle.

Warnung:

Citrix Hypervisor unterstützt kein externes Snapshotting auf SAN-Ebene einer LUN für einen beliebigen SR-Typ.

Virtual Disk Image (VDI)

Ein Virtual Disk Image (VDI) ist eine Speicherabstraktion, die ein virtuelles Festplattenlaufwerk (HDD) darstellt. VDIs sind die grundlegende Einheit des virtualisierten Speichers in Citrix Hypervisor. VDIs sind persistente, auf der Festplatte befindlichen Objekte, die unabhängig von den Citrix Hypervisor-Servern vorhanden sind. CLI-Vorgänge zur Verwaltung von VDIs werden unter beschrieben VDI-Befehle. Die Darstellung der Daten auf der Festplatte unterscheidet sich je nach SR-Typ. Eine separate Speicher-Plug-in-Schnittstelle für jeden SR, die sogenannte SM-API, verwaltet die Daten.

Physische Blockgeräte (PBDs)

Physische Blockgeräte stellen die Schnittstelle zwischen einem physischen Server und einer angeschlossenen SR dar. PBDs sind Connector-Objekte, mit denen ein bestimmter SR einem Host zugeordnet werden kann. PBDs speichern die Gerätekonfigurationsfelder, die verwendet werden, um eine Verbindung mit einem bestimmten Speicherziel herzustellen und mit ihm zu interagieren. Die NFS-Gerätekonfiguration umfasst beispielsweise die IP-Adresse des NFS-Servers und den zugehörigen Pfad, den der Citrix Hypervisor-Server bereitstellt. PBD-Objekte verwalten die Laufzeitanhänge einer bestimmten SR an einen bestimmten Citrix Hypervisor-Server. CLI-Vorgänge, die sich auf PBDs beziehen, werden unter beschrieben PBD-Befehle.

Virtuelle Blockgeräte (VBDs)

Virtuelle Blockgeräte sind Connector-Objekte (ähnlich der oben beschriebenen PBD), die Zuordnungen zwischen VDIs und VMs ermöglichen. Neben der Bereitstellung eines Mechanismus zum Anhängen eines VDI an eine VM ermöglichen VBDs die Feinabstimmung von Parametern bezüglich QoS (Quality of Service) und Statistiken eines bestimmten VDI und die Frage, ob dieser VDI gestartet werden kann. CLI-Vorgänge in Bezug auf VBDs werden unter beschrieben VBD-Befehle.

Zusammenfassung der Speicherobjekte

Die folgende Abbildung zeigt, wie sich die bisher dargestellten Speicherobjekte zusammenhängen:

Grafische Übersicht über Speicher-Repositories und zugehörige Objekte

Datenformate für virtuelle Festplatten

Im Allgemeinen gibt es die folgenden Arten der Zuordnung des physischen Speichers zu einem VDI:

  1. Logische Volume-basierte virtuelle Festplatte auf einer LUN: Der standardmäßige blockbasierte Citrix Hypervisor Speicher fügt einen logischen Volume-Manager auf einem Datenträger ein. Bei dieser Festplatte handelt es sich entweder um ein lokal angeschlossenes Gerät (LVM) oder eine SAN angeschlossene LUN über Fibre Channel, iSCSI oder SAS. VDIs werden als Volumes innerhalb des Volume-Managers dargestellt und im VHD-Format gespeichert, um eine Thin Provisioning von Referenzknoten auf Snapshot und Clone zu ermöglichen.

  2. Dateibasiertes QCOW2 auf einer LUN: VM-Images werden als dünn bereitgestellte QCOW2-Dateien im QCOW2-Format auf einem GFS2-Dateisystem auf einer LUN gespeichert, die entweder über iSCSI-Softwareinitiator oder Hardware-HBA angeschlossen ist.

  3. Dateibasierte virtuelle Festplatte auf einem Dateisystem: VM-Images werden als dünn bereitgestellte VHD-Formatdateien auf einem lokalen, nicht gemeinsam genutzten Dateisystem (EXT-Typ SR) oder einem gemeinsam genutzten NFS-Ziel (NFS-Typ SR) gespeichert.

VDI-Typen

Für die meisten SR-Typen werden VDIs im VHD-Format erstellt. Sie können zum Zeitpunkt des Erstellens des VDI die Option “Raw” verwenden. Diese Option kann nur mit der xe CLI angegeben werden. Für GFS2-SRs werden QCOW2-VDIs erstellt.

Um zu überprüfen, ob ein VDI mit erstellt wurde type=raw, überprüfen Sie die zugehörige sm-config Karte. Hierfür können jeweils die xe-Befehle sr-param-list und vdi-param-list verwendet werden.

Erstellen eines virtuellen Rohdatenträgers mit der Xe-CLI

  1. Führen Sie den folgenden Befehl aus, um einen VDI mit der UUID des SR zu erstellen, in dem Sie das virtuelle Laufwerk ablegen möchten:

    xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \
            name-label=VDI name sm-config:type=raw
    
  2. Schließen Sie das neue virtuelle Laufwerk an eine VM an. Verwenden Sie die Datenträgertools innerhalb der VM zum Partitionieren und Formatieren oder anderweitig die neue Festplatte. Sie können den Befehl vbd-create verwenden, um eine VBD zu erstellen, um das virtuelle Laufwerk Ihrer VM zuzuordnen.

Konvertieren zwischen VDI-Formaten

Es ist nicht möglich, eine direkte Konvertierung zwischen den Roh- und VHD-Formaten durchzuführen. Stattdessen können Sie einen VDI erstellen (entweder roh, wie oben beschrieben, oder eine virtuelle Festplatte) und dann Daten von einem vorhandenen Volume in ihn kopieren. Verwenden Sie die xe CLI, um sicherzustellen, dass der neue VDI eine virtuelle Größe hat, die mindestens so groß ist wie der VDI, von dem Sie kopieren. Sie können dies tun, indem Sie das Feld virtual-size überprüfen, zum Beispiel mit dem Befehl vdi-param-list. Anschließend können Sie diesen neuen VDI an eine VM anhängen und Ihr bevorzugtes Tool innerhalb der VM verwenden, um eine direkte Blockkopie der Daten zu erstellen. Zum Beispiel Standard-Datenträgerverwaltungstools in Windows oder der Befehl dd in Linux. Wenn es sich bei dem neuen Volume um ein VHD-Volume handelt, verwenden Sie ein Tool, mit dem Sie keine leeren Sektoren auf die Festplatte schreiben können. Diese Aktion kann sicherstellen, dass Speicherplatz im zugrunde liegenden Speicher-Repository optimal genutzt wird. Ein dateibasierter Kopieransatz kann besser geeignet sein.

VHD-basierte und QCOW2-basierte VDIs

VHD- und QCOW2-Images können verkettetwerden, sodass zwei VDIs gemeinsame Daten gemeinsam nutzen können. In Fällen, in denen eine VHD-gestützte oder QCow2-gestützte VM geklont wird, teilen sich die resultierenden VMs zum Zeitpunkt des Klonens die gemeinsamen Daten auf der Festplatte. Jede VM nimmt ihre eigenen Änderungen in einer isolierten Copy-on-Write-Version des VDI vor. Mit dieser Funktion können solche VMs schnell aus Vorlagen geklont werden, was eine sehr schnelle Provisioning und Bereitstellung neuer VMs ermöglicht.

Wenn VMs und die zugehörigen VDIs im Laufe der Zeit geklont werden, werden dadurch Strukturen verketteter VDIs erstellt. Wenn einer der VDIs in einer Kette gelöscht wird, rationalisiert Citrix Hypervisor die anderen VDIs in der Kette, um unnötige VDIs zu entfernen. Dieser Koaleszierungsprozess wird asynchron ausgeführt. Der zurückgeforderte Speicherplatz und die benötigte Zeit für die Durchführung des Prozesses hängen von der Größe des VDI und der Menge der gemeinsam genutzten Daten ab.

Sowohl die VHD- als auch QCOW2-Formate unterstützen Thin Provisioning. Die Imagedatei wird automatisch in feinen granularen Blöcken erweitert, wenn die VM Daten in die Festplatte schreibt. Bei dateibasierten VHD und GFS2-basierten QCOW2 hat dieser Ansatz den erheblichen Vorteil, dass VM-Image-Dateien nur so viel Speicherplatz auf dem physischen Speicher belegen, wie erforderlich. Bei LVM-basierter VHD muss der zugrunde liegende logische Volume-Container auf die virtuelle Größe des VDI angepasst werden. Jedoch wird ungenutzter Speicherplatz auf der zugrunde liegenden Copy-on-Write-Instanzfestplatte freigegeben, wenn ein Snapshot oder ein Klon auftritt. Der Unterschied zwischen den beiden Verhaltensweisen kann folgendermaßen beschrieben werden:

  • Bei LVM-basierten VHD-Imagesverbrauchen die Differenzfestplattenknoten innerhalb der Kette nur so viele Daten, wie sie auf die Festplatte geschrieben wurden. Die Blattknoten (VDI-Klone) bleiben jedoch vollständig auf die virtuelle Größe des Datenträgers aufgeblasen. Snapshot-Blatt-Knoten (VDI-Snapshots) bleiben deflationiert, wenn sie nicht verwendet werden, und können schreibgeschützt angefügt werden, um die deflationierte Zuweisung beizubehalten. Snapshot-Knoten, die mit Lese-/Schreibzugriff verbunden sind, werden beim Anhängen vollständig aufgeblasen und beim Trennen deflationiert.

  • Bei dateibasierten VHDs und GFS2-basierten QCOW2-Imagesverbrauchen alle Knoten nur so viele Daten, wie sie geschrieben wurden. Die Blattknotendateien wachsen, um Daten aufzunehmen, während sie aktiv geschrieben werden. Wenn eine VDI mit 100 GB für eine VM zugewiesen ist und ein Betriebssystem installiert ist, hat die VDI-Datei physisch nur die Größe der Betriebssystemdaten auf der Festplatte sowie einen geringfügigen Metadatenaufwand.

Beim Klonen von VMs basierend auf einer einzelnen VHD- oder QCOW2-Vorlage bildet jede untergeordnete VM eine Kette, in der neue Änderungen in die neue VM geschrieben werden. Alte Blöcke werden direkt aus der übergeordneten Vorlage gelesen. Wenn die neue VM in eine weitere Vorlage konvertiert und weitere VMs geklont wurde, führt die daraus resultierende Kette zu einer Leistungsminderung. Citrix Hypervisor unterstützt eine maximale Kettenlänge von 30. Nähern Sie sich dieser Grenze nicht ohne guten Grund. Im Zweifelsfall “kopieren” Sie die VM mit XenCenter oder verwenden Sie den Befehl vm-copy, mit dem die Kettenlänge auf 0 zurückgesetzt wird.

VHD-spezifische Hinweise zur Koalesze-Koalesze-

Nur ein einziger Koaleszierungsprozess ist je für einen SR aktiv. Dieser Prozessthread wird auf dem SR-Master-Host ausgeführt.

Wenn kritische VMs auf dem Masterserver des Pools ausgeführt werden, können Sie die folgenden Schritte ausführen, um gelegentlich langsame E/A zu vermeiden:

  • Migrieren der VM auf einen anderen Host als den SR-Master

  • Legen Sie die Festplatten-E/A-Priorität auf eine höhere Ebene fest, und passen Sie den Scheduler an. Weitere Informationen finden Sie unter QoS-Einstellungen für virtuelle Festplatte.

Speicher