Hinzufügen von Knoten zu einer Konfiguration mit hoher Verfügbarkeit

Fügen Sie Knoten zum primären Hochverfügbarkeits-Rechenzentrum (HA) hinzu. Dies soll CPU-intensive Aufgaben vom primären Knotenpunkt verlagern, um eine horizontale Skalierung der GitHub Enterprise Server Instanz zu ermöglichen.

In diesem Artikel

Hinweis

Die Möglichkeit, HA um zusätzliche Computeknoten zu erweitern, befindet sich in öffentliche Vorschau und kann geändert werden. Teilen Sie während der Vorschau ihr Feedback mit Ihrem Kundenerfolgsteam.

Für GitHub Enterprise Server Kunden, die eine horizontale Skalierung anstreben, ist die Migration zu einem Cluster und dessen Betrieb eine Option, die jedoch ressourcenintensiv und zeitaufwendig ist. Alternativ empfehlen wir das Hinzufügen von Knoten zu einer HA-Konfiguration.

Die Begriffe "zusätzlicher Knoten" und "zustandsloser Knoten" werden in diesem Artikel austauschbar verwendet. Zustandslose Knoten können nur zu HA-Bereitstellungen hinzugefügt werden, die mindestens ein Replikat enthalten.

Zusätzliche Knoten

Von allen Diensten, die auf einer GitHub Enterprise Server Appliance ausgeführt werden, ist Unicorn häufig die cpu- und arbeitsspeicherintensivste, gefolgt von Aqueduct, Git und MySQL. Da Unicorn und Aqueduct zustandslose Dienste sind, eignen sie sich gut für die horizontale Skalierung und können auf einer separaten Gruppe von Knoten ausgeführt werden. Die verbleibenden Dienste können weiterhin mit einer einzelnen Instanz pro Rechenzentrum arbeiten.

Mit zusätzlichen Knoten können Sie Web- und Auftragsworkloads horizontal skalieren. Sie können Unicorn und Aqueduct auch vom primären Knoten auslagern und dadurch erhebliche Compute- und Speicherressourcen für die verbleibenden zustandsbehafteten Dienste freigeben. Wenn leistungsbezogene Ausfälle aufgrund einer hohen CPU-Auslastung durch Unicorn-Instanzen auftreten, wird das Hinzufügen zusätzlicher Knoten empfohlen. Es gibt keine erheblichen Einschränkungen für die Anzahl dieser Knoten, die Sie innerhalb eines Rechenzentrums hinzufügen können.

Kriterien

Wenn die Leistung aufgrund eines überladenen primären Knotens in einer HA-Konfiguration beeinträchtigt wird, sollten Sie in Betracht ziehen, ihrer HA-Umgebung zusätzliche Knoten hinzuzufügen. Durch die horizontale Skalierung von Web- und Auftragsrollen über den primären Knoten hinaus können diese zusätzlichen Knoten dazu beitragen, die Last auf dem primären Host zu reduzieren.

Wenn Sie beispielsweise Backlogs in Unicorn- oder Aqueduct-Warteschlangen bemerken oder andere Arten von Ressourcenkonflikten erleben, sollten Sie diesen Ansatz in Betracht ziehen. Auch wenn keine sichtbare Warteschlange vorhanden ist, deutet das Erschöpfen der CPU-Ressourcen auf dem primären Knoten auf ein weiteres klares Signal hin. In diesen Fällen können Sie zusätzliche Knoten hinzufügen und die Anzahl der Mitarbeiter pro Knoten verringern, sodass der primäre Knoten weniger von der Gesamtauslastung verarbeitet.

Hinzufügen eines Knotens

Jeder Knoten, den Sie einer HA-Bereitstellung hinzufügen, ist eine virtuelle Maschine (VM), auf der die GitHub Enterprise Server-Software ausgeführt wird. Es sollte dieselbe Software wie das Primärgerät verwenden. Im Allgemeinen muss ein zustandsloser Knoten nicht mit dem Arbeitsspeicher, der CPU oder den Speicherspezifikationen des Primären übereinstimmen. Sowohl der zustandslose Knoten als auch die primäre Instanz erfordern jedoch eine Unter millisekundenkonnektivität. Die Anforderungen an die Replikatkonnektivität bleiben unverändert.

Verwenden Sie den ghe-add-node Befehl, um die Knoten zum primären Rechenzentrum in einer HA-Konfiguration hinzuzufügen. Der ghe-add-node Befehl richtet die aktuelle Appliance als Knoten innerhalb der HA-Bereitstellung ein und soll CPU-intensive Aufgaben vom primären Datenknoten auslagern und die horizontale Skalierung ermöglichen. Diese Knoten sind für die Verarbeitung von Web- und Auftragsworkloads konzipiert, sodass eine effizientere Workloadverteilung und -verwaltung möglich ist. Dieser Befehl hat das Format:

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

  •         `PRIMARY_IP`: Die IP-Adresse des primären Knotens.

  •         `HOSTNAME` (optional): Gewünschter Hostname für den hinzugefügten Host.

Um beispielsweise einen Knoten mit Hostnamen ghes-node-1 zur primären HA-Instanz mit IP-Adresse 192.168.1.1 im primären HA-Rechenzentrum hinzuzufügen, führen Sie den folgenden Befehl aus:

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

Anschließend müssen Sie auf dem primären Knoten die folgenden Befehle ausführen:

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

Der ghe-config-apply Befehl ist eine Anforderung zum Hinzufügen von zustandslosen Knoten.

Für die öffentliche Vorschau haben wir nicht speziell auf Ausfallzeiten getestet, und es ist nicht klar, ob ein Wartungsfenster erforderlich ist.

Entfernen eines zusätzlichen Knotens

Führen Sie ghe-remove-node auf dem Node aus, den Sie entfernen möchten. Anschließend müssen Sie auf dem primären Knoten Folgendes ausführen:

Shell
ghe-config-apply

Der ghe-config-apply Befehl ist eine Anforderung, zustandslose Knoten zu entfernen.

Für die öffentliche Vorschau haben wir nicht speziell auf Ausfallzeiten getestet, und es ist nicht klar, ob ein Wartungsfenster erforderlich ist.

Neu bereitstellen eines Knotens, der zuvor GitHub Enterprise Server gehostet hat

Sie können einen Knoten, der zuvor GitHub Enterprise Server gehostet und ausgeführt hat, als zustandslosen Knoten verwenden. Dazu sollte der Knoten auf Version 3.18 oder höher aktualisiert werden, und alle Knoten in der Bereitstellung müssen dieselbe Version ausführen. Überprüfen Sie auf diesem Knoten, ob /data/user/common/cluster.conf bereits vorhanden ist. Wenn dies der Fall ist, müssen Sie vor dem Ausführen des ghe-add-node-Befehls eine Bereinigung auf dem zustandslosen Knoten durchführen.

Beispiel:

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

Grenzwerte und Verhalten

Es gibt keine theoretische Grenze für die Anzahl der Knoten, die Sie hinzufügen können. In der Praxis kann das Hinzufügen von zu vielen Knoten zu Problemen führen und sich auf Stabilität oder Leistung auswirken. Zu diesem Zeitpunkt verarbeiten neu hinzugefügte Knoten einen vordefinierten Satz von Aufgaben. Sie können nicht auswählen, welche Art von Aufgaben ausgelagert werden. Alle APIs können vom zusätzlichen Knoten verarbeitet werden.

Wenn sich ein Git-Vorgang im Prozess befindet, gibt es Logik, die Git-Vorgänge nur auf dem primären Knoten ausführt. Git-Vorgänge werden vom zusätzlichen Knoten nicht behandelt. Beispielsweise ist das Löschen einer Verzweigung ein Git-Vorgang und wird nicht vom zustandslosen Knoten behandelt.

Zustandslose Knoten führen keine Elasticsearch-Workloads aus, aber sie führen kafka-lite aus.

System- und Netzwerkanforderungen

Im Allgemeinen müssen zustandslose Knoten nicht mit den Speicher-, CPU- und Speicherspezifikationen des primären Knotens übereinstimmen. Systemanforderungen sollten den vorhandenen Ressourcenverbrauch von Web- und Auftragsdiensten auf dem primären Knoten berücksichtigen und ob der primäre Knoten diese Workloads vollständig in den neuen Knoten entladen wird.

Der zustandslose Knoten und die primäre Instanz erfordern eine Unter millisekundenkonnektivität. Im Allgemeinen erfordern alle Knoten innerhalb des primären Rechenzentrums eine Unter millisekundenkonnektivität. Die Anforderungen an die Replikatkonnektivität bleiben unverändert.

Datenverkehrsrouting und Anforderungsverarbeitung

Leitet den Datenverkehr primär zu den zusätzlichen Knoten. Bei mehreren zustandslosen Knoten sendet der primäre Knoten neue Verbindungen zu dem Server mit der geringsten Anzahl aktiver Verbindungen.

Upgrade einer HA-Implementierung mit zusätzlichen Knoten

Es folgt eine Beispielupgradesequenz:

  • Wartungsfenster starten.
  • Stoppen Sie Replikationen.
  • Führen Sie ein paralleles Upgrade durch für zustandslose Knoten.
  • Aktualisieren Sie den primären Knoten.
  • Aktualisieren Sie die Replikate. Sie können je nach Ihren Notfallwiederherstellungseinstellungen parallel oder sequenziell aktualisiert werden.
  • Starten Sie Replikate.
  • Wartungsfenster entfernen.

Die zusätzlichen Knoten sollten bei Upgrades keine zusätzlichen Ausfallzeiten verursachen.

Failover- und Notfallwiederherstellungsverhalten

Es ist nicht erforderlich, zusätzliche Knoten „abzureißen“, da sie keine Daten enthalten.

Während des Failovers wird der Replikatknoten aus der ursprünglichen Bereitstellung entfernt und in einen eigenständigen Knoten konvertiert. Zustandslose Knoten sollten dem heraufgestuften Replikat neu angefügt werden, ähnlich wie zusätzliche Replikate nach einem Failover erneut angefügt werden.

Wenn der primäre Knoten funktionsfähig ist und Sie ein Replikat als primären Knoten heraufstufen möchten, sollten Sie zustandslose Knoten mit dem ghe-remove-node Befehl aus dem primären Knoten entfernen, bevor Sie sie dem heraufgestuften Knoten erneut hinzufügen.

Wenn der primäre Knoten nicht erreichbar und nicht behebbar ist, können zustandslose Knoten wieder hinzugefügt werden, ohne sie aus dem ursprünglichen primären Knoten zu entfernen.

Überwachung, Protokolle und Supportpakete

Auf dem primären Knoten zeigen die Verwaltungskonsolen-Überwachungsdashboards Metriken für alle Knoten an, einschließlich der zustandslosen Knoten. Befehle wie ghe-cluster-nodes und ghe-cluster-status enthalten Details zu zustandslosen Knoten. Alle Verwaltungskonsolenanforderungen werden vom primären Knoten bereitgestellt.

Protokolle werden lokal auf den zustandslosen Knoten gespeichert. Sie können von diesen Knoten in Protokollverwaltungsdienste von Drittanbietern exportiert werden.

Sie können die ghe-cluster-support-bundle Befehle ghe-support-bundle verwenden, um Cluster- oder Einzelknotenbundle zu generieren und hochzuladen.

Bekannte Einschränkungen

Dieses Feature wurde nicht für monorepos entwickelt, aber das Hinzufügen neuer zustandsloser Knoten kann monorepo-Vorgänge indirekt verbessern, indem Web- und Auftrags-Workloads auf dem primären Knoten reduziert werden. Es gibt keine Funktionen für automatische Skalierung und Herunterskalierung.