Speicher

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

  • Verfahren zum Erstellen von Speicher für VMs mithilfe der CLI mit typspezifischen Gerätekonfigurationsoptionen
  • Erstellen von Snapshots für Sicherungszwecke
  • Best Practices für die Speicherverwaltung
  • QoS-Einstellungen (Quality of Service) für virtuelle Laufwerke

Speicher-Repositories (SRs)

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

SRs sind flexibel, mit integrierter Unterstützung für die folgenden Laufwerke:

Lokal verbunden:

  • IDE
  • SATA
  • SCSI
  • SAS

Fernzugriff:

  • iSCSI
  • NFS
  • SAS
  • Fibre-Channel

Die SR- und VDI-Abstraktionen ermöglichen es, erweiterte Speicherfunktionen auf Speicherzielen verfügbar zu machen, 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.

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

Ein Speicher-Repository ist eine persistente Datenstruktur auf der Festplatte. Bei SR-Typen, die ein zugrunde liegendes Blockgerät verwenden, beinhaltet das Erstellen einer SR das Löschen aller vorhandenen Daten auf dem angegebenen Speicherziel. B. NFS, erstellen einen Container auf dem Speicher-Array parallel zu vorhandenen SRs.

Jeder Citrix Hypervisor or-Server kann mehrere SRs und verschiedene SR-Typen gleichzeitig verwenden. Diese SRs können zwischen Hosts geteilt oder für bestimmte Hosts dediziert werden. Gemeinsamer Speicher wird zwischen mehreren Hosts innerhalb eines definierten Ressourcenpools gepoolt. Ein gemeinsam genutzter SR muss für jeden Host im Pool auf das Netzwerk zugegriffen werden. Alle Server in einem einzelnen Ressourcenpool müssen mindestens eine gemeinsam genutzte SR haben. Gemeinsamer Speicher kann nicht zwischen mehreren Pools freigegeben werden.

CLI-Vorgänge zur Verwaltung von Speicher-Repositories werden unter beschriebenSR-Befehle.

Virtual Disk Image (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 der Festplatte, die unabhängig von Citrix Hypervisor or-Servern vorhanden sind. CLI-Vorgänge zur Verwaltung von VDIs werden unter beschriebenVDI-Befehle. Die Darstellung der Daten auf der Festplatte 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 angeschlossenen SR dar. PBDs sind Connectorobjekte, mit denen eine bestimmte SR einem Host zugeordnet werden kann. In PBDs werden die Gerätekonfigurationsfelder gespeichert, die für die Verbindung zu einem bestimmten Speicherziel und für die Interaktion mit diesen verwendet werden. Beispielsweise umfasst die NFS-Gerätekonfiguration die IP-Adresse des NFS-Servers und den zugeordneten Pfad, den der Citrix Hypervisor or-Server bereitstellt. PBD-Objekte verwalten die Laufzeitanhänge eines bestimmten SR an einen bestimmten Citrix Hypervisor or-Server. CLI-Vorgänge im Zusammenhang mit PBDs werden unter beschriebenPBD-Befehle.

Virtuelle Blockgeräte (VBDs)

Virtuelle Blockgeräte sind Connectorobjekte (ähnlich der oben beschriebenen PBD), die Zuordnungen zwischen VDIs und VMs ermöglichen. Neben der Bereitstellung eines Mechanismus für die Anbringung eines VDI an eine VM ermöglichen VBDs die Feinabstimmung von Parametern bezüglich QoS (Quality of Service) und Statistiken eines bestimmten VDI, und ob dieser VDI gestartet werden kann. CLI-Vorgänge im Zusammenhang mit VBDs werden unter beschriebenVBD-Befehle.

Zusammenfassung der Speicherobjekte

Das folgende Bild zeigt, wie die bisher präsentierten Speicherobjekte zusammenhängen:

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

Datenformate für virtuelle Laufwerke

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

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

  2. Dateibasiertes QCOW2 auf einer LUN: VM-Images werden als Thin-Provisioned-QCOW2-Formatdateien auf einem GFS2-Dateisystem mit freigegebenen Datenträgern auf einer LUN gespeichert, die entweder über iSCSI-Software-Initiator oder Hardware-HBA verbunden ist.

  3. Dateibasierte virtuelle Festplatte auf einem Dateisystem: VM-Images werden als Thin-Provisioned-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 VHD-Format-VDIs erstellt. Bei der Erstellung des VDI können Sie sich entscheiden, roh zu verwenden. Diese Option kann nur mit der XE CLI angegeben werden. Für GFS2 SRs werden QCOW2 VDIs erstellt.

Überprüfen Sie dietype=rawKarte, um zu überprüfensm-config, ob ein VDI mit erstellt wurde. Dazu können diesr-param-list Befehle bzw.vdi-param-list xe verwendet werden.

Erstellen eines virtuellen Rohdatenträgers mithilfe 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ägerwerkzeuge innerhalb der VM zum Partitionieren und Formatieren oder verwenden Sie den neuen Datenträger anderweitig. Sie können denvbd-create Befehl verwenden, um eine VBD zu erstellen, um das virtuelle Laufwerk Ihrer VM zuzuordnen.

Konvertieren zwischen VDI-Formaten

Eine direkte Konvertierung zwischen den Roh- und VHD-Formaten ist nicht möglich. Stattdessen können Sie einen VDI (entweder roh, wie oben beschrieben, oder VHD) erstellen 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, aus dem Sie kopieren. Sie können dies tun, indem Sie dasvirtual-size Feld überprüfen, z. B. mit demvdi-param-list Befehl. 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 derdd Befehl in Linux. Wenn es sich bei dem neuen Volume um ein VHD-Volume handelt, verwenden Sie ein Tool, mit dem Sie vermeiden können, leere Sektoren auf den Datenträger zu schreiben. Diese Aktion kann sicherstellen, dass 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 verkettetwerden, wodurch zwei VDIs gemeinsame Daten gemeinsam nutzen können. In Fällen, in denen eine VHD-gestützte oder QCOW2-gestützte VM geklont wird, verwenden die resultierenden VMs die gemeinsamen Daten auf der Festplatte zum Zeitpunkt des Klonens. 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 dadurch Bäume von verketteten VDIs erstellt. Wenn eine 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. Die Menge des zurückgeforderten Festplattenspeichers und die Zeit, die für die Ausführung des Prozesses benötigt wird, hängt von der Größe des VDI und der Menge der freigegebenen Daten ab.

Sowohl das VHD- als auch das QCOW2-Format unterstützen Thin Provisioning. Die Image-Datei wird automatisch in fein granularen 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-Imagedateien 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. Ungenutzter Speicherplatz auf dem zugrunde liegenden Kopier-on-Write-Instanzdatenträger wird jedoch wiederhergestellt, 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 der Festplatte aufgeblasen. Snapshot-Blattknoten (VDI-Snapshots) bleiben deflationiert, wenn sie nicht verwendet werden, und können schreibgeschützt angehängt werden, um die deflationierte Zuweisung beizubehalten. Snapshot-Knoten, die mit Read-Write verbunden sind, werden beim Anhängen vollständig aufgeblasen und beim Trennen deflationiert.

  • Bei dateibasierten VHDs und GFS2-basierten QCOW2-Images verbrauchen alle Knoten nur so viele Daten wie geschrieben. Die Blattknotendateien wachsen, um Daten aufzunehmen, während sie aktiv geschrieben werden. Wenn ein VDI mit 100 GB 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 und einigen geringfügigen Metadaten-Overhead.

Beim Klonen von VMs basierend auf einer einzelnen VHD- oder QCOW2-Vorlage 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 wurde und mehr VMs geklont wurden, führt die resultierende Kette zu einer Leistungsverschlechterung. Citrix Hypervisor unterstützt eine maximale Kettenlänge von 30. Nähern Sie sich diesem Limit nicht ohne guten Grund. Wenn Sie Zweifel haben, „kopieren“ Sie die VM mit XenCenter oder verwenden Sie denvm-copy Befehl, der die Kettenlänge auf 0 zurücksetzt.

VHD-spezifische Hinweise zur Koalesz

Für eine SR ist je nur ein Koaleszenzprozess aktiv. Dieser Prozess-Thread 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-Vorgänge zu minimieren:

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

  • Legen Sie die 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 Laufwerke.