Thin-provisioned gemeinsam genutzter GFS2-Blockspeicher

Thin Provisioning nutzt den verfügbaren Speicher besser aus, indem Festplattenspeicher für VDIs zugewiesen wird, sobald Daten auf die virtuelle Festplatte geschrieben werden, anstatt die volle virtuelle Größe des VDI im Voraus zuzuweisen. Thin Provisioning ermöglicht es Ihnen, den benötigten Speicherplatz auf einem gemeinsam genutzten Speicher-Array erheblich zu reduzieren und damit Ihre Gesamtbetriebskosten (TCO) zu senken.

Warnung:

GFS2 weist eine Reihe von Einschränkungen und Komplexitäten auf, die vor der Fortsetzung sorgfältig abgewogen werden sollten. In vielen Fällen ist eine alternative Speicherstrategie angemessener.

Zu den Einschränkungen von GFS2 gehören:

• Nicht voll ausgestattet (keine Unterstützung für DR, keine Unterstützung für Speichermigration, Poolgrößen auf 16 begrenzt)
• Leistungsbeschränkungen, die es für große, I/O-intensive Workloads ungeeignet machen
• Erfordert Clusterdienste, die Stabilitätsprobleme verursachen können
• Komplexer zu verstehen, was zu mehr Fehlkonfigurationen und Fehlern führt

Angesichts dieser Einschränkungen und Komplexitäten wird die Verwendung von GFS2 nur empfohlen, wenn keine Alternativen zur Erfüllung der Anforderungen bestehen. Die Szenarien, in denen GFS2 geeignet sein kann, sind:

• Thin Provisioning ist erforderlich und wird von Ihrem SAN nicht bereitgestellt. Es wird empfohlen, LVM-Speicher mit einem SAN zu verwenden, das die Anforderungen an Thin Provisioning erfüllt. Wo dies nicht möglich ist, kann GFS2 in Betracht gezogen werden.
• Unterstützung für Festplatten >2 TiB. GFS2 unterstützt Festplatten bis zu 16 TB. Wo Festplatten >2 TiB erforderlich sind, kann GFS2 in Betracht gezogen werden. Kunden sollten Tests durchführen, um sicherzustellen, dass die Umgebung die Last- und Leistungsanforderungen erfüllen kann.

Wenn Ihr SAN Thin Provisioning unterstützt, empfehlen wir Ihnen, dies zusammen mit LVM zu verwenden, anstatt GFS2, es sei denn, Sie benötigen VM-Festplatten, die größer als 2 TiB sind. Für Fälle, in denen VM-Festplatten größer als 2 TiB erforderlich sind, sollten Sie mehrere Festplatten in LVM in Betracht ziehen, um dies zu erreichen.

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

Dieser Artikel beschreibt, wie Sie Ihre GFS2-Umgebung mithilfe der xe CLI einrichten. Informationen zum Einrichten einer GFS2-Umgebung mithilfe von XenCenter finden Sie in der XenCenter-Produktdokumentation.

1. Planen Sie Ihre GFS2-Umgebung

Um die Vorteile der Thin Provisioning auf gemeinsam genutztem Blockspeicher ohne Datenverlustrisiko zu nutzen, 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 zu gewährleisten, erfordert XenServer®, dass Sie einen geclusterten Pool mit Ihrem GFS2-SR verwenden. Wir empfehlen außerdem, dass Sie Ihre Umgebung so gestalten und XenServer-Funktionen so konfigurieren, dass sie so viel Ausfallsicherheit und Redundanz wie möglich bieten.

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

• Empfohlen: Redundante Netzwerkinfrastruktur konfigurieren.

• Empfohlen: Ein dediziertes gebündeltes Netzwerk erstellen

• Erforderlich: Einen geclusterten Pool einrichten

• Optional: Den Arbeitsspeicher Ihrer Steuerdomäne erhöhen

• Empfohlen: Speicher-Multipathing konfigurieren

• Erforderlich: Einen GFS2-SR erstellen

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

2. Redundante Netzwerkinfrastruktur konfigurieren

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

Die folgenden Best Practices erhöhen die Ausfallsicherheit gegenüber Software-, Hardware- oder Stromausfällen, die Ihre Netzwerk-Switches beeinträchtigen 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 separaten Switches Strom von verschiedenen, unabhängigen Stromverteilungseinheiten (PDUs) beziehen.
• Platzieren Sie die PDUs in Ihrem Rechenzentrum, wenn möglich, auf verschiedenen Phasen der Stromversorgung oder sogar auf Versorgungen, die von verschiedenen Energieversorgungsunternehmen bereitgestellt werden.
• Erwägen Sie den Einsatz von unterbrechungsfreien Stromversorgungen, um sicherzustellen, dass die Netzwerk-Switches und Server im Falle eines Stromausfalls weiterhin funktionieren oder einen geordneten Shutdown durchführen können.

3. Erstellen Sie ein dediziertes gebündeltes Netzwerk

Es ist wichtig sicherzustellen, dass Hosts in einem Cluster-Pool zuverlässig miteinander kommunizieren können. Das Erstellen eines gebündelten Netzwerks für diesen Pool-Traffic erhöht die Ausfallsicherheit Ihres Cluster-Pools.

Hinweis:

Das Cluster-Netzwerk darf sich nicht in einem Nicht-Management-VLAN befinden.

Ein gebündeltes Netzwerk erstellt eine Verbindung zwischen zwei oder mehr NICs, um einen einzigen, leistungsstarken Kanal zu schaffen, den Ihr Cluster-Pool für den Cluster-Heartbeat-Traffic verwenden kann. Wir empfehlen dringend, dass dieses gebündelte Netzwerk nicht für anderen Traffic verwendet wird. Erstellen Sie ein separates Netzwerk für den Pool, das für den Management-Traffic verwendet werden soll.

Warnung:

Wenn Sie diese Empfehlung nicht befolgen, besteht ein höheres Risiko, dass Cluster-Management-Netzwerkpakete verloren gehen. Der Verlust von Cluster-Management-Netzwerkpaketen kann dazu führen, dass Ihr Cluster-Pool das Quorum verliert und einige oder alle Hosts im Pool sich selbst isolieren (self-fence).

Wenn Ihr Cluster in dieser nicht empfohlenen Konfiguration isoliert wird oder ein Problem auftritt, könnte der XenServer-Support Sie im Rahmen der Untersuchung bitten, dasselbe Problem in einer empfohlenen Konfiguration zu reproduzieren.

So erstellen Sie ein gebündeltes Netzwerk zur Verwendung als GFS2-Cluster-Netzwerk:

1. Wenn Sie eine Firewall zwischen den Hosts in Ihrem Pool haben, stellen Sie sicher, dass die Hosts im Cluster-Netzwerk über die folgenden Ports kommunizieren können:

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

   Weitere Informationen finden Sie unter Von XenServer verwendete Kommunikationsports.

2. Öffnen Sie eine Konsole auf dem XenServer-Host, der als Pool-Koordinator fungieren soll.

3. Erstellen Sie ein Netzwerk zur Verwendung mit der gebündelten 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 im Bond verwendet werden sollen, indem Sie den folgenden Befehl verwenden:

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

5. Erstellen Sie Ihr gebündeltes Netzwerk entweder im Active-Active-Modus, Active-Passive-Modus oder LACP-Bond-Modus. Führen Sie je nach gewünschtem Bond-Modus eine der folgenden Aktionen aus:

   • Um den Bond im Active-Active-Modus (Standard) zu konfigurieren, verwenden Sie den Befehl bond-create, um den Bond zu erstellen. Trennen Sie die Parameter durch Kommas und geben Sie die neu erstellte Netzwerk-UUID und die UUIDs der zu bündelnden 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 bündeln, und vier UUIDs, wenn Sie vier NICs bündeln. Die UUID für den Bond wird nach Ausführung des Befehls zurückgegeben.

   • Um den Bond im Active-Passive- 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 gebündeltes Netzwerk auf dem Pool-Koordinator erstellt haben, werden die Netzwerk- und Bond-Informationen automatisch auf den beitretenden Server repliziert, wenn Sie andere XenServer-Hosts dem Pool hinzufügen.

Weitere Informationen finden Sie unter Netzwerk.

Hinweis:

• Das Ändern der IP-Adresse des Clusternetzwerks mit XenCenter® erfordert, dass Clustering und GFS2 vorübergehend deaktiviert werden.
• Ändern Sie die Bündelung Ihres Clusternetzwerks nicht, während der Cluster aktiv ist und VMs ausgeführt werden. Diese Aktion kann dazu führen, dass Hosts im Cluster einen Hard-Restart (Fencing) durchführen.
• Wenn Sie einen IP-Adresskonflikt (mehrere Hosts mit derselben IP-Adresse) in Ihrem Clusternetzwerk haben, der mindestens einen Host mit aktiviertem Clustering betrifft, 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.

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 in Sekunden für den Pool zu ermitteln:

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

Wenn die Failover-Zeit der Netzwerkbindung wahrscheinlich länger ist als der Timeout-Wert, ist Ihre Netzwerkinfrastruktur und -konfiguration möglicherweise nicht zuverlässig genug, um einen geclusterten Pool zu unterstützen.

4. Einen geclusterten Pool einrichten

Um gemeinsam genutzten GFS2-Speicher zu verwenden, muss der XenServer-Ressourcenpool ein geclusterter Pool sein. Aktivieren Sie die Clusterbildung in Ihrem Pool, bevor Sie einen GFS2-SR erstellen.

Ein geclusterter Pool ist ein Pool von XenServer-Hosts, die enger miteinander verbunden und koordiniert sind als Hosts in nicht geclusterten Pools. Die Hosts im Cluster kommunizieren ständig über ein ausgewähltes Netzwerk miteinander. Alle Hosts im Cluster kennen den Status jedes Hosts im Cluster. Diese Host-Koordination ermöglicht es dem Cluster, den Zugriff auf die Inhalte des GFS2-SR zu steuern. Um sicherzustellen, dass der geclusterte Pool immer in Kommunikation bleibt, muss jeder Host in einem Cluster immer mit mindestens der Hälfte der Hosts im Cluster (einschließlich sich selbst) in Kommunikation stehen. Dieser Zustand wird als Host mit Quorum bezeichnet. Wenn ein Host kein Quorum hat, wird er hart neu gestartet und entfernt sich selbst aus dem Cluster. Diese Aktion wird als ‘Fencing’ bezeichnet.

Weitere Informationen finden Sie unter Geclusterte Pools.

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

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

  Verwenden Sie, wo möglich, eine ungerade Anzahl von Hosts in einem geclusterten Pool, da dies sicherstellt, dass Hosts immer feststellen können, ob sie ein Quorum haben. Wir empfehlen, die Clusterbildung nur in Pools mit mindestens drei Hosts zu verwenden, da Pools mit zwei Hosts anfällig für das Selbst-Fencing des gesamten Pools sind.

  Geclusterte Pools unterstützen nur bis zu 16 Hosts pro Pool.

• Alle XenServer-Hosts im geclusterten Pool müssen mindestens 2 GiB Kontrolldomänen-Speicher haben.
• Alle Hosts im Cluster müssen statische IP-Adressen für das Clusternetzwerk verwenden.
• Wenn Sie einen vorhandenen Pool clustern, stellen Sie sicher, dass Hochverfügbarkeit deaktiviert ist. Sie können die Hochverfügbarkeit wieder aktivieren, nachdem die Clusterbildung aktiviert wurde.

So erstellen Sie einen geclusterten Pool mit der xe CLI:

1. Erstellen Sie einen Ressourcenpool mit mindestens drei XenServer-Hosts.

   Wiederholen Sie die folgenden Schritte auf jedem beitretenden XenServer-Host, der nicht der Pool-Koordinator ist:

   1. Öffnen Sie eine Konsole auf dem XenServer-Host.

   2. Fügen Sie den XenServer-Host dem Pool auf dem Pool-Koordinator mit dem folgenden Befehl hinzu:

      xe pool-join master-address=<master_address> /
          master-username=<administrators_username> /
          master-password=<password>
      <!--NeedCopy-->
      

      Der Wert des master-address-Parameters muss auf den vollqualifizierten Domänennamen des XenServer-Hosts gesetzt werden, der der Pool-Koordinator ist. Das password muss das Administratorpasswort sein, das bei der Installation des Pool-Koordinators festgelegt wurde.

   Weitere Informationen finden Sie unter Hosts und Ressourcenpools.

2. Stellen Sie für jede PIF, die zu diesem Netzwerk gehört, disallow-unplug=true ein.

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

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

   2. Führen Sie den folgenden Befehl auf einem XenServer-Host 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 XenServer-Host in Ihrem Ressourcenpool aus:

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

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

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

Wenn Sie nicht genügend Steuerdomänenspeicher auf Ihren Hosts haben, kann Ihr Pool Netzwerkinstabilität erfahren. Netzwerkinstabilität kann Probleme für einen geclusterten Pool mit GFS2-SRs verursachen.

Es ist wichtig sicherzustellen, dass Ihr geclusterter Pool über eine angemessene Menge an Steuerdomänenspeicher verfügt. Informationen zum Ändern der Menge des Steuerdomänenspeichers und zur Überwachung des Speicherverhaltens finden Sie unter Speichernutzung.

6. Speichermultipathing konfigurieren

Stellen Sie sicher, dass Speichermultipathing zwischen Ihrem geclusterten Pool und Ihrem GFS2-SR eingerichtet ist.

Multipathing leitet Speicherverkehr über mehrere Pfade zu einem Speichergerät, um Redundanz zu gewährleisten. Alle Pfade können während des normalen Betriebs aktiven Datenverkehr aufweisen, was zu einem erhöhten Durchsatz führt.

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

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

  Beispielsweise gibt ein iSCSI-Speicher-Backend, das nach sendtargets auf einem bestimmten 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 zusätzliche Konfigurationen vornehmen, 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 Ziel verfügbar machen.

• Nur für iSCSI: Die Steuerdomäne (dom0) hat eine IP-Adresse in jedem Subnetz, das vom Multipath-Speicher verwendet wird.

  Stellen Sie sicher, dass für jeden Pfad zum Speicher eine NIC vorhanden ist und auf jeder NIC eine IP-Adresse konfiguriert ist. Wenn Sie beispielsweise vier Pfade zu Ihrem Speicher wünschen, müssen Sie vier NICs haben, auf denen jeweils eine IP-Adresse konfiguriert ist.

• Nur für iSCSI: Jedes iSCSI-Ziel und jeder Initiator hat einen eindeutigen IQN.

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

• Nur für HBA: Mehrere HBAs sind mit dem Switch-Fabric verbunden.

• Verwenden Sie, wenn möglich, mehrere redundante Switches.

Multipathing mit der xe-CLI aktivieren

Wir empfehlen, Multipathing für alle Hosts in Ihrem Pool vor dem Erstellen des SR zu aktivieren. Wenn Sie den SR vor der Aktivierung von Multipathing erstellen, müssen Sie Ihre Hosts in den Wartungsmodus versetzen, um Multipathing zu aktivieren.

1. Öffnen Sie eine Konsole auf dem XenServer-Host.

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-list verwenden, um die UUID der PBDs zu finden.

3. Legen Sie den Wert des Parameters multipathing auf true fest, 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, vorhandene SRs mit mehreren Pfaden vorhanden sind:

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

   • Schließen Sie die PBD aller betroffenen SRs erneut 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. Alle Verkabelungen und, im Falle von iSCSI, Subnetzkonfigurationen müssen mit den entsprechenden NICs auf jedem Host übereinstimmen.

Weitere Informationen finden Sie unter Speicher-Multipathing.

7. Erstellen eines GFS2-SR

Erstellen Sie Ihr freigegebenes GFS2-SR auf einem iSCSI- oder HBA-LUN, das für alle XenServer-Hosts in Ihrem Ressourcenpool sichtbar ist. Wir empfehlen nicht, ein Thin-Provisioned-LUN mit GFS2 zu verwenden. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie sicherstellen, dass das LUN immer genügend Speicherplatz hat, damit XenServer darauf schreiben kann.

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

Wenn Sie Ihr blockbasiertes Speichergerät zuvor für die Thick Provisioning mit LVM verwendet haben, wird dies von XenServer 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 die xe CLI verwenden, um ein GFS2 über iSCSI-SR zu erstellen.

Gerätekonfigurationsparameter für GFS2-SRs:

Die Werte für diese Parameter finden Sie mit dem Befehl xe sr-probe-ext.

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 listet bei jedem Schritt mögliche Werte auf.

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

3. Wenn die Befehlsausgabe mit Found the following complete configurations that can be used to create SRs: beginnt, können Sie den SR mithilfe des Befehls xe sr-create und der von Ihnen angegebenen Parameter device-config finden.

   Beispielausgabe:

   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 einen freigegebenen GFS2-SR auf einer bestimmten LUN eines iSCSI-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem geclusterten Pool 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 geclusterten Pool einen Hard-Restart (Fencing) durchführen.

Weitere Informationen zur Arbeit mit iSCSI-SRs finden Sie unter Software-iSCSI-Speicher.

Freigegebenen GFS2 über HBA SR erstellen

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

Gerätekonfigurationsparameter für GFS2-SRs:

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

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

1. Beginnen Sie mit der Ausführung des folgenden Befehls:

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

   Die Ausgabe des Befehls fordert Sie auf, zusätzliche Parameter anzugeben, und listet bei jedem Schritt mögliche Werte auf.

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

3. Wenn die Befehlsausgabe mit Found the following complete configurations that can be used to create SRs: beginnt, können Sie den SR mithilfe des Befehls xe sr-create und der von Ihnen angegebenen Parameter device-config finden.

   Beispielausgabe:

   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 einen freigegebenen GFS2-SR auf einer bestimmten LUN eines HBA-Ziels zu erstellen, führen Sie den folgenden Befehl auf einem Server in Ihrem geclusterten Pool 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 zur Arbeit mit HBA-SRs finden Sie unter Hardware-HBA-Speicher.

Wie geht es weiter?

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

Wenn Sie Probleme mit Ihrer GFS2-Umgebung haben, lesen Sie Fehlerbehebung bei geclusterten Pools.

Sie können Ihr GFS2-SR auf die gleiche Weise verwalten wie andere SRs. Sie können beispielsweise die Speicherkapazität des Speicher-Arrays erhöhen, um die Größe des LUN zu vergrößern. Weitere Informationen finden Sie unter Live-LUN-Erweiterung.

Einschränkungen

Der gemeinsam genutzte GFS2-Speicher weist derzeit die folgenden Einschränkungen auf:

• Intellicache™ wird für VMs, die ein GFS2-SR verwenden, nicht unterstützt.

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

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

• Die 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 VDIs auch nicht von einem anderen SR-Typ auf ein GFS2-SR migrieren.

• Der Software-FCoE-Transport wird mit GFS2-SRs nicht unterstützt (für vollständig ausgelagertes FCoE verwenden Sie HBA).

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

• CHAP wird auf GFS2-SRs 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 die Verwendung eines Thin-Provisioned-LUN mit GFS2 nicht. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie sicherstellen, dass das LUN immer genügend Speicherplatz hat, damit XenServer darauf schreiben kann.

• Wir empfehlen die Verwendung von SAN-Deduplizierung mit GFS2-SRs nicht. Wenn Sie sich jedoch für diese Konfiguration entscheiden, müssen Sie eine geeignete externe Überwachung Ihrer SAN-Auslastung verwenden, um sicherzustellen, dass immer genügend Speicherplatz für XenServer 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.

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

• Um HA in Ihrem geclusterten Pool zu aktivieren, muss der Heartbeat-SR ein GFS2 SR sein.

• Für den Cluster-Datenverkehr empfehlen wir dringend, dass Sie ein gebündeltes Netzwerk verwenden, das mindestens zwei verschiedene Netzwerk-Switches nutzt. Verwenden Sie dieses Netzwerk nicht für andere Zwecke.

• Das Ändern der IP-Adresse des Clusternetzwerks mithilfe von XenCenter erfordert, dass Clustering und GFS2 vorübergehend deaktiviert werden.

• Ändern Sie die Bündelung Ihres Clusternetzwerks nicht, während der Cluster aktiv ist und VMs ausgeführt werden. Diese Aktion kann dazu führen, dass Hosts im Cluster einen harten Neustart durchführen (Fencing).

• Wenn ein IP-Adresskonflikt (mehrere Hosts haben dieselbe IP-Adresse) in Ihrem Clusternetzwerk vorliegt, der mindestens einen Host mit aktiviertem Clustering betrifft, 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.