Gemeinsam genutzter GFS2-Blockspeicher mit Thin-Provisioning

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 spärlich und nicht dicht verteilt.
• Sie möchten die Anzahl der I/O-Vorgänge pro Sekunde auf Ihrem Speicher-Array reduzieren. 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.
• 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 unterstützt nur Blockspeicher. Wenn Ihr Speicher NFS oder SMB3 unterstützt, empfehlen wir Ihnen, diese SR-Typen anstelle von GFS2 zu verwenden.
• Ihr Speicher unterstützt kein Thin Provisioning von LUNs. Wenn Ihr Speicher Thin Provision-LUNs verwendet, können Probleme auftreten und Ihnen der Speicherplatz ausgeht, wenn Sie ihn mit GFS2 kombinieren. Die Kombination von GFS2 mit einer Thin-Provision-LUN bietet nicht viele zusätzliche Vorteile und wird nicht empfohlen.

Hinweis:

Wir empfehlen, GFS2 SR nicht mit einem VLAN zu verwenden, da ein bekanntes Problem besteht, bei dem Sie Hosts in einem Clusterpool nicht hinzufügen oder entfernen können, wenn sich das Clusternetzwerk in einem Nicht-Management-VLAN befindet.

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

In diesem Artikel wird beschrieben, wie Sie Ihre GFS2-Umgebung mithilfe der Xe-CLI einrichten. Informationen zum Einrichten einer GFS2-Umgebung mithilfe von XenCenter finden Sie in derXenCenter-Produktdokumentation.

1. Planen Sie Ihre GFS2-Umgebung

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

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:

• Empfehlung: Konfigurieren Sie eine redundante Netzwerkinfrastruktur.

• Empfohlen: Erstellen Sie ein dediziertes gebundenesNetzwerk

• Erforderlich: Richten Sie einen Clusterpool ein

• Optional: Erhöhen Sie den Speicher Ihrer Steuerdomäne

• Empfehlung: Speicher-Multipathing konfigurieren

• Erforderlich: Erstellen Sie eine GFS2-SR

Ein geclusterter Pool mit GFS2-SRs weist einige Verhaltensunterschiede zu anderen Pool- und SR-Typen auf. Weitere Informationen finden Sie unter Einschränkungen.

2. Konfiguration einer redundanten Netzwerkinfrastruktur

Ein gebundenes Netzwerk verbindet zwei oder mehr NICs miteinander, um einen einzigen Kanal für den Netzwerkverkehr zu schaffen. Wir empfehlen, dass Sie ein gebundenes Netzwerk für Ihren Clusterpool-Verkehr verwenden. Bevor Sie Ihr gebündeltes Netzwerk einrichten, stellen Sie jedoch sicher, dass Ihre Netzwerkhardwarekonfiguration die Redundanz im gebundenen Netzwerk fördert. Erwägen Sie, so viele dieser Empfehlungen umzusetzen, wie es für Ihr Unternehmen und Ihre Umgebung möglich ist.

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

• Stellen Sie sicher, dass Sie separate physische Netzwerk-Switches für die Verwendung im gebündelten Netzwerk zur Verfügung haben, nicht nur Ports auf demselben Switch.
• Stellen Sie sicher, dass die einzelnen Switches Strom von verschiedenen, unabhängigen Stromverteilungseinheiten (PDUs) beziehen.
• Wenn möglich, platzieren Sie die PDUs in Ihrem Rechenzentrum an verschiedenen Phasen der Stromversorgung oder sogar an Einspeisungen, die von verschiedenen Versorgungsunternehmen bereitgestellt werden.
• Erwägen Sie die Verwendung von unterbrechungsfreien Stromversorgungen, um sicherzustellen, dass die Netzwerk-Switches und Server weiterhin funktionieren oder bei einem Stromausfall ordnungsgemäß heruntergefahren werden 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 Verbundnetzwerks für diesen Pool-Verkehr erhöht die Ausfallsicherheit Ihres Clusterpools.

Ein gebundenes Netzwerk stellt eine Verbindung zwischen zwei oder mehr NICs her, um einen einzigen, leistungsstarken Kanal zu erstellen, den Ihr Clusterpool für Cluster-Heartbeat-Verkehr verwenden kann. Wir empfehlen dringend, dieses gebündelte Netzwerk nicht für anderen Datenverkehr zu verwenden. Erstellen Sie ein separates Netzwerk für den Pool, das für die Verwaltung des Datenverkehrs verwendet werden soll.

Warnung:

Wenn Sie dieser Empfehlung nicht folgen, besteht ein höheres Risiko, Netzwerkpakete für die Clusterverwaltung zu verlieren. Der Verlust von Netzwerkpaketen für die Clusterverwaltung kann dazu führen, dass Ihr Clusterpool das Quorum verliert und einige oder alle Hosts im Pool sich selbst umzäunen.

Wenn Ihr Cluster abgegrenzt ist oder ein Problem in dieser nicht empfohlenen Konfiguration auftritt, bittet Sie der Support möglicherweise im Laufe der Untersuchung, dasselbe Problem mit einer empfohlenen Konfiguration zu reproduzieren.

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

1. 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, 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 ein Netzwerk zur Verwendung mit der gebundenen NIC, indem Sie den folgenden Befehl verwenden:

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

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

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

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

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.

Hinweis:

• 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 dazu führen, dass Hosts im Cluster neu gestartet werden (Fencing).
• Wenn Sie in Ihrem Clusternetzwerk einen IP-Adresskonflikt haben (mehrere Hosts mit derselben IP-Adresse), an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, wird der Cluster nicht korrekt gebildet und die Hosts können bei Bedarf kein Fencing durchführen. Um dieses Problem zu beheben, lösen Sie den IP-Adresskonflikt.

So testen Sie die Failover-Zeiten für Ihr aktiv-passives gebundenes Netzwerk:

Bei verbundenen Netzwerken, die den Aktiv-Passiv-Modus verwenden, gibt es beim Ausfall der aktiven Verbindung eine Failover-Phase, in der die Netzwerkverbindung unterbrochen wird, während die passive Verbindung aktiv wird. Wenn die Zeit, die für das Failover Ihres Aktiv-Passiv-Verbundnetzwerks benötigt wird, länger als das Cluster-Timeout ist, können einige oder alle Hosts in Ihrem Clusterpool immer noch eingezäunt sein.

Sie können die Failoverzeit Ihres verbundenen Netzwerks testen, indem Sie das Netzwerk mithilfe einer der folgenden Methoden zum Failover zwingen:

• Durch physisches Herausziehen der Netzwerkkabel
• Durch Deaktivieren von Switch-Ports an 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 den Wert token-timeout für den Pool in Sekunden zu ermitteln:

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

Wenn die Failover-Zeit wahrscheinlich über dem Timeout-Wert liegt, sind Ihre Netzwerkinfrastruktur und Konfiguration möglicherweise nicht zuverlässig genug, um einen Clusterpool zu unterstützen.

4. Richten Sie einen Clusterpool ein

Um gemeinsam genutzten GFS2-Speicher zu verwenden, muss der Citrix Hypervisor Ressourcenpool ein Clusterpool sein. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie ein 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 Host-Koordination ermöglicht es dem Cluster, den Zugriff auf den Inhalt des GFS2-SRs zu steuern. Um sicherzustellen, dass der Clusterpool immer in Verbindung bleibt, muss jeder Host in einem Cluster immer mit mindestens der Hälfte der Hosts im Cluster kommunizieren (einschließlich sich selbst). Dieser Zustand ist als Host mit Quorum bekannt. Wenn ein Host kein Quorum hat, wird er neu gestartet und entfernt sich selbst aus dem Cluster. Diese Aktion wird als “Fechten” bezeichnet.

Weitere Informationen finden Sie unter Clustered-Pools.

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

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

  Verwenden Sie nach Möglichkeit eine ungerade Anzahl von Hosts in einem Clusterpool, da dadurch sichergestellt wird, dass Hosts immer feststellen können, ob sie Quorun haben. 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.

  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 Cluster-Netzwerk verwenden.
• 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.

So verwenden Sie die xe CLI zum Erstellen eines Clusterpool:

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

      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.

2. 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
      <!--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 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>
   <!--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 auf Ihren Hosts nicht genügend Steuerdomänenspeicher haben, kann es in Ihrem Pool zu Netzwerkinstabilität 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. Hinweise zum Ändern der Größe des Steuerdomänenspeichers und zum Überwachen des Speicherverhaltens finden Sie unter Speicherauslastung.

6. Speicher-Multipathing konfigurieren

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

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

Bevor Sie Multipathing aktivieren, überprüfen Sie, ob die folgenden Anweisungen zutreffen:

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

  Beispielsweise gibt ein iSCSI-Speicher-Backend, das nach sendtargets für ein bestimmtes Portal abgefragt wird, mehrere Ziele zurück, wie im folgenden Beispiel:

    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 durchführen, um iSCSI-Multipath für Arrays zu aktivieren, die nur ein einziges Ziel verfügbar machen. Weitere Informationen finden Sie unter iSCSI Multipath für Arrays, die nur ein einziges Zielverfügbar machen.

• Nur für iSCSI hat die Steuerdomäne (dom0) 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 beispielsweise vier Pfade zu Ihrem Speicher wünschen, müssen Sie über vier Netzwerkkarten verfügen, für die jeweils eine IP-Adresse konfiguriert ist.

• Nur für iSCSI hat jedes iSCSI-Ziel und jeder iSCSI-Initiator einen eigenen IQN.

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

• Nur für HBA sind mehrere HBAs an die Switch-Fabric angeschlossen.

• Verwenden Sie nach Möglichkeit mehrere redundante Switches.

So aktivieren Sie Multipathing mit der xe-CLI

Wir empfehlen, dass Sie Multipathing für alle Hosts in Ihrem Pool aktivieren, bevor Sie die SR erstellen. 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 verwenden xe pbd-list, um die UUID der PBDs zu finden.

3. Setzen Sie den Wert des Parameters multipathing auf true, indem Sie den folgenden Befehl verwenden:

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

4. Wenn auf den Hosts, die im Einzelpfadmodus ausgeführt werden, SRs mit mehreren Pfaden vorhanden sind:

   • Migrieren oder unterbrechen Sie alle laufenden Gäste mit virtuellen Datenträgern in den betroffenen SRs.

   • Schließen Sie die PBD aller betroffenen SRs erneut an, um sie mithilfe von Multipathing erneut 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 Fall von iSCSI, die Subnetzkonfigurationen müssen mit den entsprechenden NICs auf jedem Host übereinstimmen.

Weitere Informationen finden Sie unter Speicher-Multipathing.

7. Erstellen Sie eine GFS2-SR

Erstellen Sie Ihre gemeinsam genutzte GFS2 SR auf einer iSCSI- oder HBA-LUN, die für alle Citrix Hypervisor-Server in Ihrem Ressourcenpool sichtbar ist. Wir empfehlen nicht, eine Thin-Provision-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 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 den Datenträger zu formatieren und eine GFS2-Partition einzurichten.

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:

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>
<!--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 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 beginnt Found the following complete configurations that can be used to create SRs:, können Sie den SR mithilfe des xe sr-create Befehls und der von Ihnen angegebenen device-config Parameter suchen.

   Beispielausgabe:

   ```Es wurden die folgenden vollständigen Konfigurationen gefunden, die zur Erstellung von SRs verwendet werden können: Konfiguration 0: scsiID: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 Ziel : 198.51.100.27 Anbieter: iscsi

   Configuration 0 extra information: ```

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 gemountet sind, kann es sein, dass einige Hosts im Clusterpool neu gestartet werden (Fencing).

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:

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 beginnt Found the following complete configurations that can be used to create SRs:, können Sie den SR mithilfe des xe sr-create Befehls und der von Ihnen angegebenen device-config Parameter suchen.

   Beispielausgabe:

   ```Es wurden die folgenden vollständigen Konfigurationen gefunden, die zur Erstellung von SRs verwendet werden können: Konfiguration 0: scsiID: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 Ziel : 198.51.100.27 Anbieter: iscsi

   Configuration 0 extra information: ```

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

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

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 Ihres Clusterpools.

Wenn Probleme mit Ihrer GFS2-Umgebung auftreten, finden Sie weitere Informationen unter Problembehandlung bei Clusterpools.

Sie können Ihren GFS2 SR genauso verwalten wie andere SRs. Sie können beispielsweise 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

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 Ausfällen innerhalb der VM, möglichen Datenbeschädigungen 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 Software-FCoE-Transport wird mit GFS2-SRs nicht unterstützt (für vollständig ausgelagerte FCoE verwenden Sie HBA).

• 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-Provision-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.

• Wir empfehlen nicht, 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 Citrix Hypervisor immer Speicherplatz zum Schreiben zur Verfügung steht.

• 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 der Heartbeat-SR ein GFS2-SR sein.

• Für Clusterverkehr empfehlen wir dringend, 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 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 dazu führen, dass Hosts im Cluster neu gestartet werden (Fencing).

• Wenn Sie in Ihrem Clusternetzwerk einen IP-Adresskonflikt haben (mehrere Hosts mit derselben IP-Adresse), an dem mindestens ein Host mit aktiviertem Clustering beteiligt ist, wird der Cluster nicht korrekt gebildet und die Hosts können bei Bedarf kein Fencing durchführen. Um dieses Problem zu beheben, lösen Sie den IP-Adresskonflikt.