Thin-Provisioning-Shared-GFS2-Blockspeicher

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.

Beim Thin Provisioning wird der verfügbare Speicher besser genutzt, indem den VDIs beim Schreiben von Daten auf die virtuelle Festplatte Speicherplatz zugewiesen wird, anstatt die volle virtuelle Größe der VDI im Voraus zuzuweisen. Thin Provisioning ermöglicht es Ihnen, den Speicherplatzbedarf auf einem gemeinsam genutzten Speicher-Array und damit Ihre Gesamtbetriebskosten (TCO) erheblich zu reduzieren.

Thin Provisioning für Shared Block Storage ist in folgenden Fällen besonders interessant:

• Sie möchten die Flächeneffizienz steigern. Die Bilder sind spärlich und nicht dick zugeordnet.
• Sie möchten die Anzahl der E/A-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. Der GFS2 SR ist der erste SR-Typ, der Storage Read Caching auf gemeinsam genutztem Blockspeicher unterstützt.
• Sie verwenden ein gemeinsames Basisimage für mehrere virtuelle Maschinen. Die Images einzelner VMs belegen dann in der Regel noch weniger Speicherplatz.
• Sie verwenden Snapshots. Jeder Snapshot ist ein Image, und jedes Image ist jetzt spärlich.
• 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.
• Ihr Speicher unterstützt weder NFS noch SMB3 und nur Blockspeicher. Wenn Ihr Speicher NFS oder SMB3 unterstützt, empfehlen wir, diese SR-Typen anstelle von GFS2 zu verwenden.
• Ihr Speicher unterstützt kein Thin Provisioning von LUNs. Wenn Ihr Speicher Thin Provisioning-LUNs ausstattet, können bei der Kombination mit GFS2 Probleme auftreten und der Speicherplatz knapp wird. Die Kombination von GFS2 mit einer Thin-Provisioning-LUN bietet nicht viele zusätzliche Vorteile und wird nicht empfohlen.

Hinweis:

Es wird empfohlen, eine GFS2-SR nicht mit einem VLAN zu verwenden, da ein bekanntes Problem auftritt, bei dem Sie Hosts in einem Cluster-Pool nicht hinzufügen oder entfernen können, wenn sich das Cluster-Netzwerk in einem Nicht-Management-VLAN befindet.

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

In diesem Artikel wird beschrieben, wie Sie Ihre GFS2-Umgebung mithilfe der xe CLI einrichten. Informationen zum Einrichten einer GFS2-Umgebung mit XenCenter finden Sie unter die XenCenter-Produktdokumentation.

1. Planen Sie Ihre GFS2-Umgebung

Um die Vorteile von Thin Provisioning auf gemeinsam genutztem Blockspeicher ohne das Risiko von Datenverlusten nutzen zu können, muss Ihr Pool ein hohes Maß an Zuverlässigkeit und Konnektivität bieten. Es ist entscheidend, dass die Hosts im Ressourcenpool, der GFS2 verwendet, zuverlässig miteinander kommunizieren können. Um dies sicherzustellen, erfordert Citrix Hypervisor, dass Sie einen Clusterpool mit Ihrer GFS2 SR verwenden. Wir empfehlen außerdem, dass Sie Ihre Umgebung entwerfen und Citrix Hypervisor-Funktionen konfigurieren, um so viel Ausfallsicherheit und Redundanz wie möglich zu bieten.

Bevor Sie Ihren Citrix Hypervisor-Pool für die Arbeit mit GFS2-SRs einrichten, überprüfen Sie die folgenden Anforderungen und Empfehlungen für eine ideale GFS2-Umgebung:

• Empfohlen: Konfigurieren einer redundanten Netzwerkinfrastruktur.

• Empfohlen: Erstellen eines dedizierten gebundenen Netzwerks

• Erforderlich: Einrichten eines Clusterpools

• Wahlfrei Erhöhen Sie den Speicher Ihrer Steuerdomäne

• Empfohlen: Konfigurieren von Speicher-Multipathing

• Erforderlich: Erstellen einer GFS2-SR

Ein Clusterpool mit GFS2-SRs weist einige Unterschiede im Verhalten zu anderen Pool- und SR-Typen auf. Weitere Informationen finden Sie unter Zwänge.

2. Konfigurieren einer redundanten Netzwerkinfrastruktur

Ein gebündeltes Netzwerk verbindet zwei oder mehr Netzwerkkarten miteinander, um einen einzigen Kanal für den Netzwerkverkehr zu erstellen. Es wird empfohlen, dass Sie ein gebundenes Netzwerk für Ihren Clusterpooldatenverkehr verwenden. Stellen Sie jedoch vor dem Einrichten des gebundenen Netzwerks sicher, dass die Konfiguration der Netzwerkhardware die Redundanz im gebundenen Netzwerk fördert. Erwägen Sie, so viele dieser Empfehlungen zu implementieren, wie für Ihre Organisation und Umgebung machbar sind.

Die folgenden bewährten Methoden erhöhen die Resilienz gegen Software-, Hardware- oder Stromausfälle, die sich auf Ihre Netzwerk-Switches auswirken können:

• Stellen Sie sicher, dass separate physische Netzwerk-Switches für die Verwendung im gebundenen Netzwerk verfügbar sind, nicht nur Ports auf demselben Switch.
• Stellen Sie sicher, dass die separaten Switches von unterschiedlichen, unabhängigen Power Distribution Units (PDUs) mit Strom versorgt werden.
• Wenn möglich, platzieren Sie die PDUs in Ihrem Rechenzentrum auf verschiedenen Phasen der Stromversorgung oder sogar auf Einspeisungen, die von verschiedenen Versorgungsunternehmen bereitgestellt werden.
• Erwägen Sie die Verwendung von unterbrechungsfreien Netzteilen, um sicherzustellen, dass die Netzwerk-Switches und Server im Falle eines Stromausfalls weiterhin funktionieren oder ein geordnetes Herunterfahren durchführen können.

3. Erstellen Sie ein dediziertes gebundenes Netzwerk

Es ist wichtig sicherzustellen, dass Hosts in einem Clusterpool zuverlässig miteinander kommunizieren können. Das Erstellen eines gebundenen Netzwerks für diesen Pooldatenverkehr erhöht die Resilienz Ihres Clusterpools.

Ein gebundenes Netzwerk erstellt eine Bindung zwischen zwei oder mehr Netzwerkkarten, um einen einzelnen, leistungsstarken Kanal zu erstellen, den Ihr Clusterpool für Clustertaktdatenverkehr verwenden kann. Es wird dringend empfohlen, dieses gebundene Netzwerk nicht für anderen Datenverkehr zu verwenden. Erstellen Sie ein separates Netzwerk für den Pool, das für den Verwaltungsdatenverkehr verwendet werden soll.

Warnung:

Wenn Sie sich entscheiden, diese Empfehlung nicht zu befolgen, besteht ein höheres Risiko, dass Netzwerkpakete für die Clusterverwaltung verloren gehen. Der Verlust von Netzwerkpaketen für die Clusterverwaltung kann dazu führen, dass der Clusterpool das Quorum verliert und einige oder alle Hosts im Pool selbst abgeschirmt werden.

Wenn Ihr Cluster ein Fencing aufweist oder ein Problem in dieser nicht empfohlenen Konfiguration auftritt, werden Sie vom Support möglicherweise aufgefordert, das gleiche Problem im Laufe der Untersuchung in einer empfohlenen Konfiguration zu reproduzieren.

So erstellen Sie ein gebundenes Netzwerk, das als Cluster-Netzwerk verwendet werden soll:

1. Wenn Sie über eine Firewall zwischen den Hosts in Ihrem Pool verfügen, stellen Sie sicher, dass Hosts über die folgenden Ports im Clusternetzwerk kommunizieren können:

   • Telefon: 8892, 8896, 21064
   • UDP: 5404, 5405

   Weitere Informationen finden Sie unter Von Citrix Hypervisor verwendete Kommunikationsports.

2. Öffnen Sie eine Konsole auf dem Citrix Hypervisor-Server, die Sie als Poolmaster fungieren möchten.

3. Erstellen Sie mit dem folgenden Befehl ein Netzwerk für die Verwendung mit der gebundenen Netzwerkkarte:

     xe network-create name-label=bond0
   <!--NeedCopy-->
   

   Die UUID des neuen Netzwerks wird zurückgegeben.

4. Suchen Sie mit dem folgenden Befehl die UUIDs der PIFs, die in der Bindung verwendet werden sollen:

     xe pif-list
   <!--NeedCopy-->
   

5. Erstellen Sie Ihr gebundenes Netzwerk entweder im Aktiv-Aktiv-Modus, im Aktiv-Passiv-Modus oder im LACP-Bindungsmodus. Führen Sie je nach dem Bindungsmodus, den Sie verwenden möchten, eine der folgenden Aktionen aus:

   • Um die Bindung im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie die Schaltfläche Bindung-Erstellen , um die Bindung zu erstellen. Geben Sie unter Verwendung von Kommas zur Trennung der Parameter die neu erstellte Netzwerk-UUID und die UUIDs der zu bindenden PIFs an:

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

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

   • Um die Bindung im Aktiv-Passiv- oder LACP-Bindungsmodus zu konfigurieren, verwenden Sie die gleiche Syntax, fügen Sie das optionale Modus und geben Sie LACP oder aktives-backup:

        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
      <!--NeedCopy-->
     

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

Weitere Informationen finden Sie unter Vernetzung.

Hinweis:

• Um die IP-Adresse des Clusternetzwerks mithilfe von XenCenter zu ändern, müssen Clustering und GFS2 vorübergehend deaktiviert werden.
• Ändern Sie die Bündelung Ihres Clusternetzwerks nicht, während der Cluster aktiv ist und über ausgeführte VMs verfügt. Diese Aktion kann dazu führen, dass Hosts im Cluster hart neu gestartet werden (Fence).
• Wenn in Ihrem Clusternetzwerk ein IP-Adressenkonflikt (mehrere Hosts mit derselben IP-Adresse) auftritt, an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, wird der Cluster nicht korrekt gebildet und die Hosts können bei Bedarf nicht abgeschirmt werden. Um dieses Problem zu beheben, beheben Sie den IP-Adressenkonflikt.

So testen Sie die Failover-Zeiten für Ihr Aktiv-Passiv-gebundenes Netzwerk:

Bei gebundenen Netzwerken, die den Aktiv-Passiv-Modus verwenden, gibt es einen Failover-Zeitraum, in dem die Netzwerkverbindung unterbrochen wird, während die passive Verbindung aktiv wird, wenn die aktive Verbindung ausfällt. Wenn die Zeit, die für das Failover Ihres Aktiv-Passiv-Netzwerks benötigt wird, länger ist als das Cluster-Timeout, können einige oder alle Hosts in Ihrem Clusterpool weiterhin umzäunt sein.

Sie können die Failoverzeit für das gebundene Netzwerk testen, indem Sie ein Failover des Netzwerks erzwingen, indem Sie eine der folgenden Methoden verwenden:

• Durch physisches Herausziehen der Netzwerkkabel
• Durch Deaktivieren von Switch-Ports auf einer Netzwerkverbindung

Wiederholen Sie den Test mehrmals, um sicherzustellen, dass das Ergebnis konsistent ist.

Der Cluster-Timeout-Wert Ihres Pools hängt davon ab, wie viele Hosts sich in Ihrem Cluster befinden. Führen Sie den folgenden Befehl aus, um die token-zeitüberschreitung Wert in Sekunden für den Pool:

  xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout

Wenn die Failoverzeit wahrscheinlich größer als der Timeoutwert ist, sind Ihre Netzwerkinfrastruktur und -konfiguration möglicherweise nicht zuverlässig genug, um einen Clusterpool zu unterstützen.

4. Einrichten eines Clusterpools

Um gemeinsam genutzten GFS2-Speicher verwenden zu können, muss es sich bei dem Citrix Hypervisor-Ressourcenpool um einen Clusterpool handeln. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie eine GFS2-SR erstellen.

Ein Clusterpool ist ein Pool von Citrix Hypervisor-Servern, die enger miteinander verbunden und koordiniert sind als Hosts in nicht geclusterten Pools. Die Hosts im Cluster kommunizieren ständig miteinander in einem ausgewählten Netzwerk. Alle Hosts im Cluster kennen den Status jedes Hosts im Cluster. Diese Hostkoordination ermöglicht es dem Cluster, den Zugriff auf den Inhalt der GFS2 SR zu steuern. Um sicherzustellen, dass der Clusterpool immer in Kommunikation bleibt, muss jeder Host in einem Cluster immer mit mindestens der Hälfte der Hosts im Cluster (einschließlich sich selbst) kommunizieren. Dieser Zustand wird als Host mit Quorum bezeichnet. Wenn ein Host nicht über ein Quorum verfügt, wird er hart neu gestartet und sich selbst aus dem Cluster entfernt. Diese Aktion wird als “Fechten” bezeichnet.

Weitere Informationen finden Sie unter Clustered Pools.

Bevor Sie mit dem Einrichten Ihres Clusterpools beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

• Planen Sie, einen Pool von 3 bis 16 Hosts zu erstellen.

  Verwenden Sie nach Möglichkeit eine ungerade Anzahl von Hosts in einem Clusterpool, da dies sicherstellt, dass Hosts immer feststellen können, ob sie über ein Quor verfügen. Es wird empfohlen, Clustering nur in Pools mit mindestens drei Hosts zu verwenden, da Pools mit zwei Hosts empfindlich auf Self-Fencing des gesamten Pools reagieren.

  Clusterpools unterstützen nur bis zu 16 Hosts pro Pool.

• Alle Citrix Hypervisor-Server im Clusterpool müssen über mindestens 2 GiB Steuerdomänenspeicher verfügen.
• Alle Hosts im Cluster müssen statische IP-Adressen für das Clusternetzwerk verwenden.
• Wenn Sie einen vorhandenen Pool gruppieren, stellen Sie sicher, dass die Hochverfügbarkeit deaktiviert ist. Sie können die Hochverfügbarkeit wieder aktivieren, nachdem das Clustering aktiviert wurde.

So verwenden Sie die xe CLI zum Erstellen eines Cluster-Pools:

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

   Wiederholen Sie die folgenden Schritte auf jedem beitretenden Citrix Hypervisor-Server, der nicht der Poolmaster ist:

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

   2. Verknüpfen 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>
      <!--NeedCopy-->
      

      Der Wert des Master-Adresse muss auf den vollqualifizierten Domänennamen des Citrix Hypervisor-Servers festgelegt werden, bei dem es sich um den Poolmaster handelt. Das Passwort muss das Administratorkennwort sein, das bei der Installation des Poolmasters festgelegt wurde.

   Weitere Informationen finden Sie unter Hosts und Ressourcenpools.

2. Legen Sie für jeden PIF, der zu diesem Netzwerk gehört, disallow-unplug=wahr.

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

        xe pif-list
      <!--NeedCopy-->
      

   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>
      <!--NeedCopy-->
      

3. Aktivieren Sie 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>
   <!--NeedCopy-->
   

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

5. Erhöhen Sie den Speicher Ihrer Steuerdomäne

Wenn Sie nicht über genügend Steuerungsdomänenspeicher auf Ihren Hosts verfügen, kann es zu einer Netzwerkinstabilität in Ihrem Pool kommen. Netzwerkinstabilität kann bei einem Clusterpool mit GFS2-SRs zu Problemen führen.

Es ist wichtig sicherzustellen, dass Ihr Clusterpool über eine angemessene Menge an Steuerdomänenspeicher verfügt. Informationen zum Ändern der Größe des Speichers der Steuerdomäne und zum Überwachen des Speicherverhaltens finden Sie unter Speicherauslastung.

6. Konfigurieren von Speicher-Multipathing

Stellen Sie sicher, dass Storage Multipathing zwischen Ihrem Cluster-Pool und Ihrer GFS2 SR eingerichtet ist.

Multipathing leitet den Speicherdatenverkehr aus Redundanzgründen über mehrere Pfade an ein Speichergerät weiter. Auf allen Routen kann während des normalen Betriebs aktiver Verkehr vorhanden sein, was zu einem erhöhten Durchsatz führt.

Bevor Sie Multipathing aktivieren, stellen Sie sicher, dass die folgenden Aussagen wahr sind:

• Ihr Ethernet- oder Fibre-Switch ist so konfiguriert, dass mehrere Ziele auf Ihrem Speicherserver verfügbar sind.

  Ein iSCSI-Speicher-Back-End, das z. B. nach Ziele senden für ein bestimmtes Portal gibt mehrere Ziele zurück, wie im folgenden Beispiel gezeigt:

      iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
      192.168.0.161:3260,1 iqn.strawberry:litchie
      192.168.0.204:3260,2 iqn.strawberry:litchie
  

  Sie können jedoch eine zusätzliche Konfiguration vornehmen, um iSCSI-Multipath für Arrays zu aktivieren, die nur ein einzelnes Ziel verfügbar machen. Weitere Informationen finden Sie unter iSCSI-Multipath für Arrays, die nur ein einzelnes Ziel verfügbar machen.

• Nur für iSCSI verfügt die Steuerdomäne (dom0) über eine IP-Adresse in jedem Subnetz, das vom Multipath-Speicher verwendet wird.

  Stellen Sie sicher, dass Sie für jeden Pfad zum Speicher über eine Netzwerkkarte verfügen und dass auf jeder Netzwerkkarte eine IP-Adresse konfiguriert ist. Wenn Sie z. B. vier Pfade zu Ihrem Speicher benötigen, müssen Sie über vier Netzwerkkarten verfügen, für die jeweils eine IP-Adresse konfiguriert ist.

• Nur für iSCSI verfügt jedes iSCSI-Ziel und jeder iSCSI-Initiator über einen eindeutigen IQN.

• Nur für iSCSI werden die iSCSI-Zielports im Portalmodus betrieben.

• Nur für HBAs sind mehrere HBAs mit der Switch-Fabric verbunden.

• Verwenden Sie nach Möglichkeit mehrere redundante Switches.

So aktivieren Sie Multipathing mithilfe der xe CLI

Es wird empfohlen, Multipathing für alle Hosts in Ihrem Pool zu aktivieren vor Erstellen der SR. Wenn Sie die SR erstellen, bevor Sie Multipathing aktivieren, müssen Sie Ihre Hosts in den Wartungsmodus versetzen, um Multipathing zu aktivieren.

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

2. Trennen Sie alle PBDs auf dem Host mit dem folgenden Befehl:

     xe pbd-unplug uuid=<pbd_uuid>
   <!--NeedCopy-->
   

   Sie können den Befehl XE PBD-Liste , um die UUID der PBDs zu finden.

3. Legen Sie den Wert der Multipathing Parameter auf STIMMT mit dem folgenden Befehl:

     xe host-param-set uuid=<host uuid> multipathing=true
   <!--NeedCopy-->
   

4. Wenn auf den Hosts, die im Einzelpfadmodus ausgeführt werden, SRs vorhanden sind, die über mehrere Pfade verfügen:

   • Migrieren Sie alle ausgeführten Gäste mit virtuellen Festplatten in den betroffenen SRs, oder halten Sie sie an.

   • Schließen Sie die PBD aller betroffenen SRs wieder an, um sie mithilfe von Multipathing wieder zu verbinden:

        xe pbd-plug uuid=<pbd_uuid>
      <!--NeedCopy-->
     

5. Wiederholen Sie diese Schritte, um Multipathing auf allen Hosts im Pool zu aktivieren.

Stellen Sie sicher, dass Sie Multipathing auf allen Hosts im Pool aktivieren. Die gesamte Verkabelung und im Falle von iSCSI die Subnetzkonfigurationen müssen mit den entsprechenden Netzwerkkarten auf jedem Host übereinstimmen.

Weitere Informationen finden Sie unter Multipathing für Speicher.

7. Erstellen Sie eine GFS2 SR

Erstellen Sie Ihre freigegebene GFS2 SR auf einer iSCSI- oder HBA-LUN, die für alle Citrix Hypervisor-Server in Ihrem Ressourcenpool sichtbar ist. Es wird nicht empfohlen, eine Thin-Provisioning-LUN mit GFS2 zu verwenden. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie sicherstellen, dass die LUN immer über genügend Speicherplatz verfügt, damit Citrix Hypervisor darauf schreiben kann.

Sie können einem Clusterpool bis zu 62 GFS2-SRs hinzufügen.

Wenn Sie Ihr blockbasiertes Speichergerät zuvor für Thick Provisioning mit LVM verwendet haben, wird dies von Citrix Hypervisor erkannt. XenCenter bietet Ihnen die Möglichkeit, die vorhandene LVM-Partition zu verwenden oder die Festplatte zu formatieren und eine GFS2-Partition einzurichten.

Erstellen eines freigegebenen GFS2 über iSCSI SR

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

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

Device-config-Parameter für GFS2 SRs:

Sie können die Werte finden, die für diese Parameter verwendet werden sollen, indem Sie die XE SR-SONDE-EXT Befehl.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

1. Führen Sie zunächst den folgenden Befehl aus:

     xe sr-probe-ext type=gfs2 device-config:provider=iscsi
   <!--NeedCopy-->
   

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

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

3. Wenn die Befehlsausgabe mit Es wurden die folgenden vollständigen Konfigurationen gefunden, die zum Erstellen von SRs verwendet werden können:können Sie die SR suchen, indem Sie die Schaltfläche XE SR-CREATE und der Befehl Gerät-Konfiguration Parameter, die Sie angegeben haben.

   Beispiel für eine Ausgabe:

     Found the following complete configurations that can be used to create SRs:
     Configuration 0:
       SCSIid       : 36001405852f77532a064687aea8a5b3f
           targetIQN: iqn.2009-01.example.com:iscsi192a25d6
              target: 198.51.100.27
            provider: iscsi
   
   
     Configuration 0 extra information:
   <!--NeedCopy-->
   

Um eine freigegebene 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>
<!--NeedCopy-->

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

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

Erstellen eines freigegebenen 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 eine GFS2-über-HBA-SR zu erstellen.

Device-config-Parameter für GFS2 SRs:

Sie können die Werte finden, die für den SCSIid-Parameter verwendet werden sollen, indem Sie die XE SR-SONDE-EXT Befehl.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

1. Führen Sie zunächst den folgenden Befehl aus:

     xe sr-probe-ext type=gfs2 device-config:provider=hba
   <!--NeedCopy-->
   

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

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

3. Wenn die Befehlsausgabe mit Es wurden die folgenden vollständigen Konfigurationen gefunden, die zum Erstellen von SRs verwendet werden können:können Sie die SR suchen, indem Sie die Schaltfläche XE SR-CREATE und der Befehl Gerät-Konfiguration Parameter, die Sie angegeben haben.

   Beispiel für eine Ausgabe:

     Found the following complete configurations that can be used to create SRs:
     Configuration 0:
       SCSIid       : 36001405852f77532a064687aea8a5b3f
           targetIQN: iqn.2009-01.example.com:iscsi192a25d6
              target: 198.51.100.27
            provider: iscsi
   
   
     Configuration 0 extra information:
   <!--NeedCopy-->
   

Um eine gemeinsam genutzte 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>
<!--NeedCopy-->

Weitere Hinweise zum Arbeiten mit HBA-SRs finden Sie unter Hardware-Host-Bus-Adapter.

Was kommt als nächstes?

Nachdem Sie Ihre GFS2-Umgebung eingerichtet haben, ist es wichtig, dass Sie die Stabilität Ihres Clusterpools aufrechterhalten, indem Sie sicherstellen, dass er über ein Quorum verfügt. Weitere Informationen finden Sie unter Verwalten des Clusterpools.

Wenn Sie Probleme mit Ihrer GFS2-Umgebung haben, lesen Sie Problembehandlung bei Clusterpools.

Sie können Ihre GFS2 SR auf die gleiche Weise verwalten wie andere SRs. Sie können z. B. dem Speicher-Array Kapazität hinzufügen, um die Größe der LUN zu erhöhen. Weitere Informationen finden Sie unter Live-LUN-Erweiterung.

Einschränkungen

Für freigegebenen GFS2-Speicher gelten derzeit die folgenden Einschränkungen:

• Wie bei jeder Thin-Provisioning-SR schlägt bei einer Erhöhung der GFS2-SR-Nutzung auf 100 % weitere Schreibvorgänge von VMs fehl. Diese fehlgeschlagenen Schreibvorgänge können dann zu Fehlern innerhalb des virtuellen Computers, einer möglichen Datenbeschädigung oder beidem führen.

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

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

• Der Software-FCoE-Transport wird mit GFS2-SRs nicht unterstützt (z. B. vollständig ausgelagerte FCoE-Verwendung HBA).

• Das Trimmen/Aufheben der Zuordnung wird auf GFS2-SRs nicht unterstützt.

• CHAP wird auf GFS2-SRs nicht unterstützt.

• MCS-Full-Clone-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 Festplatten auf diesen SRs nicht verfügbar.

• Die Nachverfolgung geänderter Blöcke wird für VDIs, die auf GFS2-SRs gespeichert sind, nicht unterstützt.

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

• Es wird nicht empfohlen, eine Thin-Provisioning-LUN mit GFS2 zu verwenden. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie sicherstellen, dass die LUN immer über genügend Speicherplatz verfügt, damit Citrix Hypervisor darauf schreiben kann.

• Es wird nicht empfohlen, die SAN-Deduplizierung mit GFS2-SRs zu verwenden. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie eine geeignete externe Überwachung Ihrer SAN-Auslastung verwenden, um sicherzustellen, dass immer Platz für Citrix Hypervisor zum Schreiben vorhanden ist.

• Ihr GFS2-Dateisystem darf nicht größer als 100 TiB sein.

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

• Clusterpools unterstützen nur bis zu 16 Hosts pro Pool.

• Um HA in Ihrem Clusterpool zu aktivieren, muss es sich bei der Heartbeat-SR um eine GFS2-SR handeln.

• Für Clusterdatenverkehr wird dringend empfohlen, ein gebundenes Netzwerk zu verwenden, das mindestens zwei verschiedene Netzwerk-Switches verwendet. Verwenden Sie dieses Netzwerk nicht für andere Zwecke.

• Um die IP-Adresse des Clusternetzwerks mithilfe von XenCenter zu ändern, müssen Clustering und GFS2 vorübergehend deaktiviert werden.

• Ändern Sie die Bündelung Ihres Clusternetzwerks nicht, während der Cluster aktiv ist und über ausgeführte VMs verfügt. Diese Aktion kann dazu führen, dass Hosts im Cluster hart neu gestartet werden (Fence).

• Wenn in Ihrem Clusternetzwerk ein IP-Adressenkonflikt (mehrere Hosts mit derselben IP-Adresse) auftritt, an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, wird der Cluster nicht korrekt gebildet und die Hosts können bei Bedarf nicht abgeschirmt werden. Um dieses Problem zu beheben, beheben Sie den IP-Adressenkonflikt.