Replikattypen und -fähigkeiten
Welche arten von Replikaten werden in einer HA-Bereitstellung verwendet?
Es gibt drei Arten von Replikaten in einer Hochverfügbarkeitsbereitstellung (HA):
-
Passive Replikate
-
Aktives Replikat
-
Cachereplikate (als Repositorycaches bezeichnet).
**Passive Replikate** synchronisieren einfach Daten aus der primären Instanz und behandeln keine GitHub Datenverkehr. Operatoren können jedoch bei Bedarf ein passives Replikat als primäres Replikat heraufstufen.
Ein Geo-Replikat ist ein Beispiel für ein aktives Replikat (diese Begriffe werden häufig austauschbar verwendet). Aktive Replikate synchronisieren die Daten aus der primären. Ein aktives Replikat kann GitHub-Datenverkehr auch direkt verarbeiten oder sie an den primären Proxy senden.
**Cache Repliken** synchronisieren sowohl Git als auch Git Large File Storage (Git LFS) Daten vom primären. Cachereplikate sind für leseintensive Szenarien vorgesehen, z. B. CI-Farmen. Sie akzeptieren nur Lesen-/Abfragen-/Klonen-Anfragen für Repositories, von denen sie eine lokale Kopie haben. Für alle anderen Repositorys wird ein Fehler zurückgegeben. Sie lehnen Pushs immer mit einer Fehlermeldung ab.
Können alle Replikattypen zur primären Instanz heraufgestuft werden?
Nur passive und aktive Replikate können primär heraufgestuft werden. Cachereplikate können nicht zur primären Instanz heraufgestuft werden.
Kann eine einzelne Bereitstellung über alle Replikate verfügen?
Eine einzelne Bereitstellung kann aktive Replikate, passive Replikate und Cachereplikate gleichzeitig enthalten.
Wartet die primäre Instanz auf Replikas für Schreibvorgänge?
Die primäre Instanz wartet bei Schreibvorgängen nicht auf Replikas. In HA schreibt ein Pushvorgang sowohl zur primären Instanz als auch zu allen passiven und aktiven Replikaten. Da der primäre Knoten jedoch der einzige Abstimmungsknoten ist, gilt der Pushvorgang als akzeptiert, wenn er erfolgreich auf dem primären Knoten ausgeführt wird.
Kommunikations- und Netzwerkanforderungen
Welche Entitäten können mit aktiven Replikaten kommunizieren?
Die primäre Instanz kommuniziert mit aktiven Replikas, um die Daten zu synchronisieren und alle Anforderungen zu verarbeiten, die von aktiven Replikas an die primäre Instanz weitergeleitet werden. GitHub Web-, API- und Git-Datenverkehr (von Mensch und Automatisierung) kann direkt an aktive Replikate weitergeleitet werden. Deshalb ist es wichtig, DNS so zu konfigurieren, dass der für ein aktives Replikat vorgesehene Datenverkehr tatsächlich erreicht wird.
Welche Entitäten können mit passiven Replikaten kommunizieren?
Die primäre Instanz kommuniziert mit passiven Replikaten, um Daten zu synchronisieren. Passive Replikate empfangen oder verarbeiten keine anderen GitHub Datenverkehr.
Welche Entitäten können mit Cachereplikaten kommunizieren?
Schreibgeschützter Git-Datenverkehr, hauptsächlich aus Automatisierungen wie CI-Farmen, kann von Cachereplikaten weitergeleitet und verarbeitet werden. Um dies zu ermöglichen, sollten Sie Ihr DNS so konfigurieren, dass der relevante Datenverkehr an das Cachereplikat umgeleitet wird. Cachereplikate dienen nicht dem Benutzerdatenverkehr oder Pushdatenverkehr.
Sollten Replikate gemeinsam mit der Primären gespeichert werden?
Es besteht keine Anforderung, dass Replikate mit der primären Datei gemeinsam gespeichert werden. Definition gemäß ist ein Georeplikat geografisch vom Primärstandort entfernt und nicht im selben Rechenzentrum. Cachereplikate stellen auch keine Colocation-Anforderungen.
Es wird jedoch empfohlen, dass sich mindestens ein passives Replikat mit dem Primären im selben Rechenzentrum zusammen befindet, um ein schnelleres Failover während eines primären Ausfalls zu ermöglichen. Im Falle eines vollständigen Rechenzentrumsausfalls können Sie ein geografisch verteiltes passives Replikat bewerben.
Was sind die Latenzanforderungen zwischen primären und Replikaten?
Primäre und aktive Replikate haben strenge Latenzanforderungen. Primäre und passive Replikate sowie primäre und Cachereplikate haben empfohlene Latenzanforderungen. Weitere Informationen findest du unter Erstellung eines hochverfügbaren Replikats und Überwachen einer Hochverfügbarkeitskonfiguration. Netzwerklatenzen, die über die erforderlichen und empfohlenen Werte hinausgehen, können dazu führen, dass Replikate ständig zurückbleiben.
Administrativer Zugriff und Überwachung
Ist die Verwaltungskonsole auf Replikaten verfügbar?
Die Verwaltungskonsole ist weder auf passiven Replikaten noch auf Cache-Replikaten verfügbar. Es ist nur auf aktiven Replikaten verfügbar (aktive Replikate leiten die meisten Anforderungen an den Primärserver weiter).
Ist es möglich, SSH in Replikate zu integrieren?
Ein Operator mit Administratorshellzugriff kann SSH in eines der Replikate integrieren. Operatoren können ihre öffentlichen Schlüssel über die Verwaltungskonsole zum neuen Replikat hinzufügen, bevor das Replikat zum Cluster hinzugefügt wird. Weitere Informationen finden Sie unter Auf die Verwaltungsshell (SSH) zugreifen.
Wie funktionieren Supportpakete für Replikate?
Sie können entweder ein Clusterbundle oder ein knotenspezifisches Bündel generieren. Ein Clusterbundle enthält Bündel aller Knoten in der HA-Bereitstellung, während ein knotenspezifisches Bündel Daten aus nur einem Knoten enthält.
Können die Replikate überwacht werden und wie?
Alle Replikate können überwacht werden. Die Verwaltungskonsole auf der primären Instanz stellt Dashboards für alle Knoten bereit, einschließlich passiver und aktiver Replikatknoten in der Bereitstellung.
Darüber hinaus können Sie Metriken und Protokolle von allen Knoten in einer Bereitstellung auf Überwachungsplattformen von Drittanbietern exportieren.
Informationen zum Überwachen des Status der Datenreplikation zwischen Replikatknoten finden Sie unter Überwachen einer Hochverfügbarkeitskonfiguration.
Unterschied zwischen Replikaten und Sicherungen
Sind Replikate und Sicherungen gleich?
Replikate und Sicherungen sind nicht identisch. Sie dienen verschiedenen Zwecken.
Sicherungen werden verwendet, um Kopien deiner Daten zu erstellen, die dann zu einer anderen GitHub Enterprise Server wiederhergestellt werden können. Kunden verwenden häufig Sicherungen, um sich von Katastrophen zu erholen oder um neue Installationen zu erstellen. Sicherungsdaten werden also verwendet, um eine andere GitHub Enterprise Server-Instanz wiederherzustellen, während Replikate hohe Verfügbarkeit und Redundanz in Echtzeit bereitstellen.
Die Replikate selbst sind GitHub Enterprise Server-Instanzen. Beim Sicherungshost handelt es sich nicht um eine GitHub Enterprise Server-Installation.
Welche Software wird auf Replikaten ausgeführt?
Replikate sind eine separate Installation von GitHub Enterprise Server. Die primäre Instanz und alle Replikate sollten dieselbe Version von GitHub Enterprise Server ausführen.
Wartungsvorgänge
Was ist die empfohlene Abfolge von Vorgängen für Upgrades?
- Starten Sie das Wartungsfenster für das primäre und alle Replikate.
- Beenden Sie die Replikation auf allen Repliken.
- Aktualisieren Sie die primäre auf die Zielversion.
- Aktualisieren Sie die Replikate auf dieselbe Zielversion. Alle Replikate können parallel aktualisiert werden.
- Nachdem alle Upgrades abgeschlossen sind, starten Sie den Replikationsprozess neu.
- Schließen Sie das Wartungsfenster.
Manchmal möchten Kunden das Upgrade von Replikaten zu einem späteren Zeitpunkt verschieben. Entfernen Sie in diesem Fall den Replikatknoten aus der Bereitstellung, und konvertieren Sie ihn in einen eigenständigen Knoten. Führen Sie ein Upgrade auf dieselbe Version wie die primäre Version durch, und fügen Sie es dann wieder zur Bereitstellung hinzu.
Was ist die empfohlene Reihenfolge von Vorgängen beim Hotpatching?
Ein Hotpatching kann mit nur minimalen Unterbrechungen ausgeführt werden. Du kannst zuerst die primäre Instanz und dann die Replikate hotpatchen.
Auswählen des richtigen Replikattyps
Wann werden passive Replikate verwendet?
Wenn Sie hohe Verfügbarkeit benötigen und eine auf dem neuesten Stand befindliche Instanz für den Failover benötigen, falls die primäre Instanz ausfällt, sind passive Replikate der richtige Weg. Die meisten unserer Kunden verwenden passive Replikate.
Wann sollen Geo-Replikate verwendet werden?
Wenn Sie über eine geografisch verteilte Entwicklermitarbeiter verfügen, können Die Einrichtung von Georeplikaten Benutzern in bestimmten Regionen helfen. Stellen Sie sich beispielsweise ein multinationales Unternehmen mit Ingenieurteams in Nordamerika, Europa und Asien vor. Wenn sich die primäre Instanz in den USA befindet, kann die Bereitstellung eines Georeplikats in Europa die Leistung von Lesevorgängen für europäische Benutzer erheblich verbessern. Dasselbe kann jedoch nicht für Schreibvorgänge gesagt werden. Alle Schreibvorgänge müssen sowohl auf den Georeplikaten als auch auf dem primären Computer landen, bevor der Vorgang abgeschlossen ist. Der geografische Abstand zwischen den primären und Replikaten erhöht die Latenz, wodurch Schreibvorgänge verlangsamt werden können.
Wann sollen Cachereplikate verwendet werden?
Wenn Ihre Anwendungsfälle leselastig sind, wie es bei CI-Farmen oft der Fall ist, sind Cache-Replikate besser geeignet. Hier sind einige Szenarien, in denen Cachereplikate sinnvoll sind:
- Ein Unternehmen mit einem kleinen Satellitenbüro in einer Region mit begrenzter Bandbreite für das Hauptdatenzentrum, in dem Entwickler schnelleren Zugriff auf Repositorys benötigen, aber keinen Schreibzugriff benötigen.
- Eine Organisation, die CI/CD-Jobs in einem Remote-Rechenzentrum ausführt, die häufig Repositories klonen muss und den Netzwerkdatenverkehr zur primären Instanz minimieren möchte.
Konstruktionsbedingt kommen Cachereplikate mit Kompromissen. Cachereplikate sind letztlich konsistent und stellen nicht immer die neuesten Repository-Inhalte bereit. Es gibt jedoch Webhooks für den Zeitpunkt, an dem die neuesten Änderungen beim Replikat eingehen, damit die relevanten CI/CD-Aufgaben gestartet werden können. Sehr wenige GitHub Kunden verwenden Cachereplikate.