Informationen zur Beobachtbarkeit für Hochverfügbarkeit
Du kannst Hochverfügbarkeit für Ihre GitHub Enterprise Server-Instance konfigurieren, um deinen Plan für die Notfallwiederherstellung und deine Sicherungen zu unterstützen oder die Netzwerk- und Schreibleistung für geografisch verteilte Benutzer*innen zu verbessern. Weitere Informationen findest du unter Informationen zur Hochverfügbarkeitskonfiguration.
Nachdem du die Hochverfügbarkeit konfiguriert hast, kannst du die Redundanz proaktiv sicherstellen, indem du die allgemeine Integrität der Replikation und den Status jedes Replikatknotens deiner Instanz überwachst. Du kannst Befehlszeilen-Hilfsprogramme in der Instanz, ein Übersichtsdashboard oder ein Remoteüberwachungssystem wie Nagios verwenden.
Bei Hochverfügbarkeit verwendet deine Instanz mehrere Ansätze zum Replizieren von Daten zwischen primären Knoten und Replikatknoten. Datenbankdienste, die einen nativen Replikationsmechanismus unterstützen (z. B. MySQL), verwenden den nativen Mechanismus des Diensts für die Replikation. Andere Dienste (z. B. Git-Repositorys) nutzen einen für GitHub Enterprise Server entwickelten benutzerdefinierten Mechanismus oder Plattformtools wie rsync für die Replikation.
Überwachen der Replikation über deine Instanz
Um den Replikationsstatus eines vorhandenen Replikatknotens für Ihre GitHub Enterprise Server-Instance zu überwachen, stelle eine Verbindung mit der Verwaltungskonsole (SSH) des Knotens her, und führe das Befehlszeilen-Hilfsprogramm ghe-repl-status aus. Weitere Informationen findest du unter Befehlszeilenprogramme.
Du kannst den Replikationsstatus auch über das Übersichtsdashboard in deiner Instanz überwachen. Navigiere in einem Browser zur folgenden URL, und ersetze „HOSTNAME“ durch den Hostnamen deiner Instanz.
http(s)://HOSTNAME/setup/replication
Überwachen der Replikation über ein Remotesystem
Die Ausgabe des Befehlszeilen-Hilfsprogramms ghe-repl-status entspricht den Erwartungen des Nagios-Plug-Ins „check_by_ssh“. Weitere Informationen findest du unter Befehlszeilenprogramme.
Darüber hinaus kannst du die Verfügbarkeit deiner Instanz überwachen, indem du den von einer Anforderung an die folgende URL zurückgegebenen Statuscode analysierst. Wenn du beispielsweise einen Lastenausgleich als Teil deiner Failoverstrategie bereitstellst, kannst du Integritätsüberprüfungen konfigurieren, die diese Ausgabe analysieren. Weitere Informationen findest du unter GitHub Enterprise Server mit einem Load-Balancer verwenden.
Je nachdem, wo und wie du die Überwachung konfigurierst, ersetzt du „HOST“ entweder durch den Hostnamen deiner Instanz oder durch die IP-Adresse eines einzelnen Knotens.
http(s)://HOST/status
Ein aktiver Knoten für die Georeplikation, der auf Benutzeranforderungen reagieren kann, gibt den Statuscode 200 (OK) zurück. Bei Anforderungen an einzelne Knoten oder den Hostnamen der Instanz kann aus den folgenden Gründen ein 503-Fehler (Dienst nicht verfügbar) zurückgegeben werden.
- Bei dem einzelnen Knoten handelt es sich um einen passiven Replikatknoten (z. B. beim Replikatknoten in einer Hochverfügbarkeitskonfiguration mit zwei Knoten).
- Der einzelne Knoten ist Teil einer Georeplikationskonfiguration, aber es handelt sich um einen passiven Replikatknoten.
- Die Instanz befindet sich im Wartungsmodus. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.
Weitere Informationen zur Georeplikation findest du unter Informationen zur Geo-Replikation.
Problembehandlung für Replikationsfehler
Um Replikationsprobleme in deiner Instanz zu beheben, stelle sicher, dass die Replikation ausgeführt wird und Knoten über das Netzwerk miteinander kommunizieren können. Du kannst auch Befehlszeilen-Hilfsprogramme verwenden, um die Unterreplikation zu untersuchen.
Replikation wird nicht ausgeführt
Du musst die Replikation in jedem Knoten mithilfe des Befehlszeilen-Hilfsprogramms ghe-repl-start starten. Wenn die Replikation nicht ausgeführt wird, stelle mithilfe von SSH eine Verbindung mit dem betroffenen Knoten her, und führe dann ghe-repl-start aus. Weitere Informationen findest du unter Befehlszeilenprogramme.
Kommunikationsprobleme zwischen Knoten
Die Replikation erfordert, dass der primäre Knoten und alle Replikatknoten über das Netzwerk miteinander kommunizieren können. Stelle mindestens sicher, dass die Ports 122/TCP und 1194/UDP für die bidirektionale Kommunikation zwischen allen Knoten deiner Instanz offen sind. Weitere Informationen findest du unter Netzwerkports.
Die Latenz zwischen primären und Replikatknoten muss kleiner als 70 Millisekunden sein. Es wird nicht empfohlen, eine Firewall zwischen den Netzwerken der Knoten zu konfigurieren. Du kannst das ping oder ein anderes Hilfsprogramm für die Netzwerkverwaltung verwenden, um die Netzwerkkonnektivität zwischen Knoten zu testen.
Unterreplikation
Wenn du das Befehlszeilen-Hilfsprogramm ghe-repl-status in einem Replikatknoten ausführst und Git-Repositorys, Repositorynetzwerke oder Speicherobjekte unterrepliziert sind, wird mindestens ein Replikatknoten nicht vollständig mit dem primären Knoten synchronisiert. Eine Unterreplikation kann auftreten, wenn der primäre Knoten nicht mit den Replikatknoten kommunizieren kann oder die Replikatknoten nicht mit dem primären Knoten kommunizieren können.
Wenn du kürzlich die Hochverfügbarkeit oder Georeplikation konfiguriert hast, dauert die erste Synchronisierung einige Zeit. Die Dauer der ersten Synchronisierung hängt von der Datenmenge und den Netzwerkbedingungen ab.
Unterreplizierte Repositorys oder Repositorynetzwerke
Du kannst den Replikationsstatus eines bestimmten Repositorys anzeigen, indem du eine Verbindung mit einem Knoten herstellst, den folgenden Befehl ausführst und dann „OWNER“ durch die Besitzer*innen des Repositorys und „REPOSITORY“ durch den Namen des Repositorys ersetzt.
ghe-spokes diagnose OWNER/REPOSITORY
Wenn du den Replikationsstatus eines Repositorynetzwerks anzeigen möchtest, kannst du alternativ „NETWORK-ID/REPOSITORY-ID“ durch die Netzwerk-ID und die Repository-ID ersetzen.
ghe-spokes diagnose NETWORK-ID/REPOSITORY-ID
Unterreplizierte Speicherobjekte
Du kannst den Status eines bestimmten Speicherobjekts anzeigen, indem du eine Verbindung mit einem Knoten herstellst und den folgenden Befehl ausführst, wobei „OID“ durch die Objekt-ID ersetzt wird.
ghe-storage info OID
Support von GitHub
Wenn Sie die Problembehandlungshinweise für die Replikation berücksichtigen und weiterhin Probleme im Zusammenhang mit Ihrer Instanz auftreten, sammeln die folgenden Informationen, und wenden Sie sich dann unter GitHub Enterprise Support an uns.
- Führe auf jedem betroffenen Knoten
ghe-repl-status -vvaus, und kopiere dann die Ausgabe in dein Ticket. Weitere Informationen findest du unter Befehlszeilenprogramme. - Erstelle für jeden betroffenen Knoten ein Supportbundle, das an dein Ticket angefügt wird. Weitere Informationen findest du unter Providing data to GitHub Support (Bereitstellen von Daten für GitHub Support).