Citrix Hypervisor

Thin Provisioning gemeinsam genutzter GFS2-Blockspeicher

Beim Thin Provisioning wird der verfügbare Speicher besser genutzt, indem VDIs Datenträgerspeicherplatz zugewiesen wird, während die Daten auf das virtuelle Laufwerk geschrieben werden, anstatt die volle virtuelle Größe des VDI im Voraus zuzuweisen. Thin Provisioning ermöglicht es Ihnen, den auf einem gemeinsam genutzten Speicher-Array benötigten Speicherplatz und damit Ihre Gesamtbetriebskosten (TCO) erheblich zu reduzieren.

Thin Provisioning für gemeinsam genutzten Blockspeicher ist in den folgenden Fällen von besonderem Interesse:

  • Sie möchten eine höhere Raumeffizienz. Images werden dünn und nicht dick zugeordnet.
  • Sie möchten die Anzahl der I/O-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. Der GFS2 SR ist der erste SR-Typ, der das Speicherlesecaching auf gemeinsam genutztem Blockspeicher unterstützt.
  • Sie verwenden ein allgemeines Basisimage für mehrere virtuelle Maschinen. Die Images einzelner VMs benötigen dann in der Regel noch weniger Speicherplatz.
  • Sie verwenden Schnappschüsse. Jeder Snapshot ist ein Image, und jedes Image ist jetzt spärlich.
  • Ihr Speicher unterstützt kein NFS und unterstützt nur Blockspeicher. Wenn Ihr Speicher NFS unterstützt, empfehlen wir Ihnen, NFS anstelle von GFS2 zu verwenden.
  • Sie möchten VDIs erstellen, die größer als 2 TiB sind. Der GFS2 SR unterstützt VDIs mit einer Größe von bis zu 16 TiB.

Der gemeinsam genutzte GFS2-Typ stellt Datenträger als Dateisystem dar, das auf einer iSCSI- oder HBA-LUN erstellt wurde. VDIs, die auf einem GFS2 SR gespeichert sind, werden im QCOW2-Imageformat gespeichert.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

  • Alle Citrix Hypervisor-Server im Clusterpool müssen über mindestens 2 GiB Kontrolldomänenspeicher verfügen.

  • Alle Hosts im Cluster müssen statische IP-Adressen für das Cluster-Netzwerk verwenden.

  • Es wird empfohlen, Clustering nur in Pools mit mindestens drei Hosts zu verwenden, da Pools von zwei Hosts empfindlich auf das Selbst-Fencing des gesamten Pools reagieren.

  • Wenn Sie eine Firewall zwischen den Hosts in Ihrem Pool haben, stellen Sie sicher, dass Hosts über die folgenden Ports im Cluster-Netzwerk kommunizieren können:
    • TCP: 8892, 21064
    • UDP: 5404, 5405

    Weitere Informationen finden Sie unter Kommunikationsports, die von Citrix Technologien verwendet werden.

  • Wenn Sie einen vorhandenen Pool clustern, stellen Sie sicher, dass die Hochverfügbarkeit deaktiviert ist. Sie können die Hochverfügbarkeit erneut aktivieren, nachdem das Clustering aktiviert wurde.

  • Wir empfehlen dringend, dass Sie für Ihren Clusterpool ein gebundenes Netzwerk verwenden, das nicht für anderen Datenverkehr verwendet wird.

  • Sie haben ein blockbasiertes Speichergerät, das für alle Citrix Hypervisor-Server im Ressourcenpool sichtbar ist.

Richten Sie einen Clusterpool ein, um eine gemeinsam genutzte GFS2 SR zu verwenden

Um gemeinsam genutzten GFS2-Speicher zu verwenden, muss der Citrix Hypervisor Ressourcenpool ein Clusterpool sein. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie eine GFS2 SR erstellen.

Hinweis:

Cluster-Pools verhalten sich anders als Pools ohne Cluster. Weitere Informationen zum Verhalten von Clustern finden Sie unter Clustered-Pools.

Wenn Sie möchten, können Sie mit XenCenter Clustering in Ihrem Pool einrichten. Weitere Informationen finden Sie in der XenCenter-Produktdokumentation.

So verwenden Sie die xe CLI zum Erstellen eines Clusterpool:

  1. Erstellen Sie ein gebundenes Netzwerk, das als Clusternetzwerk verwendet werden kann.

    Hinweis:

    Wir empfehlen dringend, ein dediziertes gebundenes Netzwerk für Ihren Clusterpool zu verwenden. Verwenden Sie dieses Netzwerk nicht für anderen Datenverkehr.

    Führen Sie auf dem Citrix Hypervisor-Server, der der Poolmaster sein soll, die folgenden Schritte aus:

    1. Öffnen Sie eine Konsole auf dem Citrix Hypervisor-Server.

    2. Benennen Sie Ihren Ressourcenpool mit dem folgenden Befehl:

      xe pool-param-set name-label="New Pool" uuid=<pool_uuid>
      
    3. Erstellen Sie ein Netzwerk zur Verwendung mit der gebundenen NIC, indem Sie den folgenden Befehl verwenden:

      xe network-create name-label=bond0
      

      Die UUID des neuen Netzwerks wird zurückgegeben.

    4. Suchen Sie die UUIDs der PIFs, die in der Bindung verwendet werden sollen, indem Sie den folgenden Befehl verwenden:

      xe pif-list
      
    5. Erstellen Sie Ihr gebundenes Netzwerk entweder im aktiv-aktiven Modus, im aktiv-passiven Modus oder im LACP-Bond-Modus. Führen Sie je nach dem Bond-Modus, den Sie verwenden möchten, eine der folgenden Aktionen aus:

      • Um die Bindung im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie den Befehl bond-create, um die Bindung zu erstellen. Trennen Sie die Parameter durch Kommas und geben Sie die neu erstellte Netzwerk-UUID und die UUIDs der zu verbindenden PIFs an:

         xe bond-create network-uuid=<network_uuid> /
              pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
        

        Geben Sie zwei UUIDs ein, wenn Sie zwei NICs und vier UUIDs verbinden, wenn Sie vier Netzwerkkarten verbinden. Die UUID für die Bindung wird nach Ausführung des Befehls zurückgegeben.

      • Um die Bindung im Aktiv-Passiv- oder LACP-Bond-Modus zu konfigurieren, verwenden Sie dieselbe Syntax, fügen Sie den optionalen Parameter mode hinzu und geben Sie lacp oder active-backup an:

         xe bond-create network-uuid=<network_uuid> pif-uuids=<pif_uuid_1>, /
              <pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
              mode=balance-slb | active-backup | lacp
        

    Nachdem Sie Ihr gebundenes Netzwerk auf dem Poolmaster erstellt haben und andere Citrix Hypervisor-Server mit dem Pool verbinden, werden die Netzwerk- und Bindungsinformationen automatisch auf den beitretenden Server repliziert.

    Weitere Informationen finden Sie unter Netzwerk.

  2. Erstellen Sie einen Ressourcenpool mit mindestens drei Citrix Hypervisor-Servern.

    Wiederholen Sie die folgenden Schritte auf jedem Citrix Hypervisor-Server, der ein (Nicht-Master-) Poolmitglied ist:

    1. Öffnen Sie eine Konsole auf dem Citrix Hypervisor-Server.
    2. Verbinden Sie den Citrix Hypervisor-Server mit dem Pool auf dem Poolmaster, indem Sie den folgenden Befehl verwenden:

      xe pool-join master-address=master_address master-username=administrators_username master-password=password
      

      Der Wert des Parameters master-address muss auf den vollqualifizierten Domänennamen des Citrix Hypervisor-Servers festgelegt werden, der der Poolmaster ist. password muss das Administratorkennwort sein, das bei der Installation des Poolmasters festgelegt wurde.

    Weitere Informationen finden Sie unter Hosts und Ressourcenpools.

  3. Stellen Sie für jedes PIF, das zu diesem Netzwerk gehört, ein disallow-unplug=true.

    1. Suchen Sie die UUIDs der PIFs, die zum Netzwerk gehören, indem Sie den folgenden Befehl verwenden:

      xe pif-list
      
    2. Führen Sie den folgenden Befehl auf einem Citrix Hypervisor-Server in Ihrem Ressourcenpool aus:

      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      
  4. Aktivieren Sie das Clustering in Ihrem Pool. Führen Sie den folgenden Befehl auf einem Citrix Hypervisor-Server in Ihrem Ressourcenpool aus:

    xe cluster-pool-create network-uuid=<network_uuid>
    

    Geben Sie die UUID des gebundenen Netzwerks an, das Sie in einem früheren Schritt erstellt haben.

Stellen Sie sicher, dass Storage-Multipathing zwischen Ihrem Cluster-Pool und Ihrem GFS2 SR eingerichtet ist. Weitere Informationen finden Sie unter Speicher-Multipathing.

Erstellen einer gemeinsam genutzten GFS2 SR

Sie können Ihre gemeinsam genutzte GFS2 SR auf einer iSCSI- oder HBA-LUN erstellen.

Erstellen eines gemeinsam genutzten GFS2 über iSCSI SR

Sie können GFS2 über iSCSI-SRs mit XenCenter erstellen. Weitere Informationen finden Sie unter Software-iSCSI-Speicher in der XenCenter-Produktdokumentation .

Alternativ können Sie die xe CLI verwenden, um ein GFS2 über iSCSI SR zu erstellen.

Gerätekonfigurationsparameter für GFS2-SRs:

Parametername Beschreibung Erforderlich?
provider Die Blockanbieter-Implementierung. In diesem Fall, iscsi. Ja
target Die IP-Adresse oder der Hostname des iSCSI-Filers, der hostet Ja
targetIQN Das IQN-Ziel des iSCSI-Filers, der das SR hostet Ja
SCSIid SCSI-ID des Geräts Ja

Sie können die für diese Parameter zu verwendenden Werte mit dem Befehl xe sr-probe-ext finden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Führen Sie zunächst den folgenden Befehl aus:

    xe sr-probe-ext type=gfs2 device-config:provider=iscsi
    

    Die Ausgabe des Befehls fordert Sie auf, zusätzliche Parameter anzugeben, und enthält bei jedem Schritt eine Liste möglicher Werte.

  2. Wiederholen Sie den Befehl und fügen Sie jedes Mal neue Parameter hinzu.

  3. Wenn die Befehlsausgabe mit The following SRs were found: beginnt, können Sie die von Ihnen angegebenen Parameter device-config verwenden, um das SR beim Ausführen des Befehls xe sr-create zu finden.

Um ein gemeinsam genutztes GFS2-SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Clusterpool aus:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
   device-config:provider=iscsi device-config:targetIQN=target_iqns \
   device-config:target=portal_address device-config:SCSIid=scsci_id

Wenn das iSCSI-Ziel nicht erreichbar ist, während GFS2-Dateisysteme eingehängt sind, können einige Hosts im Clusterpool einen Fence durchführen.

Weitere Informationen zum Arbeiten mit iSCSI SRs finden Sie unter Software-iSCSI-Unterstützung.

Erstellen eines gemeinsam genutzten GFS2 über HBA SR

Sie können GFS2 über HBA-SRs erstellen, indem Sie XenCenter verwenden. Weitere Informationen finden Sie unter Hardware-HBA-Speicher in der XenCenter-Produktdokumentation.

Alternativ können Sie die xe CLI verwenden, um ein GFS2 über HBA SR zu erstellen.

Gerätekonfigurationsparameter für GFS2-SRs:

Name des Parameters Beschreibung Erforderlich?
provider Die Blockanbieter-Implementierung. In diesem Fall, hba. Ja
SCSIid SCSI-ID des Geräts Ja

Sie können die für den SCSIid-Parameter zu verwendenden Werte mit dem Befehl xe sr-probe-ext finden.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. Führen Sie zunächst den folgenden Befehl aus:

    xe sr-probe-ext type=gfs2 device-config:provider=hba
    

    Die Ausgabe des Befehls fordert Sie auf, zusätzliche Parameter anzugeben, und enthält bei jedem Schritt eine Liste möglicher Werte.

  2. Wiederholen Sie den Befehl und fügen Sie jedes Mal neue Parameter hinzu.

  3. Wenn die Befehlsausgabe mit The following SRs were found: beginnt, können Sie die von Ihnen angegebenen Parameter device-config verwenden, um das SR beim Ausführen des Befehls xe sr-create zu finden.

Um ein gemeinsam genutztes GFS2-SR auf einer bestimmten LUN eines HBA-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem Clusterpool aus:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
  device-config:provider=hba device-config:SCSIid=device_scsi_id

Weitere Informationen zum Arbeiten mit HBA-SRs finden Sie unter Hardware-Hostbusadapter.

Einschränkungen

Gemeinsam genutzter GFS2-Speicher weist derzeit die folgenden Einschränkungen auf:

  • Wie bei jeder Thin-Provisioning-SR schlagen weitere Schreibvorgänge von VMs fehl, wenn die GFS2 SR-Nutzung auf 100% ansteigt. Diese fehlgeschlagenen Schreibvorgänge können dann zu Fehlern innerhalb der VM oder zu einer möglichen Datenbeschädigung oder beidem führen.

  • XenCenter zeigt eine Warnung an, wenn Ihre SR-Auslastung auf 80% ansteigt. Stellen Sie sicher, dass Sie Ihren GFS2 SR auf diese Warnung überwachen und gegebenenfalls die entsprechenden Maßnahmen ergreifen. Bei einem GFS2 SR führt eine hohe Auslastung zu einer Leistungsverschlechterung. Wir empfehlen, dass Sie Ihre SR-Nutzung unter 80% halten.

  • VM-Migration mit Speichermigration (live oder offline) wird für VMs, deren VDIs sich auf einem GFS2-SR befinden, nicht unterstützt. Sie können auch keine VDIs von einem anderen SR-Typ auf eine GFS2 SR migrieren.

  • Der FCoE-Transport wird mit GFS2-SRs nicht unterstützt.

  • Trim/Unmap wird auf GFS2 SRs nicht unterstützt.

  • CHAP wird auf GFS2 SRs nicht unterstützt.

  • MCS-Vollklon-VMs werden mit GFS2 SRs nicht unterstützt.

  • Die Verwendung mehrerer GFS2 SRs im selben MCS-Katalog wird nicht unterstützt.

  • Leistungsmetriken sind für GFS2 SRs und Datenträger auf diesen SRs nicht verfügbar.

  • Die geänderte Blockverfolgung wird für VDIs, die auf GFS2 SRs gespeichert sind, nicht unterstützt.

  • Sie können VDIs, die größer als 2 TiB sind, nicht als VHD oder OVA/OVF exportieren. Sie können jedoch VMs mit VDIs, die größer als 2 TiB sind, im XVA-Format exportieren.

  • Wir empfehlen nicht, eine Thin Provisioning-LUN mit GFS2 zu verwenden. Wenn Sie diese Konfiguration wählen, müssen Sie jedoch sicherstellen, dass die LUN immer über genügend Speicherplatz verfügt, damit Citrix Hypervisor darauf schreiben kann.

  • Sie können nicht mehr als 62 GFS2 SRs in Ihrem Pool haben.

  • Clusterpools unterstützen nur bis zu 16 Hosts pro Pool.
  • Für den Cluster-Verkehr müssen Sie ein gebundenes Netzwerk verwenden, das mindestens zwei verschiedene Netzwerk-Switches verwendet. Verwenden Sie dieses Netzwerk nicht für andere Zwecke.
  • Um die IP-Adresse des Cluster-Netzwerks mithilfe von XenCenter zu ändern, müssen Clustering und GFS2 vorübergehend deaktiviert werden.
  • Ändern Sie nicht die Bindung Ihres Clusternetzwerks, während der Cluster aktiv ist und über laufende VMs verfügt. Diese Aktion kann zum Fence des Clusters führen.
  • Wenn Sie in Ihrem Clusternetzwerk einen IP-Adresskonflikt (mehrere Hosts mit derselben IP-Adresse) haben, an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, werden die Hosts nicht eingezäunt. Um dieses Problem zu beheben, lösen Sie den IP-Adresskonflikt.
Thin Provisioning gemeinsam genutzter GFS2-Blockspeicher