Konfigurieren der Elasticsearch Cross-Cluster-Replikation für hohe Verfügbarkeit

Sie können die Suche während der Wartung, Failovers und Upgrades für eine Hochverfügbarkeitsbereitstellung stabiler machen, indem Sie die Elasticsearch Cross-Cluster Replication (CCR) aktivieren.

In diesem Artikel

Über die Elasticsearch Cross-Cluster-Replikation

GitHub Enterprise Server verwendet Elasticsearch, um die Suche über Issues, Pull Requests, Repositories sowie die Projekte- und Release-Seiten hinweg zu ermöglichen und die in der gesamten Weboberfläche angezeigten Zähler bereitzustellen. Da die Suche für das Produkt von zentraler Bedeutung ist, wirkt sich die Zuverlässigkeit von Elasticsearch direkt auf die tägliche Verwaltung Ihrer Instanz aus.

In einer Hochverfügbarkeitskonfiguration (HA) verwendet GitHub Enterprise Server ein Leader-Follower-Modell. Die primäre Appliance verarbeitet alle Schreibvorgänge und den gesamten Datenverkehr, und die Replikat-Appliances bleiben als schreibgeschützte Standby-Systeme synchron, die den Betrieb übernehmen können, wenn die primäre Appliance ausfällt. Weitere Informationen findest du unter Informationen zur Hochverfügbarkeitskonfiguration.

In früheren Versionen hat Elasticsearch dieses Leader/Follower-Modell nicht direkt unterstützt. Um Suchdaten zu replizieren, wurde ein einzelner Elasticsearch-Cluster ausgeführt, GitHub Enterprise Server der die primären und Replikatgeräte umfasste. Dieser Ansatz hat funktioniert, aber es hat eine Klasse von Problemen eingeführt: Elasticsearch könnte einen primären Shard (der für den Empfang und die Überprüfung von Schreibvorgängen zuständige Shard) auf eine Replikat-Appliance verschieben. Wenn dieses Replikat dann für Wartungsarbeiten offline genommen wurde, konnte die Instanz in einen gesperrten Zustand geraten, da das Replikat darauf wartete, dass Elasticsearch wieder fehlerfrei wurde, während Elasticsearch erst wieder fehlerfrei werden konnte, wenn das Replikat wieder beitrat.

Die Elasticsearch Cross-Cluster Replication (CCR) entfernt diese Abhängigkeit. Statt eines Clusters, der jede Appliance umfasst, wird jede Appliance als unabhängiger Single-Node Elasticsearch-Cluster ausgeführt. CCR repliziert dann Indexdaten zwischen diesen Clustern mithilfe eines nativ unterstützten Führungs-/Folgemusters. Daten werden erst kopiert, nachdem sie dauerhaft in den zugrunde liegenden Lucene-Segmenten persistiert wurden, sodass Replikas stets den Daten folgen, die sicher geschrieben wurden. Daher kann ein kritischer Primärshard nicht mehr in einem schreibgeschützten Replikat gestrandet werden.

Benefits

  • Weniger gesperrte Upgrades und Wartungsfenster. Durch das Entfernen der Zirkelabhängigkeit zwischen den primären und Replikatgeräten während der Wartung wird das Risiko reduziert, dass eine Instanz hängen bleibt.
  • Stärkerer Datenschutz. Daten werden nur repliziert, nachdem sie dauerhaft gespeichert wurden, wodurch die Indexbeschädigung während eines Failovers verhindert wird.
  • Einfachere Vorgänge. Das Muster reduziert den Bedarf an manuellen Indexreparaturen, die zuvor aufgetreten sind, wenn Wartungsschritte außerhalb der Reihenfolge ausgeführt wurden.

Availability

Elasticsearch CCR wird ab GitHub Enterprise Server 3.19.1 unterstützt. Das Feature ist optional. GitHub plant, CCR in den folgenden zwei Jahren zur standardmäßigen HA-Sucharchitektur zu machen, sodass Sie Zeit haben, es zu testen und Feedback zu geben, bevor sie zur Standardeinstellung wird.

Requirements

Bevor Sie CCR aktivieren, bestätigen Sie Folgendes.

  • Ihre Instanz wird mit GitHub Enterprise Server 3.19.1 oder höherer Version ausgeführt.
  • Ihre Instanz ist für hohe Verfügbarkeit mit mindestens zwei Appliances (primär und mindestens einem Replikat) konfiguriert.
  • Sie verfügen über eine aktualisierte GitHub Enterprise Server Lizenz, die die für CCR erforderliche Elasticsearch-Berechtigung enthält. Wenden Sie sich an den Kontakt Vertriebsteam von GitHub oder GitHub-Support damit Ihr Unternehmen für die neue Lizenz aktiviert ist, und laden Sie dann die aktualisierte Lizenzdatei herunter.

Warnung: Wenn CCR aktiviert ist, erfordert die Upgradevorprüfung eine gültige CCR-fähige Lizenz. Wenn die Kennzeichnung aktiviert ist und die Lizenzüberprüfung fehlschlägt, wird das Upgrade nicht fortgesetzt. Stellen Sie sicher, dass Ihre aktualisierte Lizenz installiert ist, bevor Sie die Funktion aktivieren oder ein Upgrade durchführen. Wenn Sie nicht sicher sind, ob Ihre Lizenz die Elasticsearch-Berechtigung enthält, wenden Sie sich an GitHub-Support.

Aktivieren von Elasticsearch Cross-Cluster-Replikation

Hinweis: Die Migration kann je nach Größe Ihrer Instanz eine erhebliche Zeit in Anspruch nehmen, da Suchdaten vor dem Neustart der Replikation auf den primären konsolidiert werden. Planen Sie die Aktivierung von CCR während eines Wartungsfensters, und testen Sie den Prozess zuerst in einer Nichtproduktionsumgebung. Weitere Informationen findest du unter Aktualisierung Ihrer Instanz.

  1. Wenden Sie sich an GitHub-Support und beantragen Sie Zugriff auf die neue HA-Sucharchitektur. GitHub aktiviert Ihr Unternehmen, damit Sie die erforderliche CCR-fähige Lizenz herunterladen können.

  2. Laden Sie Ihre aktualisierte Lizenz herunter, und laden Sie sie in Ihre Instanz hoch. Weitere Informationen findest du unter Herunterladen Ihrer Lizenz für GitHub Enterprise.

  3. Aktivieren Sie auf der primären Appliance das Feature.

    ghe-config app.elasticsearch.ccr true

  4. Wenden Sie die Konfiguration an, indem Sie eine Konfiguration ausführen oder die Instanz auf 3.19.1 oder höher aktualisieren.

    ghe-config-apply

  5. Wenn die Instanz neu gestartet wird, migriert Elasticsearch die Installation zur neuen Replikationsmethode. Diese Migration konsolidiert Suchdaten auf dem primären Computer, beendet den Cluster, der zuvor geräteübergreifend war, und startet die Replikation mithilfe von CCR neu. Während der Migration verknüpft GitHub Enterprise Server Follower mit Ihren vorhandenen Suchindizes und aktiviert eine Auto-Follow-Regel, damit alle künftig erstellten Indizes automatisch als Follower übernommen werden.

Verwendung von Elasticsearch Cross-Cluster-Replikation

Replikation überprüfen

Nach Abschluss der Migration funktioniert die Suche weiterhin normal, und es ist keine Änderung erforderlich, wie Benutzer suchen. Um die Integrität der Replikation zu bestätigen, generieren Sie ein Support-Bundle, das CCR-Statusinformationen zur Prüfung enthält. Weitere Informationen findest du unter Bereitstellen von Daten für GitHub Support.

Failover und Notfallwiederherstellung

Sie verwenden weiterhin die Standard-Replikationsdienstprogramme für Hochverfügbarkeit, um Replikate zu verwalten und ein Failover durchzuführen. Weitere Informationen findest du unter Initiieren eines Failovers zu deiner Replikat-Appliance und Hochverfügbarkeitskonfiguration wiederherstellen.

Nach einem Failover bei aktiviertem CCR übernimmt die hochgestufte Appliance die Führungsrolle für die Suche, und die Replikas folgen im Rahmen des standardmäßigen Wiederherstellungsprozesses erneut deren Indizes. Wenn während oder nach einem Failover Fehler im Zusammenhang mit der Suchreplikation auftreten, wenden Sie sich an GitHub-Support.

Deaktivieren der Elasticsearch-Cross-Cluster-Replikation

Warnung: Deaktivieren Sie CCR auf einer Produktionsinstanz nicht ohne Anleitung von GitHub-Support. Das Deaktivieren von CCR ist kein routinemäßiger Self-Service-Vorgang. Wenn Sie das Feature deaktivieren, kann das Entfernen von Replikat-Elasticsearch-Daten im Rahmen der Rückkehr zum vorherigen Modus ausgelöst werden.

Wenn Sie zur vorherigen Sucharchitektur zurückkehren müssen, wenden Sie sich an den Kontakt GitHub-Support , bevor Sie Änderungen vornehmen. GitHub hilft Ihnen dabei, zu überprüfen, dass Ihre Lizenz, der Replikationsstatus und der Upgradepfad sicher verwaltet werden.

Weiterführende Lektüre