Speicher

Wichtig:

Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.

Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).

Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.

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

• Verfahren zum Erstellen von Speicher für VMs mithilfe der CLI mit typspezifischen Gerätekonfigurationsoptionen
• Generieren von Snapshots zu Sicherungszwecken
• Best Practices für die Speicherverwaltung

Speicher-Repositories (SRs)

Ein Storage Repository (SR) ist ein bestimmtes Speicherziel, in dem Virtual Machine (VM) Virtual Disk Images (VDIs) gespeichert werden. Ein VDI ist eine Speicherabstraktion, die eine virtuelle Festplatte (HDD) darstellt.

SRs sind flexibel und bieten integrierte Unterstützung für die folgenden Laufwerke:

Lokal verbunden:

• SATA
• SCSI
• SAS
• NVMe

Bei der lokalen physischen Speicherhardware kann es sich um eine Festplatte (HDD) oder ein Solid-State-Laufwerk (SSD) handeln.

Fernverbunden:

• iSCSI (Englisch)
• NFS
• SAS
• SMB (nur Version 3)
• Fibre-Channel (Glasfaser-Kanal)

Hinweis:

NVMe über Fibre Channel und NVMe über TCP werden nicht unterstützt.

Die SR- und VDI-Abstraktionen ermöglichen die Bereitstellung erweiterter Speicherfunktionen auf Speicherzielen, die sie unterstützen. Zum Beispiel können erweiterte Funktionen wie Schlanke Provisionierung, 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 der Virtual Hard Disk (VHD)-Spezifikation von Microsoft.

Ein Speicher-Repository ist eine persistente Datenstruktur auf dem Datenträger. Bei SR-Typen, die ein zugrunde liegendes Blockgerät verwenden, umfasst der Prozess der Erstellung einer SR das Löschen aller vorhandenen Daten auf dem angegebenen Speicherziel. Bei anderen Speichertypen, wie z. B. NFS, wird ein Container auf dem Speicher-Array parallel zu vorhandenen SRs erstellt.

Jeder Citrix Hypervisor-Server kann mehrere SRs und verschiedene SR-Typen gleichzeitig verwenden. Diese SRs können von mehreren Hosts gemeinsam genutzt oder für bestimmte Hosts dediziert werden. Shared Storage wird zwischen mehreren Hosts innerhalb eines definierten Ressourcenpools zusammengefasst. Eine freigegebene SR muss für jeden Host im Pool über das Netzwerk zugänglich sein. Alle Server in einem einzelnen Ressourcenpool müssen über mindestens eine gemeinsam genutzte SR verfügen. Freigegebener Speicher kann nicht von mehreren Pools gemeinsam genutzt werden.

SR-Befehle bieten Vorgänge zum Erstellen, Zerstören, Ändern der Größe, Klonen, Verbinden und Ermitteln der einzelnen VDIs, die sie enthalten. CLI-Vorgänge zum Verwalten von Speicher-Repositories werden unter SR-Befehle.

Warnung:

Citrix Hypervisor unterstützt keine Snapshots auf der externen SAN-Ebene einer LUN für einen SR-Typ.

Image virtueller Datenträger (VDI)

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

Physische Blockgeräte (PBDs)

Physische Blockgeräte stellen die Schnittstelle zwischen einem physischen Server und einer angehängten SR dar. PBDs sind Konnektorobjekte, mit denen ein bestimmter SR einem Host zugeordnet werden kann. PBDs speichern die Gerätekonfigurationsfelder, die für die Verbindung mit und die Interaktion mit einem bestimmten Speicherziel verwendet werden. Die NFS-Gerätekonfiguration enthält beispielsweise die IP-Adresse des NFS-Servers und den zugehörigen Pfad, den der Citrix Hypervisor-Server bereitstellt. PBD-Objekte verwalten die Laufzeitanbindung einer bestimmten SR an einen bestimmten Citrix Hypervisor-Server. CLI-Vorgänge im Zusammenhang mit PBDs werden in PBD-Befehle.

Virtuelle Blockgeräte (VBDs)

Virtuelle Blockgeräte sind Konnektorobjekte (ähnlich der oben beschriebenen PBD), die Zuordnungen zwischen VDIs und VMs ermöglichen. VBDs bieten nicht nur einen Mechanismus zum Anfügen eines VDI an eine VM, sondern ermöglichen auch die Feinabstimmung von Parametern in Bezug auf die Festplatten-E/A-Priorität und die Statistiken eines bestimmten VDI sowie die Angabe, ob dieser VDI gestartet werden kann. CLI-Vorgänge im Zusammenhang mit VBDs werden in VBD-Befehle.

Zusammenfassung der Speicherobjekte

Die folgende Abbildung ist eine Zusammenfassung der Beziehung zwischen den bisher vorgestellten Speicherobjekten:

Datenformate virtueller Festplatten

Im Allgemeinen gibt es die folgenden Arten der Zuordnung von physischem Speicher zu einer VDI:

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

2. Dateibasiertes QCOW2 auf einer LUN: VM-Images werden als Thin-Provisioning-Dateien im QCOW2-Format auf einem GFS2-Dateisystem mit gemeinsam genutzten Festplatten auf einer LUN gespeichert, die entweder über einen iSCSI-Software-Initiator oder einen Hardware-HBA angeschlossen ist.

3. Dateibasierte VHD auf einem Dateisystem: VM-Images werden als Dateien im Thin-Provisioning-VHD-Format entweder auf einem lokalen, nicht freigegebenen Dateisystem (EXT3/EXT4-Typ SR), einem freigegebenen NFS-Ziel (NFS-Typ SR) oder einem Remote-SMB-Ziel (SMB-Typ SR) gespeichert.

VDI-Typen

Für GFS2-SRs werden QCOW2-VDIs erstellt.

Für andere SR-Typen werden VDIs im VHD-Format erstellt. Sie können sich dafür entscheiden, Raw zum Zeitpunkt der Erstellung des VDI zu verwenden. Diese Option kann nur mit der xe CLI angegeben werden.

Hinweis:

Wenn Sie eine unformatierte VDI auf einer LVM-basierten SR oder HBA/LUN pro VDI-SR erstellen, kann die besitzende VM auf Daten zugreifen, die Teil einer zuvor gelöschten VDI (in einem beliebigen Format) waren, die zu einer beliebigen VM gehört. Es wird empfohlen, dass Sie Ihre Sicherheitsanforderungen berücksichtigen, bevor Sie diese Option verwenden.

Unformatierte VDIs auf einer NFS-, EXT- oder SMB-SR erlauben keinen Zugriff auf die Daten zuvor gelöschter VDIs, die zu einer VM gehören.

So überprüfen Sie, ob eine VDI mit typ=roh, überprüfen Sie die sm-config Landkarte. Das sr-param-liste und vdi-param-liste Zu diesem Zweck können entsprechende XE-Befehle verwendet werden.

Erstellen eines unformatierten virtuellen Laufwerks mit der xe CLI

1. Führen Sie den folgenden Befehl aus, um eine VDI mit der UUID der SR zu erstellen, in der Sie den virtuellen Datenträger platzieren möchten:

     xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \
             name-label=VDI name sm-config:type=raw
   <!--NeedCopy-->
   

2. Fügen Sie den neuen virtuellen Datenträger an einen virtuellen Computer an. Verwenden Sie die Datenträgertools auf der VM, um den neuen Datenträger zu partitionieren und zu formatieren, oder verwenden Sie ihn auf andere Weise. Sie können die Funktion vbd-create , um eine VBD zu erstellen, mit der der virtuelle Datenträger Ihrer VM zugeordnet werden kann.

Konvertieren zwischen VDI-Formaten

Es ist nicht möglich, eine direkte Konvertierung zwischen dem Rohformat und dem VHD-Format durchzuführen. Stattdessen können Sie eine VDI erstellen (entweder unformatiert, wie oben beschrieben, oder VHD) und dann Daten von einem vorhandenen Volume in diese VDI kopieren. Verwenden Sie die xe CLI, um sicherzustellen, dass die neue VDI eine virtuelle Größe hat, die mindestens so groß ist wie die VDI, von der Sie kopieren. Sie können dies tun, indem Sie die virtuelle Größe , z. B. mit dem Feld vdi-param-liste Befehl. Sie können diese neue VDI dann an eine VM anhängen und Ihr bevorzugtes Tool innerhalb der VM verwenden, um eine direkte Blockkopie der Daten durchzuführen. Zum Beispiel Standard-Datenträgerverwaltungstools in Windows oder die Dd -Befehl unter Linux. Wenn es sich bei dem neuen Volume um ein VHD-Volume handelt, verwenden Sie ein Tool, mit dem das Schreiben leerer Sektoren auf den Datenträger vermieden werden kann. Durch diese Aktion kann sichergestellt werden, dass der Speicherplatz im zugrunde liegenden Speicher-Repository optimal genutzt wird. Ein dateibasierter Kopieransatz ist möglicherweise besser geeignet.

VHD-basierte und QCOW2-basierte VDIs

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

Wenn VMs und die zugehörigen VDIs im Laufe der Zeit geklont werden, werden Strukturen von verketteten 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. Das sich vereinigend Der Prozess wird asynchron ausgeführt. Die Menge des zurückgewonnenen Speicherplatzes und die Zeit, die zum Ausführen des Prozesses benötigt wird, hängen von der Größe der VDI und der Menge der freigegebenen Daten ab.

Sowohl das VHD- als auch das QCOW2-Format unterstützen Schlanke Provisionierung. Die Image-Datei wird automatisch in feingranularen Blöcken erweitert, wenn die VM Daten auf den Datenträger schreibt. Für dateibasierte VHD- und GFS2-basierte QCOW2 hat dieser Ansatz den erheblichen Vorteil, dass VM-Image-Dateien nur so viel Speicherplatz auf dem physischen Speicher beanspruchen, wie benötigt wird. Bei LVM-basierter VHD muss die Größe des zugrunde liegenden Containers für logische Datenträger an die virtuelle Größe des VDI angepasst werden. Ungenutzter Speicherplatz auf dem zugrunde liegenden Copy-on-Write-Instanzdatenträger wird jedoch freigegeben, wenn ein Snapshot oder Klon auftritt. Der Unterschied zwischen den beiden Verhaltensweisen kann wie folgt beschrieben werden:

• Für LVM-basierte VHD-Imagesverwenden, verbrauchen die unterschiedlichen Festplattenknoten innerhalb der Kette nur so viele Daten, wie auf die Festplatte geschrieben wurden. Die Leaf-Knoten (VDI-Klone) bleiben jedoch vollständig auf die virtuelle Größe des Datenträgers aufgebläht. Snapshot-Leaf-Knoten (VDI-Snapshots) bleiben deflationiert, wenn sie nicht verwendet werden, und können schreibgeschützt angehängt werden, um die deflationierte Zuweisung beizubehalten. Snapshot-Knoten, an die Lese-/Schreibzugriff angehängt ist, werden beim Anfügen vollständig aufgebläht und beim Trennen entleert.

• Für dateibasierte VHDs und GFS2-basierte QCOW2-Bilderverwenden, verbrauchen alle Knoten nur so viele Daten, wie geschrieben wurden. Die Blattknotendateien werden erweitert, um Daten aufzunehmen, während sie aktiv geschrieben werden. Wenn einer VM ein VDI mit 100 GB zugewiesen und ein Betriebssystem installiert ist, hat die VDI-Datei physisch nur die Größe der Betriebssystemdaten auf dem Datenträger zuzüglich eines geringfügigen Metadaten-Overheads.

Beim Klonen von VMs, die auf einer einzelnen VHD- oder QCOW2-Vorlage basieren, bildet jede untergeordnete VM eine Kette, in der neue Änderungen auf 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 wurden, führt die resultierende Kette zu Leistungseinbußen. Citrix Hypervisor unterstützt eine maximale Kettenlänge von 30. Nähern Sie sich dieser Grenze nicht ohne triftigen Grund. Im Zweifelsfall “kopieren” Sie die VM mit XenCenter oder verwenden Sie die vm-copy , der die Kettenlänge wieder auf 0 zurücksetzt.

VHD-spezifische Hinweise zur Koaleszenz

Für eine SR ist immer nur ein Koaleszenzprozess aktiv. Dieser Prozessthread wird auf dem SR-Masterhost ausgeführt.

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

• Migrieren der VM zu einem anderen Host als dem SR-Master

• Legen Sie die E/A-Priorität des Datenträgers auf eine höhere Stufe fest, und passen Sie den Scheduler an. Weitere Informationen finden Sie unter Priorisierung von E/A-Anforderungen für virtuelle Festplatten.