layout: doc—
Hinweis:
XenCenter yyyy.x.x wird noch nicht für die Verwendung mit Citrix Hypervisor 8.2 CU1 in Produktionsumgebungen unterstützt. Verwenden Sie XenCenter 8.2.7, um Ihre Citrix Hypervisor 8.2 CU1-Produktionsumgebung zu verwalten. Weitere Informationen finden Sie in der XenCenter 8.2.7-Dokumentation.
Sie können XenCenter 8.2.7 und XenCenter yyyy.x.x auf demselben System installieren. Die Installation von XenCenter yyyy.x.x überschreibt Ihre XenCenter 8.2.7-Installation nicht.
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:
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.
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 XenServer, dass Sie einen Clusterpool mit Ihrem GFS2 SR verwenden. Wir empfehlen Ihnen außerdem, Ihre Umgebung zu entwerfen und die XenServer-Funktionen so zu konfigurieren, dass sie so viel Stabilität und Redundanz wie möglich bieten.
Bevor Sie Ihren XenServer-Pool für die Verwendung mit GFS2-SRs einrichten, sollten Sie die folgenden Anforderungen und Empfehlungen für eine ideale GFS2-Umgebung lesen:
Empfehlung: Konfigurieren Sie eine redundante Netzwerkinfrastruktur.
Empfohlen: Erstellen Sie ein dediziertes gebundenesNetzwerk
Erforderlich: Richten Sie einen Clusterpool ein
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.
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.
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.
Hinweis:
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 XenServer verwendete Kommunikationsports.
So erstellen Sie ein gebundenes Netzwerk, das als Clusternetzwerk verwendet werden soll:
Wählen Sie im Bond-Modus die Art der Bindung aus:
Hinweise:
- Um die LACP-Bonding-Optionen in XenCenter anzeigen und eine LACP-Bindung erstellen zu können, konfigurieren Sie vSwitch als Netzwerk-Stack. Außerdem müssen Ihre Switches den IEEE 802.3ad-Standard unterstützen.
- Aktiv-aktive und aktiv-passive Bindungstypen sind sowohl für die vSwitch- als auch für die Linux-Brücke verfügbar.
- Sie können zwei, drei oder vier Netzwerkkarten verbinden, wenn vSwitch der Netzwerkstapel ist. Sie können jedoch nur zwei Netzwerkkarten verbinden, wenn die Linux-Brücke der Netzwerkstapel ist.
Nachdem Sie Ihr gebundenes Netzwerk auf dem Poolkoordinator erstellt haben und andere XenServer-Hosts mit dem Pool verbinden, werden die Netzwerk- und Bindungsinformationen automatisch auf den beitretenden Server repliziert.
Weitere Informationen finden Sie unter Konfigurieren von NICs.
Hinweise:
- 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.
Um gemeinsam genutzten GFS2-Speicher zu verwenden, muss der XenServer-Ressourcenpool ein Clusterpool sein. Aktivieren Sie das Clustering in Ihrem Pool, bevor Sie ein GFS2-SR erstellen.
So erstellen Sie einen Clusterpool:
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.
Um Multipathing zu aktivieren:
Führen Sie die folgenden Schritte für jeden Server in Ihrem Pool aus:
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.
Erstellen Sie Ihre gemeinsam genutzte GFS2 SR auf einer iSCSI- oder HBA-LUN, die für alle XenServer-Hosts 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 XenServer darauf schreiben kann.
Sie können einem Clusterpool bis zu 62 GFS2-SRs hinzufügen.
Hinweis:
Bevor Sie die folgenden Schritte ausführen, stellen Sie sicher, dass der iSCSI-Initiator-IQN für alle Hosts im Pool entsprechend eingestellt ist. Weitere Informationen finden Sie unter Ändern der Servereigenschaften.
Geben Sie auf der Seite Standort die Details des iSCSI-Ziels an:
Zielhost: Die IP-Adresse oder der DNS-Name des iSCSI-Ziels. Dies kann auch eine kommagetrennte Werteliste sein.
CHAP verwenden: Dies wird mit GFS2-SRs nicht unterstützt. Lassen Sie diese Option nicht ausgewählt.
Ziel-IQN: Um den iSCSI-Ziel-IQN anzugeben, klicken Sie auf die Schaltfläche IQNs ermitteln und wählen Sie dann einen IQN aus der Liste Ziel-IQN aus.
Wichtig:
Das iSCSI-Ziel und alle Server im Pool dürfen nicht über denselben IQN verfügen. Jedes iSCSI-Ziel und jeder Initiator muss über einen eindeutigen IQN verfügen. Wenn eine nicht eindeutige IQN-ID verwendet wird, kann es zu Datenbeschädigungen kommen, der Zugriff auf das Ziel kann verweigert werden oder beides.
Ziel-LUN: Um die LUN anzugeben, auf der das Speicherrepository erstellt werden soll, klicken Sie auf die Schaltfläche Discover LUNs . Wählen Sie eine LUN aus der Liste Ziel-LUN aus.
Jedes einzelne iSCSI-Speicherrepository muss vollständig in einer einzigen LUN enthalten sein. Das SR kann nicht mehr als eine LUN umfassen. Wenn die LUN bereits ein SR enthält, wählen Sie, ob Sie das vorhandene SR verwenden oder das vorhandene SR durch ein neues ersetzen möchten. Durch Ersetzen des vorhandenen SRs werden alle auf dem Datenträger vorhandenen Daten zerstört.
Der Assistent sucht nach verfügbaren LUNs und zeigt dann eine Seite mit allen gefundenen LUNs an. Wählen Sie eine LUN aus der Liste aus und klicken Sie auf Erstellen.
Hinweis:
Eine Warnmeldung wird angezeigt, wenn SRs auf der ausgewählten LUN vorhanden sind. Überprüfen Sie die Details und wählen Sie eine der folgenden Optionen.
- Um das Bestehende zu verwenden, klicken Sie auf Erneut anhängen.
- Um das vorhandene SR zu löschen und ein SR zu erstellen, klicken Sie auf Format.
- Wenn Sie lieber eine andere LUN auswählen möchten, klicken Sie auf Abbrechen und wählen Sie eine LUN aus der Liste aus.
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 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.
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 XenServer 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 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.