Enterprise Server 3.22 ist derzeit als Release Candidate verfügbar.

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 aus dem primären Knoten entladen, wodurch die horizontale Skalierung der GitHub Enterprise Server Instanz ermöglicht wird.

In diesem Artikel

Für GitHub Enterprise Server Kunden, die horizontal skalieren möchten, ist die Migration zu und den Betrieb eines Clusters eine Option, ist aber ressourcenintensiv und zeitaufwändig. 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 oft 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. Unicorn und Aqueduct können auch vom primären Knoten ausgelagert werden, was erhebliche Compute- und Speicherressourcen für die verbleibenden zustandsbehafteten Dienste freigibt. 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 ein virtueller Computer (VM), auf dem 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.

Wir empfehlen, für das Hinzufügen zustandsloser Knoten ein Wartungsfenster einzuplanen.

Entfernen eines zusätzlichen Knotens

Bevor Sie einen zusätzlichen Knoten entfernen, installieren Sie den gleichen neuesten Patch für Ihre Featureversion auf jedem Knoten in der HA-Bereitstellung, und planen Sie ein Wartungsfenster. Warten Sie, bis ein Upgrade oder eine Konfiguration abgeschlossen ist, bevor Sie mit dem Entfernen beginnen.

  1. Überprüfen Sie auf dem HA-Primärknoten den Status jedes Knotens in der HA-Bereitstellung.

    Shell
    ghe-cluster-nodes
ghe-cluster-nodes --offline
nomad node status
ghe-cluster-status --extended --verbose

    Vergewissern Sie sich, dass beide ghe-cluster-nodes Befehle denselben Hostnamen auflisten und den Hostnamen des Knotens einschließen, den Sie entfernen möchten. Vergewissern Sie sich, dass jeder Knoten den Nomad-Status ready hat und dass connect-ssh und enterprise-version für jeden Knoten ok sind. Vergewissern Sie sich, dass zustandsbehaftete Dienste für die primäre Und alle Replikate fehlerfrei sind. Wenn kein Replikat verbleibt, wird eine Warnung angezeigt, dass kein MySQL-Replikat gefunden wurde. Fehler, die auf Web-, Auftrags- oder Memcache-Workloads für das Ziel beschränkt sind, blockieren die Entfernung nicht. Wenn eine andere Überprüfung auf Knotenebene oder eines zustandsbehafteten Dienstes fehlschlägt, wenden Sie sich vor dem Entfernen an GitHub-Support.

  2. Entfernen Sie den zusätzlichen Knoten auf dem primären HA-Knoten. Ersetzen Sie HOSTNAME durch den Hostnamen des zusätzlichen Knotens.

    Shell
    ghe-remove-node --verbose HOSTNAME

    Wenn ein weiterer Nicht-Primärknoten vorhanden ist, leert der Befehl den Zielknoten, entfernt ihn aus der HA-Konfiguration und führt ghe-config-apply aus. Wenn kein nicht primärer Knoten verbleibt, entfernt der Befehl die Clustermetadaten und konvertiert die primäre Instanz ohne Ausführung ghe-config-applyin eine eigenständige Instanz. Führen Sie ghe-config-apply in beiden Fällen nicht separat aus.

  3. Überprüfen Sie die Entfernung.

    Wenn ein weiterer Nicht-Primärknoten vorhanden ist, führen Sie die folgenden Befehle auf dem HA-Primärknoten aus. Vergewissern Sie sich, dass der Hostname nicht vorhanden ist und dass die HA-Konfiguration fehlerfrei ist.

    Shell
    ghe-cluster-nodes --offline
ghe-cluster-status --extended --verbose

    Wenn kein Knoten außer dem primären mehr vorhanden ist, führen Sie die ausschließlich für den Cluster bestimmten Befehle nicht aus. Vergewissern Sie sich, dass die Ausgabe des Entfernungsvorgangs Cluster artifacts removed; now standalone. enthält, und vergewissern Sie sich dann, dass die primäre Instanz den Benutzerdatenverkehr bedient und Web- und Auftragsworkloads verarbeitet.

Wenn ein zusätzlicher Knoten offline, nicht erreichbar oder in einer anderen Version ist, oder wenn ghe-remove-node eine Überprüfung fehlschlägt, wenden Sie sich an GitHub-Support. Bearbeiten Sie cluster.conf nicht manuell.

Erneute Bereitstellung eines Zuvor gehosteten Knotens GitHub Enterprise Server

Sie können einen Knoten, auf dem zuvor GitHub Enterprise Server gehostet und ausgeführt wurde, 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, musst du vor dem Ausführen des Befehls ghe-add-node auf dem zustandslosen Knoten eine Bereinigung 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, der nicht vom zustandslosen Knoten behandelt wird.

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.

Milderung der Softirq-Sättigung mit einem Kern

Das Hinzufügen eines zustandslosen Knotens zu einer GitHub Enterprise Server Hochverfügbarkeitsbereitstellung sendet den gesamten Datenverkehr zwischen zwei Knoten über einen einzelnen WireGuard-Tunnel. Da jedes Paket für dieses Knotenpaar einen UDP-Port gemeinsam verwendet, steuert die Netzwerkkarte sie in eine Empfangswarteschlange, und ein CPU-Kern verarbeitet alle eingehenden Pakete. Unter starkem Datenverkehr, der Kern erreicht 100 Prozent, während die anderen im Leerlauf bleiben und der Knoten Pakete abbricht. GitHub Enterprise Server enthält die unten beschriebenen integrierten Gegenmaßnahmen.

1. Skalieren mit mehr zustandslosen Knoten

Jeder zustandslose Knoten erreicht den Primären über seinen eigenen WireGuard-Tunnel, sodass der Datenverkehr jedes Knotens in einer separaten Empfangswarteschlange und einem SEPARATEN CPU-Kern verarbeitet. Durch die Verteilung von Workloads über mehr, kleinere zustandslose Knoten können die Lastenausgleichslast über mehr Kerne des primären Kerns hinweg teilen, und dies basiert nicht auf Hashing auf Tunnelebene. Zwei Knoten halbieren die empfangende Last pro Kern, und drei schneiden sie auf etwa ein Drittel aus.

GitHub Enterprise Server passt die Größe der Web-Worker jedes Knotens aus dem Speicher an und begrenzt seinen eigenen Wert bei 30. Halten Sie app.github.github-workers nahe 30 pro Knoten; höhere Anzahl kosten Arbeitsspeicher, und fügen Sie während eines Tunnelstands die Warteschlangentiefe und nicht den Durchsatz hinzu, da die zusätzlichen Mitarbeiter auf der primären Seite blockieren. Fügen Sie für mehr Kapazität weitere zustandslose Knoten hinzu.

2. Multi-Tunnel WireGuard (Opt-In)

GitHub Enterprise Server kann den Datenverkehr zwischen Knoten über mehrere WireGuard-Tunnel verteilen. Jeder Tunnel verwendet einen eigenen UDP-Port, sodass unterschiedliche Verbindungen auf unterschiedlichen Empfangswarteschlangen landen und unterschiedliche CPU-Kerne die Arbeit teilen. Legen Sie die Tunnelanzahl auf die niedrigste Anzahl von Empfangswarteschlangen über Ihre Clusterknoten, den Wert "Kombiniert" von ethtool -l eth0.

Shell
ghe-config wireguard.num-tunnels 8
ghe-config-apply

Der Standardwert ist 1. Der Höchstwert beträgt 16; Höhere Werte sind begrenzt. Mehr Tunnel als die Schnittstelle empfängt, bietet keine Vorteile. Um die Einstellung wiederhergestellt zu werden, entfernen Sie die Einstellung, und wenden Sie sie an.

Shell
ghe-config --unset wireguard.num-tunnels
ghe-config-apply

Vor der Aktivierung (einmal):

  • Öffnen Sie in Ihrer externen Firewall oder Cloudsicherheitsgruppe die zusätzlichen UDP-Ports zwischen allen Knoten, einschließlich aller Replikate. Ports zählen von 1194, sodass 8 Tunnel UDP 1194 bis 1201 verwenden. Der vollständige Bereich erfordert UDP 1194 bis 1209.
  • Durch Aktivieren von Multi-Tunnel-Updates wird die Hostfirewall aktualisiert. Wenden Sie sie einmal an, indem Sie alle Knoten neu starten oder die Firewall mit sudo ufw reload jedem Knoten neu laden. Vergewissern Sie sich, dass Ihre Netzwerksicherheitsgruppe den eingehenden Zugriff bereits einschränkt, da der ufw-Lademodus kurz abbricht und die Regeln neu erstellt. Spätere num-tunnels Änderungen benötigen diesen Schritt nicht.

3. Lokales Git-Proxy-Routing auf der primären (automatisch)

Git fordert an, dass ein zustandsloser Knoten andernfalls über den Tunnel zurücksenden würde, bleiben jetzt auf dem primären Ort, in dem sich die Git-Daten bereits befinden. Dadurch wird ein großer Teil von paketübergreifenden Paketen entfernt, und es ist keine Aktion erforderlich. Die primäre Anwendung verwendet zuerst den lokalen Git-Proxy und greift nur dann auf einen Remoteknoten zurück, wenn der lokale Proxy nicht verfügbar ist.

4. Kapazitätsbasierte Webanforderungsgewichtung (Opt-In)

Wenn Knoten unterschiedliche Anzahl von Web-Workern ausführen, GitHub Enterprise Server können Anforderungen proportional zur Anzahl der Mitarbeiter jedes Knotens verteilt werden, anstatt gleichmäßig. Aktivieren Sie diese Option, wenn die Anzahl der Mitarbeiter ungleich ist, z. B. ein Primärschlüssel mit 100 Mitarbeitern und einen zustandslosen Knoten mit 30.

Shell
ghe-config app.github.unicorn-weight-by-capacity true
ghe-config-apply

Der Standardwert ist deaktiviert.

Auswählen, was aktiviert werden soll

Beginnen Sie mit der Skalierung auf mehr zustandslose Knoten. Es ist die vollständigste Option, verteilt die Last über mehr kerne der primären Kerne über das Lastenausgleichsmodul und benötigt kein Feature-Flag. Wenn ein einzelner Kern immer noch gesättigt ist, aktivieren Sie WireGuard mit mehreren Tunneln. Aktivieren Sie die kapazitätsbasierte Gewichtung nur, wenn sich die Anzahl der Mitarbeiter über Knoten unterscheidet.

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 Auftragsworkloads auf dem primären Knoten reduziert werden. Es gibt keine Funktionen für automatische Skalierung und Herunterskalierung.