Speicher
In diesem Abschnitt wird beschrieben, wie physische Speicherhardware virtuellen Maschinen (VMs) zugeordnet wird und welche Softwareobjekte von der Verwaltungs-API zur Ausführung speicherbezogener Aufgaben verwendet werden. Ausführliche Abschnitte zu jedem der unterstützten Speichertypen enthalten die folgenden Informationen:
- Verfahren zum Erstellen von Speicher für VMs über die CLI mit typspezifischen Gerätekonfigurationsoptionen
- Generieren von Snapshots für Backup-Zwecke
- Best Practices für die Verwaltung von Speicher
Speicherrepositories (SRs)
Ein Speicherrepository (SR) ist ein bestimmtes Speicherziel, in dem Virtual Machine (VM) Virtual Disk Images (VDIs) gespeichert sind. Ein VDI ist eine Speicherabstraktion, die ein virtuelles Datenträgerlaufwerk (HDD) darstellt.
SRs sind flexibel, mit integrierter Unterstützung für die folgenden Laufwerke:
Lokal verbunden:
- SATA
- SCSI
- SAS
- NVMe
Die lokale physische Speicherhardware darf ein Datenträgerlaufwerk (HDD) oder ein Solid-State-Laufwerk (SSD) sein.
Remote-Verbindung:
- iSCSI
- NFS
- SAS
- SMB (nur Version 3)
- Fibre-Channel
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 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.
Ein Speicherrepository ist eine persistente Datenstruktur auf dem Datenträger. Bei SR-Typen, die ein zugrunde liegendes Blockgerät verwenden, werden beim Erstellen eines SRs alle vorhandenen Daten auf dem angegebenen Speicherziel gelöscht. Andere Speichertypen wie NFS erstellen parallel zu vorhandenen SRs einen Container auf dem Speicher-Array.
Jeder XenServer-Host kann mehrere SRs und verschiedene SR-Typen gleichzeitig verwenden. Diese SRs können zwischen Hosts geteilt oder für bestimmte Hosts reserviert werden. Gemeinsam genutzter Speicher wird zwischen mehreren Hosts innerhalb eines definierten Ressourcenpools gepoolt. Ein gemeinsam genutztes SR muss für jeden Host im Pool über das Netzwerk zugänglich sein. Alle Hosts in einem einzigen Ressourcenpool müssen mindestens eine gemeinsam genutzte SR haben. Gemeinsam genutzter 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 Erkennen der einzelnen VDIs, die sie enthalten. CLI-Vorgänge zum Verwalten von Speicherrepositories sind in SR-Befehlen beschrieben.
Warnung:
XenServer unterstützt für keinen SR-Typ Snapshots auf der externen SAN-Ebene einer LUN.
Virtuelles Disk-Image (VDI)
Ein Virtual Disk-Image (VDI) ist eine Speicherabstraktion, die ein virtuelles Datenträgerlaufwerk (HDD) darstellt. VDIs sind die grundlegende Einheit des virtualisierten Speichers in XenServer. VDIs sind persistente Objekte auf der Datenträger, die unabhängig von XenServer-Hosts existieren. CLI-Vorgänge zur Verwaltung von VDIs sind in VDI-Befehlenbeschrieben. Die Darstellung der Daten auf dem Datenträger unterscheidet sich je nach SR-Typ. Eine separate Speicher-Plug-In-Schnittstelle für jedes SR, die SM-API genannt wird, verwaltet die Daten.
Physische Blockgeräte (PBDs)
Physische Blockgeräte stellen die Schnittstelle zwischen einem physischen Server und einem angeschlossenen SR dar. PBDs sind Connectorobjekte, mit denen ein bestimmtes SR einem Host zugeordnet werden kann. PBDs speichern die Gerätekonfigurationsfelder, die verwendet werden, um eine Verbindung zu einem bestimmten Speicherziel herzustellen und mit diesem zu interagieren. Die NFS-Gerätekonfiguration umfasst beispielsweise die IP-Adresse des NFS-Servers und den zugehörigen Pfad, den der XenServer-Host bereitstellt. PBD-Objekte verwalten die Laufzeitanhänge einer bestimmten SR an einen bestimmten XenServer-Host. CLI-Operationen in Bezug auf PBDs werden in PBD-Befehlenbeschrieben.
Virtuelle Blockgeräte (VBDs)
Virtuelle Blockgeräte sind Connector-Objekte (ähnlich der oben beschriebenen PBD), die Zuordnungen zwischen VDIs und VMs ermöglichen. VBDs bieten nicht nur einen Mechanismus zum Anhängen eines VDI an eine VM, sondern ermöglichen auch die Feinabstimmung von Parametern in Bezug auf die Datenträger-I/O-Priorität und die Statistiken eines bestimmten VDI sowie die Frage, ob dieser VDI gestartet werden kann. CLI-Operationen in Bezug auf VBDs werden in VBD-Befehlenbeschrieben.
Zusammenfassung der Speicherobjekte
Das folgende Bild ist eine Zusammenfassung der Beziehung der bisher dargestellten Speicherobjekte:
Datenformate virtueller Datenträger
Im Allgemeinen gibt es die folgenden Arten der Zuordnung von physischem Speicher zu einem VDI:
-
Logische volumebasierte virtuelle Datenträger auf einer LUN: Der standardmäßige blockbasierte XenServer-Speicher fügt einen logischen Volume-Manager auf einer Datenträger ein. Dieser Datenträger ist entweder ein lokal angeschlossenes Gerät (LVM) oder eine an das SAN angeschlossene LUN über Fibre Channel, iSCSI oder SAS. VDIs werden im Volume Manager als Volumes dargestellt und im VHD-Format gespeichert, um die Thin-Bereitstellung von Referenzknoten auf Snapshot und Klon zu ermöglichen.
-
Dateibasiertes QCOW2 auf einer LUN: VM-Images werden als Thin-Provisioning-Dateien im QCOW2-Format auf einem gemeinsam genutzten GFS2-Datenträgerdateisystem auf einer LUN gespeichert, die entweder über iSCSI-Softwareinitiator oder Hardware-HBA angeschlossen ist.
-
Dateibasierte VHD auf einem Dateisystem: VM-Images werden als Thin-Provisioning-Dateien im VHD-Format entweder in einem lokalen, nicht gemeinsam genutzten Dateisystem (EXT3/EXT4-SR), einem gemeinsam genutzten NFS-Ziel (NFS-SR) oder einem Remote-SMB-Ziel (SMB-SR) gespeichert.
-
Dateibasiertes QCOW2 auf einem Dateisystem: VM-Images werden als Thin-Provision-Dateien im QCOW2-Format auf einem lokalen, nicht gemeinsam genutzten 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 zum Zeitpunkt des Erstellens des VDI die Option “Raw” verwenden. Diese Option kann nur mit der xe CLI angegeben werden.
Hinweis:
Wenn Sie einen Roh-VDI auf einem LVM-basierten SR oder HBA/LUN-per-VDI SR erstellen, kann die besitzende VM möglicherweise auf Daten zugreifen, die Teil eines zuvor gelöschten VDI (jedes Formats) waren, der zu einer beliebigen VM gehört. Wir empfehlen Ihnen, Ihre Sicherheitsanforderungen zu berücksichtigen, bevor Sie diese Option verwenden.
Raw-VDIs auf einem NFS-, EXT- oder SMB SR ermöglichen keinen Zugriff auf die Daten zuvor gelöschter VDIs, die zu einer VM gehören.
Um zu überprüfen, ob ein VDI mit type=raw erstellt wurde, überprüfen Sie seine sm-config-Zuordnung. Die xe-Befehle sr-param-list und vdi-param-list können jeweils für diesen Zweck verwendet werden.
Erstellen eines virtuellen Rohdatenträgers über die xe CLI
-
Führen Sie den folgenden Befehl aus, um einen VDI mit der UUID des SRs zu erstellen, in dem Sie das virtuelle Laufwerk 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 das neue virtuelle Laufwerk an eine VM an. Verwenden Sie die Datenträger-Tools innerhalb der VM zum Partitionieren und Formatieren oder verwenden Sie die neue Datenträger auf andere Weise. Sie können den Befehl
vbd-createverwenden, um ein VBD zu erstellen, um den virtuellen Datenträger Ihrer VM zuzuordnen.
Zwischen VDI-Formaten konvertieren
Es ist nicht möglich, eine direkte Konvertierung zwischen den Raw- und VHD-Formaten durchzuführen. Stattdessen können Sie einen VDI erstellen (entweder roh, wie oben beschrieben, oder VHD) und dann Daten von einem vorhandenen Volume hinein 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 entsprechende Feld virtual-size überprüfen, z. B. mit dem Befehl vdi-param-list. Sie können diesen neuen VDI dann 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 das neue Volume ein VHD-Volume ist, verwenden Sie ein Tool, mit dem Sie vermeiden können, leere Sektoren auf den Datenträger zu schreiben. Durch diese Aktion kann sichergestellt werden, dass der Speicherplatz im zugrunde liegenden Speicherrepository optimal genutzt wird. Ein dateibasierter Kopieransatz ist möglicherweise besser geeignet.
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- oder QCow2-unterstü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 des 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 ihre zugehörigen VDIs im Laufe der Zeit geklont werden, werden Bäume verketteter VDIs erstellt. Wenn einer der VDIs in einer Kette gelöscht wird, rationalisiert XenServer die anderen VDIs in der Kette, um nicht benötigte VDIs zu entfernen. Dieser Koaleszenzprozess läuft asynchron. Die Menge des zurückgewonnenen Datenträgerspeichers und die für die Ausführung des Vorgangs benötigte Zeit hängen von der Größe des VDI und der Menge der gemeinsam genutzten Daten ab.
Sowohl das VHD- als auch das QCOW2-Format unterstützen Thin Provisioning. Die Imagedatei wird automatisch in feinkörnigen Chunks erweitert, während die VM Daten auf den Datenträger schreibt. Bei dateibasierter VHD und GFS2-basierter QCOW2 hat dieser Ansatz den erheblichen Vorteil, dass VM-Image-Dateien nur so viel Speicherplatz auf dem physischen Speicher beanspruchen, wie erforderlich. Bei LVM-basierter VHD muss der zugrunde liegende logische Volume-Container auf die virtuelle Größe des VDI angepasst sein. Nicht genutzter Speicherplatz auf der zugrunde liegenden Copy-on-Write-Instanzdatenträger wird jedoch zurückgewonnen, wenn ein Snapshot oder Klon auftritt Der Unterschied zwischen den beiden Verhaltensweisen kann auf folgende Weise beschrieben werden:
-
Bei LVM-basierten VHD-Images verbrauchen die unterschiedlichen Datenträgerknoten innerhalb der Kette nur so viele Daten, wie auf den Datenträger geschrieben wurden. Die Blattknoten (VDI-Klone) bleiben jedoch vollständig auf die virtuelle Größe der Datenträger vergrößert. Snapshot-Blattknoten (VDI-Snapshots) bleiben ungebunden, wenn sie nicht verwendet werden, und können schreibgeschützt angehängt werden, um die verkleinerte Zuweisung beizubehalten. Snapshot-Knoten, die mit Lese-/Schreibzugriff verbunden sind, werden beim Anhängen vollständig aufgeblasen und beim Trennen entleert.
-
Bei dateibasierten VHDs und GFS2-basierten QCOW2-Images verbrauchen alle Knoten nur so viele Daten, wie geschrieben wurde. Die Blattknotendateien werden erweitert, um Daten aufzunehmen, während sie aktiv geschrieben werden. Wenn ein 100-GB-VDI für eine VM zugewiesen wird und ein Betriebssystem installiert ist, entspricht die VDI-Datei physisch nur der Größe der Betriebssystemdaten auf dem Datenträger sowie einigen kleineren 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 umgewandelt wurde und mehr VMs geklont wurden, führt die resultierende Kette zu einer Leistungsminderung. XenServer 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, der die Kettenlänge auf 0 zurücksetzt.
VHD-spezifische Hinweise zur Koaleszenz
Für ein SR ist immer nur ein Koaleszenzprozess aktiv. Dieser Prozessthread läuft auf dem SR-Poolkoordinator.
Wenn auf dem Poolkoordinator kritische VMs ausgeführt werden, können Sie die folgenden Schritte ergreifen, um gelegentliche langsame I/O-Vorgänge zu vermeiden:
-
Migrieren Sie die VM auf einen anderen Host als den SR- Poolkoordinator
-
Stellen Sie die Datenträger-E/A-Priorität auf eine höhere Ebene und passen Sie den Scheduler an Weitere Informationen finden Sie unter Priorisierung von I/O-Anforderungen für virtuelle Datenträger.