Speicher
Dieser Artikel beschreibt, wie physische Speicherhardware virtuellen Maschinen (VMs) zugeordnet wird und welche Softwareobjekte von XenServer® für speicherbezogene Aufgaben verwendet werden. Er enthält auch Informationen zu den verfügbaren Speichertypen, damit Sie die richtige Wahl für die in Ihrer Umgebung zu verwendende Speicherhardware treffen können.
Speicherkonzepte
Die folgende Abbildung zeigt, wie die in diesem Abschnitt beschriebenen Speicherobjekte miteinander in Beziehung stehen:
Speicher-Repositories (SRs)
Ein Speicher-Repository (SR) ist ein bestimmtes Speicherziel, in dem virtuelle Festplatten-Images (VDIs) von virtuellen Maschinen (VMs) gespeichert werden. Ein VDI ist eine Speicherabstraktion, die eine virtuelle Festplatte (HDD) darstellt. Informationen zu den von XenServer unterstützten SR-Typen finden Sie unter Speicher-Repository-Typen.
Die SR- und VDI-Abstraktionen ermöglichen die Bereitstellung erweiterter Speicherfunktionen auf Speicherzielen, die diese unterstützen. Zum Beispiel erweiterte Funktionen wie Thin Provisioning, VDI-Snapshots und schnelles Klonen. Für Speichersubsysteme, die erweiterte Operationen nicht direkt unterstützen, wird ein Software-Stack bereitgestellt, der diese Funktionen implementiert.
Ein Speicher-Repository ist eine persistente, auf der Festplatte befindliche Datenstruktur. Bei SR-Typen, die ein zugrunde liegendes Blockgerät verwenden, beinhaltet der Prozess der Erstellung eines SR das Löschen aller vorhandenen Daten auf dem angegebenen Speicherziel. Andere Speichertypen, wie z. B. NFS, erstellen einen Container auf dem Speicher-Array parallel zu bestehenden SRs.
Jeder XenServer-Host kann mehrere SRs und verschiedene SR-Typen gleichzeitig verwenden. Diese SRs können zwischen Hosts gemeinsam genutzt oder bestimmten Hosts zugewiesen werden. Gemeinsamer Speicher wird zwischen mehreren Hosts innerhalb eines definierten Ressourcenpools gepoolt. Ein gemeinsames SR muss für jeden Host im Pool über das Netzwerk zugänglich sein. Gemeinsamer Speicher kann nicht zwischen mehreren Pools geteilt werden.
SR-Befehle bieten Operationen zum Erstellen, Zerstören, Ändern der Größe, Klonen, Verbinden und Auffinden der einzelnen VDIs, die sie enthalten. CLI-Operationen zur Verwaltung von Speicher-Repositories werden unter SR-Befehle beschrieben.
Virtuelles Festplatten-Image (VDI)
Ein virtuelles Festplatten-Image (VDI) ist eine Speicherabstraktion, die eine virtuelle Festplatte (HDD) darstellt. VDIs sind die grundlegende Einheit des virtualisierten Speichers in XenServer. VDIs sind persistente, auf der Festplatte befindliche Objekte, die unabhängig von XenServer-Hosts existieren. Weitere Informationen zu den für virtuelle Festplatten auf XenServer unterstützten Datenformaten finden Sie unter Datenformate für virtuelle Festplatten.
CLI-Operationen zur Verwaltung von VDIs werden unter VDI-Befehle beschrieben. Die On-Disk-Darstellung der Daten unterscheidet sich je nach SR-Typ. Eine separate Speicher-Plug-in-Schnittstelle für jedes SR, die sogenannte SM-API, verwaltet die Daten.
Physische Blockgeräte (PBDs)
Physische Blockgeräte stellen die Schnittstelle zwischen einem physischen Server und einem angeschlossenen SR dar. PBDs sind Konnektorobjekte, die es ermöglichen, ein bestimmtes SR einem Host zuzuordnen. PBDs speichern die Gerätekonfigurationsfelder, die zum Verbinden mit und zur Interaktion mit einem bestimmten Speicherziel verwendet werden. Zum Beispiel umfasst die NFS-Gerätekonfiguration die IP-Adresse des NFS-Servers und den zugehörigen Pfad, den der XenServer-Host mountet. PBD-Objekte verwalten die Laufzeitverbindung eines bestimmten SR mit einem bestimmten XenServer-Host. CLI-Operationen bezüglich PBDs werden in PBD-Befehle beschrieben.
Virtuelle Blockgeräte (VBDs)
Virtuelle Blockgeräte sind Konnektorobjekte (ähnlich dem 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 der E/A-Priorität und Statistiken eines bestimmten VDI sowie die Frage, ob dieses VDI gebootet werden kann. CLI-Operationen bezüglich VBDs werden in VBD-Befehle beschrieben.
Speicher-Repository-Typen
XenServer unterstützt eine Reihe von Speichertypen für lokal und remote verbundene SRs.
Warnung:
XenServer unterstützt keine Snapshots auf SAN-Ebene eines LUN für irgendeinen SR-Typ.
Lokale SRs
Ein lokales Speicher-Repository (SR) ist mit einem einzelnen Host verbunden und wird nicht zwischen allen Hosts in einem Pool geteilt. Die lokale physische Speicherhardware kann eine Festplatte (HDD) oder ein Solid-State-Laufwerk (SSD) sein. Es kann über eine der folgenden Methoden mit dem Host verbunden werden: SATA, SCSI, SAS, NVMe.
XenServer-Hosts unterstützen die folgenden Typen von lokalem Speicher:
Remote-SRs
XenServer unterstützt remote verbundenen Speicher unter Verwendung der folgenden Laufwerke: iSCSI, NFS, SAS, SMB (nur Version 3), Fibre Channel.
Hinweis:
NVMe über Fibre Channel und NVMe über TCP werden nicht unterstützt.
Die folgenden extern verbundenen Speichertypen können verwendet werden, um freigegebene SRs für Ihren XenServer-Pool zu erstellen.
ISO-Bibliotheken:
Flie-basierter Speicher:
Blockbasierter Speicher:
Vergleich der freigegebenen Speichertypen
Die folgende Tabelle vergleicht die Funktionen der verschiedenen Speichertypen, die für freigegebene SRs unterstützt werden. Berücksichtigen Sie diese Funktionen bei der Auswahl Ihrer Speicherlösung.
| Dateibasiert (SMB/NFS) | Blockbasiert (iSCSI/HBA) LVM | Blockbasiert (iSCSI/HBA) GFS2 | |
|---|---|---|---|
| Virtueller Festplattentyp | VHD | VHD | QCOW2 |
| Maximale Anzahl virtueller Festplatten pro SR | 20000 | 1000 | 20000 |
| Maximale Größe virtueller Festplatten | 2.040 GiB | 2.040 GiB | 16 TiB |
| Maximale Poolgröße(/de-de/xenserver/9/hosts-pools#recommended-pool-size) | 32/64 | 32 | 16 |
| Unterstützte Funktionen | |||
| Speichermigration(/de-de/xenserver/9/vms/migrate) | Ja | Ja | Nein |
| Intellicache(/de-de/xenserver/9/storage/intellicache) | Ja | Ja | Nein |
| Lesecaching(/de-de/xenserver/9/storage/read-cache) | Ja | Nein | Ja |
| Thin Provisioning (siehe Hinweis) | Ja | Nein | Ja |
| Notfallwiederherstellung | Nein | Ja | Nein |
Hinweis:
Für blockbasierten LVM-Speicher können Sie Thin Provisioning im zugrunde liegenden SAN implementieren. Dies wird jedoch bei GFS2-SRs nicht empfohlen.
Datenformate virtueller Festplatten
Im Allgemeinen gibt es die folgenden Arten der Zuordnung von physischem Speicher zu einem VDI:
-
Logikvolumen-basiertes VHD auf einer LUN: Der standardmäßige blockbasierte XenServer-Speicher fügt einen logischen Volumenmanager auf einer Festplatte ein. Diese Festplatte ist entweder ein lokal angeschlossenes Gerät (LVM) oder eine über Fibre Channel, iSCSI oder SAS angeschlossene SAN-LUN. VDIs werden als Volumes innerhalb des Volumenmanagers dargestellt und im VHD-Format gespeichert, um Thin Provisioning von Referenzknoten bei Snapshot und Klon zu ermöglichen.
-
Dateibasiertes QCOW2 auf einer LUN: VM-Images werden als Thin-Provisioned-QCOW2-Formatdateien auf einem GFS2-Shared-Disk-Dateisystem auf einer LUN gespeichert, die entweder über einen iSCSI-Software-Initiator oder eine Hardware-HBA angeschlossen ist.
-
Dateibasiertes VHD auf einem Dateisystem: VM-Images werden als Thin-Provisioned-VHD-Formatdateien entweder auf einem lokalen, nicht freigegebenen Dateisystem (SR vom Typ EXT3/EXT4), einem freigegebenen NFS-Ziel (SR vom Typ NFS) oder einem Remote-SMB-Ziel (SR vom Typ SMB) gespeichert.
-
Dateibasiertes QCOW2 auf einem Dateisystem: VM-Images werden als Thin-Provisioned-QCOW2-Formatdateien auf einem lokalen, nicht freigegebenen XFS-Dateisystem gespeichert.
VDI-Typen
Für GFS2- und XFS-SRs werden QCOW2-VDIs erstellt.
Für andere SR-Typen werden VDIs im VHD-Format erstellt. Sie können optional die Verwendung von Raw zum Zeitpunkt der VDI-Erstellung wählen. Diese Option kann nur über die xe CLI angegeben werden.
Hinweis:
Wenn Sie eine Raw-VDI auf einem LVM-basierten SR oder einem HBA/LUN-pro-VDI-SR erstellen, könnte dies der besitzenden VM den Zugriff auf Daten ermöglichen, die Teil einer zuvor gelöschten VDI (jedes Formats) waren, die zu einer beliebigen VM gehörte. Wir empfehlen Ihnen, Ihre Sicherheitsanforderungen zu berücksichtigen, bevor Sie diese Option verwenden.
Raw-VDIs auf einem NFS-, EXT- oder SMB-SR erlauben keinen Zugriff auf die Daten zuvor gelöschter VDIs, die zu einer beliebigen VM gehören.
Um zu überprüfen, ob eine VDI mit type=raw erstellt wurde, überprüfen Sie ihre sm-config-Map. Die xe-Befehle sr-param-list und vdi-param-list können jeweils für diesen Zweck verwendet werden.
Erstellen eines Raw-Virtual-Disks mit der xe CLI
-
Führen Sie den folgenden Befehl aus, um eine VDI zu erstellen, wobei die UUID des SR angegeben wird, in dem 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--> -
Hängen Sie den neuen virtuellen Datenträger an eine VM an. Verwenden Sie die Datenträger-Tools innerhalb der VM zum Partitionieren und Formatieren oder verwenden Sie den neuen Datenträger anderweitig. Sie können den Befehl
vbd-createverwenden, um eine VBD zu erstellen, um den virtuellen Datenträger in Ihre VM einzubinden.
Konvertieren zwischen VDI-Formaten
Eine direkte Konvertierung zwischen den Raw- und VHD-Formaten ist nicht möglich. Stattdessen können Sie eine VDI erstellen (entweder Raw, wie oben beschrieben, oder VHD) und dann Daten aus einem vorhandenen Volume hineinkopieren. 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. Dies können Sie überprüfen, indem Sie das Feld virtual-size prüfen, zum Beispiel mit dem Befehl vdi-param-list. 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 standardmäßige Datenträgerverwaltungstools in Windows oder der Befehl dd in Linux. Wenn das neue Volume ein VHD-Volume ist, verwenden Sie ein Tool, das das Schreiben leerer Sektoren auf den Datenträger vermeiden kann. Diese Aktion kann sicherstellen, dass der Speicherplatz im zugrunde liegenden Speicher-Repository optimal genutzt wird. Ein dateibasiertes Kopierverfahren kann geeigneter sein.
VHD-basierte und QCOW2-basierte VDIs
VHD- und QCOW2-Images können verkettet werden, sodass zwei VDIs gemeinsame Daten nutzen können. Wenn eine VHD-basierte oder QCOW2-basierte VM geklont wird, teilen sich die resultierenden VMs die gemeinsamen Daten auf der Festplatte zum Zeitpunkt des Klonens. Jede VM nimmt dann ihre eigenen Änderungen in einer isolierten Copy-on-Write-Version des VDI vor. Diese Funktion ermöglicht es, solche VMs schnell aus Vorlagen zu klonen, was eine sehr schnelle Bereitstellung und Implementierung neuer VMs erleichtert.
Wenn VMs und ihre zugehörigen VDIs im Laufe der Zeit geklont werden, entstehen Bäume von verketteten VDIs. Wenn eines der VDIs in einer Kette gelöscht wird, rationalisiert XenServer die anderen VDIs in der Kette, um unnötige VDIs zu entfernen. Dieser Zusammenführungsprozess läuft asynchron ab. Die Menge des zurückgewonnenen Speicherplatzes und die Zeit, die für die Durchführung des Prozesses benötigt wird, hängen von der Größe des VDI und der Menge der gemeinsam genutzten Daten ab. Weitere Informationen finden Sie unter Hinweise zum Zusammenführen.
Sowohl das VHD- als auch das QCOW2-Format unterstützen Thin Provisioning. Die Image-Datei wird automatisch in feingranularen Blöcken erweitert, wenn die VM Daten auf die Festplatte schreibt. Bei dateibasierten VHDs und GFS2-basierten QCOW2 hat dieser Ansatz den erheblichen Vorteil, dass VM-Image-Dateien nur so viel Platz auf dem physischen Speicher belegen, wie tatsächlich benötigt wird. Bei LVM-basierten VHDs muss der zugrunde liegende logische Volume-Container auf die virtuelle Größe des VDI dimensioniert werden. Nicht genutzter Speicherplatz auf der zugrunde liegenden Copy-on-Write-Instanzfestplatte wird jedoch bei einem Snapshot oder Klon zurückgewonnen. Der Unterschied zwischen den beiden Verhaltensweisen kann wie folgt beschrieben werden:
-
Bei LVM-basierten VHD-Images verbrauchen die Differenz-Disk-Knoten innerhalb der Kette nur so viele Daten, wie auf die Festplatte geschrieben wurden. Die Blattknoten (VDI-Klone) bleiben jedoch vollständig auf die virtuelle Größe der Festplatte aufgebläht. Snapshot-Blattknoten (VDI-Snapshots) bleiben im Ruhezustand entleert und können schreibgeschützt angehängt werden, um die entleerte Zuweisung zu erhalten. Snapshot-Knoten, die im Lese-Schreib-Modus angehängt werden, werden beim Anhängen vollständig aufgebläht und beim Trennen entleert.
-
Bei dateibasierten VHDs und GFS2-basierten QCOW2-Images verbrauchen alle Knoten nur so viele Daten, wie geschrieben wurden. Die Blattknotendateien wachsen, um Daten aufzunehmen, während sie aktiv geschrieben werden. Wenn ein 100 GB VDI für eine VM zugewiesen und ein Betriebssystem installiert wird, entspricht die VDI-Datei physisch nur der Größe der Betriebssystemdaten auf der Festplatte, 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 in die neue VM geschrieben werden. Alte Blöcke werden direkt aus der übergeordneten Vorlage gelesen. Wenn die neue VM in eine weitere Vorlage umgewandelt und weitere VMs geklont werden, führt die resultierende Kette zu einer verminderten Leistung. XenServer 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 den Befehl vm-copy, der die Kettenlänge auf 0 zurücksetzt.
Hinweise zum Zusammenführen
Für einen SR ist immer nur ein Zusammenführungsprozess aktiv. Dieser Prozess-Thread läuft auf dem SR-Pool-Koordinator. Während der Zusammenführungsprozess aktiv ist, kann zusätzlicher Speicherplatz im SR erforderlich sein, um Daten aufzunehmen, die von einer Ebene des Delta-Baums in eine andere zusammengeführt werden. Nach diesem Prozess wird die redundante Ebene entfernt und Speicherplatz freigegeben.
Wenn Sie kritische VMs auf dem Pool-Koordinator ausführen, können Sie die folgenden Schritte unternehmen, um gelegentliche langsame E/A-Vorgänge zu mindern:
-
Migrieren Sie die VM auf einen anderen Host als den SR-Pool-Koordinator
-
Legen Sie die E/A-Priorität der Festplatte 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.