Elasticsearch クロスクラスター レプリケーションについて
GitHub Enterprise Server では、Elasticsearch を使用して、問題、プル要求、リポジトリ、プロジェクトとリリース ページ、Web インターフェイス全体に表示される数を検索できます。 検索は製品の中心であるため、Elasticsearch の信頼性はインスタンスの日常的な管理に直接影響します。
高可用性 (HA) 構成では、 GitHub Enterprise Server はリーダー/フォロワー モデルを使用します。 プライマリ アプライアンスはすべての書き込みとトラフィックを受け取り、レプリカ アプライアンスは読み取り専用スタンバイとして同期され、プライマリが失敗した場合に引き継ぐ可能性があります。 詳細については、「高可用性構成について」を参照してください。
以前のリリースでは、Elasticsearch はこのリーダー/フォロワー モデルを直接サポートしていませんでした。 検索データをレプリケートするために、 GitHub Enterprise Server プライマリ アプライアンスとレプリカ アプライアンスにまたがる単一の Elasticsearch クラスターを実行しました。 このアプローチは機能しましたが、問題のクラスが導入されました。Elasticsearch は、プライマリ シャード (書き込みの受信と検証を担当するシャード) をレプリカ アプライアンスに移動する可能性があります。 その後、そのレプリカがメンテナンスのためにオフラインになった場合、インスタンスはロックされた状態になる可能性があります。これは、レプリカが Elasticsearch が正常になるのを待機したのに対し、Elasticsearch はレプリカが再び参加するまで正常になりませんでした。
Elasticsearch クロスクラスター レプリケーション (CCR) は、この依存関係を削除します。 各アプライアンスにまたがる 1 つのクラスターではなく、各アプライアンスは独立した単一ノード Elasticsearch クラスターとして実行されます。 次に、CCR は、ネイティブでサポートされているリーダー/フォロワー パターンを使用して、これらのクラスター間でインデックス データをレプリケートします。 データは、基になる Lucene セグメントに永続的に永続化された後にのみコピーされるため、レプリカは常に安全に書き込まれたデータに従います。 その結果、重要なプライマリシャードが読み取り専用レプリカに取り残された状態になることはなくなりました。
Benefits
- ロックされたアップグレードとメンテナンス期間が少なくなります。 メンテナンス中にプライマリ アプライアンスとレプリカ アプライアンスの間の循環依存関係を削除すると、インスタンスがスタックするリスクが軽減されます。
- より強力なデータ保護。 データは永続的に保存された後にのみレプリケートされるため、フェールオーバー中のインデックスの破損を防ぐことができます。
- より単純な操作。 このパターンにより、以前はメンテナンス手順が順不同で実行された際に発生していたインデックスの手動修復の必要性が低減されます。
Availability
Elasticsearch CCR は、 GitHub Enterprise Server 3.19.1 以降でサポートされています。 この機能は省略可能です。 GitHub は、CCR を次の 2 年間で既定の HA 検索アーキテクチャにすることを計画しているため、既定になる前にテストしてフィードバックを提供する時間があります。
Requirements
CCR を有効にする前に、次の内容を確認します。
- インスタンスは GitHub Enterprise Server 3.19.1 以降を実行しています。
- インスタンスは、少なくとも 2 つのアプライアンス (プライマリと 1 つ以上のレプリカ) を使用して高可用性を実現するように構成されています。
- CCR に必要な Elasticsearch エンタイトルメントを含む更新された GitHub Enterprise Server ライセンスがあります。 企業で新しいライセンスを有効にするには、 GitHub の営業チーム または GitHub のサポート に問い合わせ、更新されたライセンス ファイルをダウンロードします。
警告： CCR が有効になっている場合、アップグレードプレフライト チェックには有効な CCR 対応ライセンスが必要です。 フラグが有効になっていて、ライセンス チェックが失敗した場合、アップグレードは続行されません。 機能またはアップグレードを有効にする前に、更新されたライセンスがインストールされていることを確認してください。 ライセンスに Elasticsearch の権利が含まれているかどうかわからない場合は、 GitHub のサポートにお問い合わせください。
Elasticsearch クロスクラスター レプリケーションの有効化
注: レプリケーションが再開される前に検索データがプライマリに統合されるため、インスタンスのサイズによっては、移行にかなりの時間がかかる場合があります。 メンテナンス期間中に CCR を有効にすることを計画し、最初に非運用環境でプロセスをテストします。 詳細については、「インスタンスのアップグレード」を参照してください。
-
GitHub のサポートに連絡し、新しい HA 検索アーキテクチャへのアクセスを要求します。 GitHub は、必要な CCR 対応ライセンスをダウンロードできるように、企業を有効にします。
-
更新したライセンスをダウンロードし、インスタンスにアップロードします。 詳細については、「GitHub Enterprise のライセンスのダウンロード」を参照してください。
-
プライマリ アプライアンスで、この機能を有効にします。
ghe-config app.elasticsearch.ccr true -
構成を適用するには、構成実行を実行するか、インスタンスを 3.19.1 以降にアップグレードします。
ghe-config-apply -
インスタンスが再起動すると、Elasticsearch はインストールを新しいレプリケーション方法に移行します。 この移行により、検索データがプライマリに統合され、以前にアプライアンスにまたがるクラスターが終了し、CCR を使用してレプリケーションが再開されます。 移行中、 GitHub Enterprise Server はフォロワーを既存の検索インデックスにアタッチし、自動フォロー ルールを有効にして、将来作成されるすべてのインデックスが自動的にフォローされるようにします。
Elasticsearch クロスクラスター レプリケーションの使用
レプリケーションの確認
移行が完了すると、検索は正常に機能し続け、ユーザーの検索方法に変更は必要ありません。 レプリケーションの正常性を確認するには、レビュー用の CCR 状態情報を含むサポート バンドルを生成します。 詳細については、「GitHub サポートにデータを提供する」を参照してください。
フェールオーバーとディザスター リカバリー
レプリカの管理とフェールオーバーには、引き続き標準の高可用性レプリケーション ユーティリティを使用します。 詳細については、「レプリカアプライアンスへのフェイルオーバーの開始」および「高可用性構成の回復」を参照してください。
CCR を有効にしたフェールオーバーの後、昇格されたアプライアンスが検索の新しいリーダーになり、レプリカは標準の復旧プロセスの一環としてインデックスに従い直します。 フェールオーバー中またはフェールオーバー後に検索レプリケーションに関連するエラーが発生した場合は、 GitHub のサポートにお問い合わせください。
Elasticsearch クロスクラスター レプリケーションの無効化
**警告：**GitHub のサポートからのガイダンスがない場合は、実稼働インスタンスで CCR を無効にしないでください。 CCR を無効にすることは、日常的なセルフサービス操作ではありません。 この機能をオフにすると、前のモードに戻る一環として、レプリカ Elasticsearch データの削除をトリガーできます。
前の検索アーキテクチャに戻る必要がある場合は、変更を加える前に GitHub のサポート にお問い合わせください。 GitHub は、ライセンス、レプリケーションの状態、およびアップグレード パスが安全に処理されることを確認するのに役立ちます。