Informationen zu Bereitstellungstopologien für GitHub Enterprise Server
Du kannst die virtuellen Computer für eine GitHub Enterprise Server-Instanz in verschiedenen Topologien bereitstellen, je nach Umgebung und Benutzeranforderungen.
-
Du kannst Hochverfügbarkeit konfigurieren, um einen Plan für die Notfallwiederherstellung und zusätzliche Sicherungen zu unterstützen oder die Netzwerk- und Schreibleistung für geografisch verteilte Benutzer*innen zu verbessern. In einer Hochverfügbarkeitskonfiguration fungiert ein Knoten als primärer Knoten und andere Knoten als Replikate. Weitere Informationen findest du unter Informationen zur Hochverfügbarkeitskonfiguration.
-
Um für Umgebungen mit Zehntausenden von Entwickler*innen eine horizontale Skalierung zu ermöglichen, ist eine Clustertopologie verfügbar. Clustering eignet sich für Situationen, in denen bei Verwendung eines einzelnen primären Knotens regelmäßig eine Ressourcenüberlastung auftreten würde. Diese Konfiguration erfordert eine sorgfältige Planung und zusätzlichen Verwaltungsaufwand. GitHub unterstützt dich dabei, deine Berechtigung für das Clustering zu ermitteln. Weitere Informationen findest du unter Informationen zu Clustering.
Fehlerszenarien
Hochverfügbarkeit und Clustering bieten Redundanz, indem einzelne Knoten als ein Single Point of Failure beseitigt werden. In den folgenden Szenarien können sie Verfügbarkeit bieten:
- Softwareabstürze durch Ausfall des Betriebssystems oder nicht wiederherstellbare Anwendungen.
- Hardwarefehler, beispielsweise Speicherhardware, CPU, RAM oder Netzwerkschnittstellen.
- Virtualisierungshost-Systemfehler, einschließlich geplanter und nicht geplanter Wartungsereignisse für AWS, Azure oder GCP.
- Logisch oder physisch getrenntes Netzwerk, wenn sich die Failoverappliance in einem separaten Netzwerk befindet, das vom Fehler nicht betroffen ist.
Skalierbarkeit
Clustering bietet eine bessere Skalierbarkeit, indem die Last auf mehrere Knoten verteilt wird. Diese horizontale Skalierung empfiehlt sich allenfalls für Organisationen mit Zehntausenden Entwicklern. in der Hochverfügbarkeitskonfiguration ist die Größe der Appliance nur vom primären Knoten abhängig, und die Last wird nicht an den Replikatserver verteilt.
Unterschiede bei der Failover-Methode und -Konfiguration
| Funktion | Failover-Konfiguration | Failover-Methode |
|---|---|---|
| Hochverfügbarkeitskonfiguration | DNS-Eintrag mit einem niedrigen TTL-Wert, der auf die primäre Appliance oder auf den Load-Balancer verweist. | Du musst die Replikat-Appliance in den DNS-Failover- und Load-Balancer-Konfigurationen manuell hochstufen. |
| Clustering | Der DNS-Eintrag muss auf einen Load-Balancer verweisen. | Wenn ein Knoten hinter dem Load-Balancer ausfällt, wird der Traffic automatisch an die anderen funktionierenden Knoten gesendet. |
Sicherungen und Notfallwiederherstellung
Weder Hochverfügbarkeit noch Clustering sollte als Ersatz für regelmäßige Sicherungen betrachtet werden. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf einer Instanz.
Überwachung
Verfügbarkeitsfeatures, insbesondere solche mit automatischem Failover wie das Clustering, können einen Ausfall maskieren, da der Dienst in der Regel nicht unterbrochen wird, wenn ein Fehler auftritt. Unabhängig davon, ob du Hochverfügbarkeit oder Clustering verwendest, ist es wichtig, den Zustand jeder Instanz zu überwachen, damit du weißt, wann ein Fehler auftritt. Weitere Informationen zur Überwachung findest du unter Empfohlene Schwellenwerte für Meldungen und Überwachen der Integrität deines Clusters.