GFS2-Cluster-Pools
GFS2-Clustering bietet zusätzliche Funktionen, die für Ressourcen-Pools erforderlich sind, die GFS2-SRs verwenden. Weitere Informationen zu GFS2 finden Sie unter Speicher konfigurieren.
Ein GFS2-Cluster ist ein Pool von bis zu 16 XenServer®-Hosts, die enger miteinander verbunden und koordiniert sind als Hosts in nicht-geclusterten Pools. Die Hosts im GFS2-Cluster kommunizieren ständig über ein ausgewähltes Netzwerk miteinander. Alle Hosts im GFS2-Cluster kennen den Status jedes Hosts im GFS2-Cluster. Diese Host-Koordination ermöglicht es dem GFS2-Cluster, den Zugriff auf die Inhalte des GFS2-SR zu steuern.
Hinweis:
Die GFS2-Clustering-Funktion ist nur für Pools von Vorteil, die einen GFS2-SR enthalten. Wenn Ihr Pool keinen GFS2-SR enthält, aktivieren Sie GFS2-Clustering nicht in Ihrem Pool.
Quorum
Jeder Host in einem GFS2-Cluster muss immer mit der Mehrheit der Hosts im GFS2-Cluster (einschließlich sich selbst) in Kommunikation stehen. Dieser Zustand wird als Quorum eines Hosts bezeichnet. Wenn ein Host kein Quorum hat, isoliert sich dieser Host selbst.
Die Anzahl der Hosts, die kommunizieren müssen, um anfänglich ein Quorum zu erreichen, kann sich von der Anzahl der Hosts unterscheiden, die ein GFS2-Cluster benötigt, um das Quorum aufrechtzuerhalten.
Die folgende Tabelle fasst dieses Verhalten zusammen. Der Wert von n ist die Gesamtzahl der Hosts im GFS2-Cluster-Pool.
| Anzahl der Hosts, die zum Erreichen des Quorums erforderlich sind | Anzahl der Hosts, die erforderlich sind, um quorumfähig zu bleiben | |
|---|---|---|
| Ungerade Anzahl von Hosts im Pool | (n+1)/2 | (n+1)/2 |
| Gerade Anzahl von Hosts im Pool | (n/2)+1 | n/2 |
Für einen GFS2-Cluster-Pool können Sie überprüfen, ob der Pool Quorum hat, indem Sie den is-quorate Parameter des GFS2-Clusters abfragen:
xe cluster-list params=is-quorate uuid=<cluster_id>
Um zu sehen, wie viele Hosts im GFS2-Cluster aktiv sind, führen Sie den folgenden Befehl aus:
xe cluster-list params=live-hosts uuid=<cluster_id>
Um zu sehen, wie viele aktive Hosts erforderlich sind, damit der GFS2-Cluster Quorum erreicht, führen Sie den folgenden Befehl aus:
xe cluster-list params=quorum uuid=<cluster_id>
Wenn der GFS2-Cluster erstellt wird, muss die Anzahl der aktiven Hosts größer oder gleich diesem Wert sein. Um das Quorum aufrechtzuerhalten, kann die erforderliche Anzahl von Hosts von dem durch diesen Befehl zurückgegebenen Wert abweichen, je nachdem, ob der GFS2-Cluster eine ungerade oder gerade Anzahl von Hosts enthält.
Ungerade Pools
Um den Quorum-Wert für einen Pool mit ungerader Anzahl von Hosts zu erreichen, benötigen Sie die Hälfte der um eins erhöhten Gesamtzahl der Hosts im GFS2-Cluster: (n+1)/2. Dies ist auch die Mindestanzahl von Hosts, die erreichbar bleiben müssen, damit der Pool quoriert bleibt.
Zum Beispiel müssen in einem GFS2-Cluster-Pool mit 5 Hosts 3 Hosts erreichbar sein, damit der GFS2-Cluster sowohl aktiv wird als auch quoriert bleibt [(5+1)/2 = 3].
Wo immer möglich, wird empfohlen, eine ungerade Anzahl von Hosts in einem GFS2-Cluster-Pool zu verwenden, da dies sicherstellt, dass Hosts immer feststellen können, ob sie ein quoriertes Set haben.
Gerade Pools
Wenn ein GFS2-Cluster-Pool mit gerader Anzahl von Hosts von einem Kaltstart hochfährt, müssen (n/2)+1 Hosts verfügbar sein, bevor die Hosts Quorum haben. Nachdem die Hosts Quorum haben, wird der GFS2-Cluster aktiv.
Ein aktiver Pool mit gerader Anzahl von Hosts kann jedoch quoriert bleiben, wenn die Anzahl der erreichbaren Hosts mindestens n/2 beträgt. Infolgedessen kann sich ein laufender GFS2-Cluster mit einer geraden Anzahl von Hosts genau in zwei Hälften teilen. Der laufende GFS2-Cluster entscheidet, welche Hälfte des GFS2-Clusters sich selbst abschottet und welche Hälfte des GFS2-Clusters Quorum hat. Die Hälfte des GFS2-Clusters, die den Knoten mit der niedrigsten ID enthält, der vor der Aufteilung des GFS2-Clusters als aktiv angesehen wurde, bleibt aktiv, und die andere Hälfte des GFS2-Clusters schottet sich selbst ab.
Zum Beispiel müssen in einem GFS2-Cluster-Pool mit 4 Hosts 3 Hosts erreichbar sein, damit der GFS2-Cluster aktiv wird [4/2 + 1 = 3]. Nachdem der GFS2-Cluster aktiv ist, müssen, um quoriert zu bleiben, nur 2 Hosts erreichbar sein [4/2 = 2], und dieses Set von Hosts muss den Host mit der niedrigsten bekannten aktiven Knoten-ID enthalten.
Selbstabschottung
Wenn ein Host feststellt, dass er kein Quorum hat, schottet er sich innerhalb weniger Sekunden selbst ab. Wenn sich ein Host selbst abschottet, startet er sofort neu. Alle auf dem Host ausgeführten VMs werden sofort gestoppt, da der Host einen Hard-Shutdown durchführt. In einem GFS2-Cluster-Pool, der Hochverfügbarkeit verwendet, startet XenServer die VMs gemäß ihrer Neustartkonfiguration auf anderen Poolmitgliedern neu. Der Host, der sich selbst abgeschottet hat, startet neu und versucht, dem GFS2-Cluster wieder beizutreten.
Wenn die Anzahl der aktiven Hosts im GFS2-Cluster unter den Quorum-Wert fällt, verlieren alle verbleibenden Hosts das Quorum.
In einem idealen Szenario verfügt Ihr GFS2-Cluster-Pool immer über mehr aktive Hosts, als für das Quorum erforderlich sind, und XenServer schottet sich niemals ab. Um dieses Szenario wahrscheinlicher zu machen, beachten Sie die folgenden Empfehlungen beim Einrichten Ihres GFS2-Cluster-Pools:
-
Stellen Sie sicher, dass Sie eine gute Hardware-Redundanz haben.
-
Verwenden Sie ein dediziertes gebündeltes Netzwerk für das GFS2-Clusternetzwerk. Stellen Sie sicher, dass sich die gebündelten NICs auf demselben L2-Segment befinden. Weitere Informationen finden Sie unter Netzwerk.
-
Konfigurieren Sie Speicher-Multipathing zwischen dem Pool und dem GFS2-SR. Weitere Informationen finden Sie unter Speicher-Multipathing.
Einen GFS2-Cluster-Pool erstellen
Stellen Sie vor dem Start sicher, dass die folgenden Voraussetzungen erfüllt sind:
-
Alle XenServer-Hosts im GFS2-Cluster-Pool müssen mindestens 2 GiB Kontrolldomänen-Speicher haben.
Abhängig von Ihrer Umgebung benötigen Ihre Hosts möglicherweise mehr Kontrolldomänen-Speicher als diesen. Wenn Sie nicht genügend Kontrolldomänen-Speicher auf Ihren Hosts haben, kann Ihr Pool Netzwerkinstabilität erfahren. Netzwerkinstabilität kann Probleme für einen GFS2-Cluster-Pool mit GFS2-SRs verursachen. Informationen zum Ändern der Menge des Kontrolldomänen-Speichers und zur Überwachung des Speicherverhaltens finden Sie unter Speichernutzung.
-
Alle Hosts im GFS2-Cluster müssen statische IP-Adressen für das GFS2-Clusternetzwerk verwenden.
-
Wir empfehlen, GFS2-Clustering nur in Pools mit mindestens drei Hosts zu verwenden, da Pools mit zwei Hosts anfällig für die Selbstabschottung des gesamten Pools sind.
-
GFS2-Cluster-Pools unterstützen nur bis zu 16 Hosts pro Pool.
- Wenn Sie eine Firewall zwischen den Hosts in Ihrem Pool haben, stellen Sie sicher, dass die Hosts im GFS2-Clusternetzwerk über die folgenden Ports kommunizieren können:
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
Weitere Informationen finden Sie unter Von XenServer verwendete Kommunikationsports.
-
Wenn Sie einem vorhandenen Pool GFS2-Clustering hinzufügen, stellen Sie sicher, dass Hochverfügbarkeit deaktiviert ist. Sie können die Hochverfügbarkeit wieder aktivieren, nachdem GFS2-Clustering aktiviert wurde.
- Wir empfehlen dringend, für Ihren GFS2-Cluster-Pool ein gebündeltes Netzwerk zu verwenden, das nicht für anderen Datenverkehr genutzt wird.
Wenn Sie möchten, können Sie GFS2-Clustering in Ihrem Pool mit XenCenter einrichten. Weitere Informationen finden Sie in der XenCenter-Produktdokumentation.
So erstellen Sie einen GFS2-Cluster-Pool mit der xe-CLI:
-
Erstellen Sie ein gebündeltes Netzwerk, das als GFS2-Clusternetzwerk verwendet werden soll.
Hinweis:
Wir empfehlen dringend, ein dediziertes gebündeltes Netzwerk für Ihren GFS2-Cluster-Pool zu verwenden. Verwenden Sie dieses Netzwerk nicht für anderen Datenverkehr.
Führen Sie auf dem XenServer-Host, der der Pool-Koordinator sein soll, die folgenden Schritte aus:
-
Öffnen Sie eine Konsole auf dem XenServer-Host.
-
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.
-
Suchen Sie die UUIDs der PIFs, die in der Bond verwendet werden sollen, indem Sie den folgenden Befehl verwenden:
xe pif-list <!--NeedCopy--> -
Erstellen Sie Ihr gebündeltes Netzwerk entweder im Active-Active-Modus, Active-Passive-Modus oder LACP-Bond-Modus. Je nachdem, welchen Bond-Modus Sie verwenden möchten, führen Sie eine der folgenden Aktionen aus:
-
Um die Bond im Aktiv-Aktiv-Modus (Standard) zu konfigurieren, verwenden Sie den Befehl
bond-create, um die Bond zu erstellen. Trennen Sie die Parameter durch Kommas und geben Sie die neu erstellte Netzwerk-UUID und die UUIDs der zu bondenden 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 die Bond wird nach Ausführung des Befehls zurückgegeben.
-
Um die Bond im Aktiv-Passiv- oder LACP-Bond-Modus zu konfigurieren, verwenden Sie dieselbe Syntax, fügen Sie den optionalen Parameter
modehinzu und geben Sielacpoderactive-backupan: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.
-
-
Erstellen Sie einen Ressourcenpool mit mindestens drei XenServer-Hosts.
Wiederholen Sie die folgenden Schritte auf jedem XenServer-Host, der ein (Nicht-Master-)Poolmitglied ist:
- Öffnen Sie eine Konsole auf dem XenServer-Host.
-
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 Parameters
master-addressmuss auf den vollqualifizierten Domänennamen des XenServer-Hosts gesetzt werden, der der Pool-Koordinator ist.passwordmuss das Administratorpasswort sein, das bei der Installation des Pool-Koordinators festgelegt wurde.
Weitere Informationen finden Sie unter Hosts und Ressourcenpools.
-
Setzen Sie für jede PIF, die zu diesem Netzwerk gehört,
disallow-unplug=true.-
Suchen Sie die UUIDs der PIFs, die zu diesem Netzwerk gehören, indem Sie den folgenden Befehl verwenden:
xe pif-list <!--NeedCopy--> -
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-->
-
-
Aktivieren Sie GFS2-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.
GFS2-Clustering deaktivieren
Sie können das GFS2-Clustering deaktivieren. Nachdem Sie das GFS2-Clustering deaktiviert haben, existiert der Pool weiterhin, ist aber nicht mehr GFS2-geclustert und kann keine GFS2-SRs mehr verwenden.
Um das GFS2-Clustering zu deaktivieren, führen Sie den folgenden Befehl aus:
xe cluster-pool-destroy cluster-uuid=<uuid>
Ihren GFS2-Cluster-Pool verwalten
Bei der Verwaltung Ihres GFS2-Cluster-Pools können die folgenden Praktiken das Risiko verringern, dass der Pool das Quorum verliert.
Host zu einem GFS2-Cluster-Pool hinzufügen oder daraus entfernen
Stellen Sie beim Hinzufügen oder Entfernen eines Hosts in einem GFS2-Cluster-Pool sicher, dass alle Hosts im GFS2-Cluster online sind.
Sie können einen Host in einem GFS2-Cluster-Pool mit XenCenter hinzufügen oder entfernen. Weitere Informationen finden Sie unter Server zu einem Pool hinzufügen und Server aus einem Pool entfernen.
Sie können einen Host auch über die xe-CLI zu einem GFS2-Cluster-Pool hinzufügen oder daraus entfernen. Weitere Informationen finden Sie unter Hinzufügen eines Hosts zu einem Pool mithilfe der xe-CLI und Entfernen von XenServer-Hosts aus einem Ressourcenpool.
Sicherstellen, dass Hosts sauber heruntergefahren werden
Wenn ein Host sauber heruntergefahren wird, wird er vorübergehend aus dem GFS2-Cluster entfernt, bis er wieder gestartet wird. Während der Host heruntergefahren ist, zählt er nicht zum Quorum des GFS2-Clusters. Die Abwesenheit des Hosts führt nicht dazu, dass andere Hosts das Quorum verlieren. Weitere Informationen finden Sie unter Herunterfahren eines XenServer-Hosts.
Wird ein Host jedoch zwangsweise oder unerwartet heruntergefahren, wird er nicht aus dem GFS2-Cluster entfernt, bevor er offline geht. Dieser Host zählt zum Quorumwert des GFS2-Clusters. Sein Herunterfahren kann dazu führen, dass andere Hosts das Quorum verlieren.
Wenn es notwendig ist, einen Host zwangsweise herunterzufahren, überprüfen Sie zuerst, wie viele Live-Hosts sich im GFS2-Cluster befinden. Dies können Sie mit dem Befehl corosync-quorumtool tun. In der Befehlsausgabe ist die Anzahl der Live-Hosts der Wert von Total votes: und die Anzahl der Live-Hosts, die zum Beibehalten des Quorums erforderlich sind, der Wert von Quorum:.
-
Wenn die Anzahl der Live-Hosts der Anzahl der Hosts entspricht, die zum Erhalt des Quorums erforderlich sind, fahren Sie den Host nicht zwangsweise herunter. Andernfalls führt dies dazu, dass der gesamte GFS2-Cluster abgeschottet wird.
Versuchen Sie stattdessen, andere Hosts wiederherzustellen und die Anzahl der aktiven Hosts zu erhöhen, bevor Sie den Host zwangsweise herunterfahren.
-
Wenn die Anzahl der aktiven Hosts nahe an der Anzahl der Hosts liegt, die für die Aufrechterhaltung des Quorums erforderlich sind, können Sie den Host zwangsweise herunterfahren. Dies macht den GFS2-Cluster jedoch anfälliger für ein vollständiges Fencing, wenn andere Hosts im Pool Probleme haben.
Versuchen Sie immer, den heruntergefahrenen Host so schnell wie möglich neu zu starten, um die Ausfallsicherheit Ihres GFS2-Clusters zu erhöhen.
Wartungsmodus verwenden
Bevor Sie auf einem Host etwas tun, das dazu führen könnte, dass dieser Host das Quorum verliert, versetzen Sie den Host in den Wartungsmodus. Wenn sich ein Host im Wartungsmodus befindet, werden laufende VMs von ihm auf einen anderen Host im Pool migriert. Wenn dieser Host der Pool-Koordinator war, wird diese Rolle an einen anderen Host im Pool übergeben. Wenn Ihre Aktionen dazu führen, dass sich ein Host im Wartungsmodus selbst absichert, verlieren Sie keine VMs und auch nicht Ihre XenCenter®-Verbindung zum Pool.
Hosts im Wartungsmodus zählen weiterhin zum Quorumwert für den GFS2-Cluster.
Sie können die IP-Adresse eines Hosts, der Teil eines GFS2-Cluster-Pools ist, nur ändern, wenn sich dieser Host im Wartungsmodus befindet. Das Ändern der IP-Adresse eines Hosts führt dazu, dass der Host den GFS2-Cluster verlässt. Nachdem die IP-Adresse erfolgreich geändert wurde, tritt der Host dem GFS2-Cluster wieder bei. Nachdem der Host dem GFS2-Cluster wieder beigetreten ist, können Sie ihn aus dem Wartungsmodus nehmen.
Hosts wiederherstellen, die sich selbst abgesichert haben oder offline sind
Es ist wichtig, Hosts wiederherzustellen, die sich selbst abgesichert haben. Solange diese GFS2-Clustermitglieder offline sind, zählen sie zum Quorumwert für den GFS2-Cluster und verringern die Anzahl der GFS2-Clustermitglieder, die erreichbar sind. Diese Situation erhöht das Risiko, dass ein nachfolgender Host-Ausfall dazu führt, dass der GFS2-Cluster das Quorum verliert und vollständig heruntergefahren wird.
Offline-Hosts in Ihrem GFS2-Cluster verhindern auch, dass Sie bestimmte Aktionen ausführen können. In einem GFS2-Cluster-Pool muss jedes Mitglied des Pools jeder Änderung der Pool-Mitgliedschaft zustimmen, bevor die Änderung erfolgreich sein kann. Wenn ein GFS2-Clustermitglied nicht erreichbar ist, verhindert XenServer Operationen, die die GFS2-Cluster-Mitgliedschaft ändern (z. B. Hinzufügen oder Entfernen von Hosts).
Hosts als nicht wiederherstellbar markieren
Wenn ein oder mehrere Offline-Hosts nicht wiederhergestellt werden können, können Sie dem GFS2-Cluster-Pool mitteilen, sie zu vergessen. Diese Hosts werden dauerhaft aus dem Pool entfernt. Nachdem Hosts aus dem GFS2-Cluster-Pool entfernt wurden, zählen sie nicht mehr zum Quorumwert.
Um einen Host als nicht wiederherstellbar zu markieren, verwenden Sie den folgenden Befehl:
xe host-forget uuid=<host_uuid>
Einen vergessenen Host wiederherstellen
Nachdem einem GFS2-Cluster-Pool mitgeteilt wurde, einen Host zu vergessen, kann der Host nicht wieder zum Pool hinzugefügt werden.
Um dem GFS2-Cluster-Pool wieder beizutreten, müssen Sie XenServer auf dem Host neu installieren, damit er dem Pool als neuer Host erscheint. Anschließend können Sie den Host auf die übliche Weise dem GFS2-Cluster-Pool hinzufügen.
Fehlerbehebung für Ihren GFS2-Cluster-Pool
Wenn Probleme mit Ihrem GFS2-Cluster-Pool auftreten, lesen Sie Fehlerbehebung bei GFS2-Cluster-Pools.
Einschränkungen
- GFS2-Cluster-Pools unterstützen nur bis zu 16 Hosts pro Pool.
- Um HA in Ihrem GFS2-Cluster-Pool zu aktivieren, muss der Heartbeat-SR ein GFS2-SR sein.
- Für den GFS2-Cluster-Datenverkehr empfehlen wir dringend, ein gebündeltes Netzwerk zu verwenden, das mindestens zwei verschiedene Netzwerk-Switches nutzt. Verwenden Sie dieses Netzwerk nicht für andere Zwecke.
- Das Ändern der IP-Adresse des GFS2-Clusternetzwerks mithilfe von XenCenter erfordert, dass GFS2-Clustering und alle GFS2-SRs vorübergehend deaktiviert werden.
- Ändern Sie die Bündelung Ihres GFS2-Clusternetzwerks nicht, während der GFS2-Cluster aktiv ist und VMs ausgeführt werden. Diese Aktion kann dazu führen, dass Hosts im GFS2-Cluster hart neu starten (Fencing).
- Wenn Sie einen IP-Adresskonflikt (mehrere Hosts mit derselben IP-Adresse) in Ihrem GFS2-Clusternetzwerk haben, an dem mindestens ein Host mit aktiviertem GFS2-Clustering beteiligt ist, wird der GFS2-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.