高可用性レプリカに関する一般的な質問への回答

レプリカの種類と機能

HA デプロイで使用されるレプリカの種類は何ですか?

高可用性 (HA) デプロイには、次の 3 種類のレプリカがあります。

パッシブレプリカ
アクティブレプリカ

キャッシュレプリカ (リポジトリキャッシュと呼ばれます)。

        **パッシブ レプリカ** は単にプライマリ インスタンスからのデータを同期するだけで、GitHub トラフィックを処理しません。 ただし、オペレーターは、必要に応じてパッシブ レプリカをプライマリに昇格させることができます。

        **geoレプリカ**は**アクティブなレプリカ**の例です (これらの用語は同じ意味で使用されることがよくあります)。 アクティブ レプリカは、プライマリからのデータを同期します。 アクティブなレプリカは、 GitHub トラフィックを直接処理することも、プライマリにプロキシすることもできます。

        **キャッシュ レプリカ** は、プライマリから Git と Git Large File Storage (Git LFS) の両方のデータを同期します。 キャッシュ レプリカは、CI ファームなどの読み取り負荷の高いシナリオ向けに設計されています。 ローカルコピーを持っているリポジトリに対してのみ、読み取り/フェッチ/クローンを受け入れます。 その他のリポジトリの場合、エラーが返されます。 エラー メッセージを含むプッシュは常に拒否されます。

すべてのレプリカの種類をプライマリに昇格できますか?

パッシブレプリカとアクティブレプリカのみをプライマリに昇格できます。キャッシュレプリカをプライマリに昇格することはできません。

1 つのデプロイにすべてのレプリカを含めることができますか?

1 つのデプロイに、アクティブレプリカ、パッシブレプリカ、キャッシュレプリカを一度に含めることができます。

プライマリインスタンスはレプリカの書き込みを待機しますか?

プライマリインスタンスは、レプリカの書き込みを待機しません。 HA では、プッシュがプライマリおよびすべてのパッシブレプリカとアクティブレプリカに書き込まれます。ただし、プライマリノードが唯一の投票ノードであるため、プッシュはプライマリで成功した場合に受け入れられると見なされます。

通信とネットワークの要件

アクティブレプリカと通信できるエンティティは何ですか?

プライマリインスタンスは、アクティブレプリカと通信してデータを同期し、アクティブレプリカがプライマリにプロキシする要求を処理します。 GitHub Web、API、Git トラフィック (人間と自動化の両方から) をアクティブレプリカに直接ルーティングできます。そのため、アクティブレプリカを対象としたトラフィックが実際に DNS に到達するように DNS を構成することが重要です。

パッシブレプリカと通信できるエンティティは何ですか?

プライマリインスタンスはパッシブレプリカと通信してデータを同期します。パッシブレプリカは、他の GitHub トラフィックを受信または処理しません。

キャッシュレプリカと通信できるエンティティは何ですか?

読み取り専用の Git トラフィックは、主に CI ファームなどの自動化から、キャッシュレプリカにルーティングして処理できます。これを有効にするには、関連するトラフィックをキャッシュレプリカに転送するように DNS を構成する必要があります。キャッシュレプリカは、ユーザートラフィックやプッシュトラフィックを処理するようには設計されていません。

レプリカはプライマリと併配置する必要がありますか?

レプリカをプライマリと併配置する必要はありません。定義上、geo レプリカはプライマリから地理的に離れ、同じデータセンターには存在しません。キャッシュレプリカにも併配置要件はありません。

ただし、プライマリ障害時のフェールオーバーを高速化するために、少なくとも 1 つのパッシブレプリカを同じデータセンター内のプライマリと併配置することをお勧めします。完全なデータセンターの停止が発生した場合は、地理的に分散されたパッシブレプリカを昇格させることができます。

プライマリとレプリカの間の待機時間の要件は何ですか?

プライマリレプリカとアクティブレプリカには、厳密な待機時間要件があります。プライマリレプリカとパッシブレプリカ、およびプライマリレプリカとキャッシュレプリカには、推奨される待機時間の要件があります。詳細については、「高可用性レプリカの作成」および「高可用性構成の監視」を参照してください。必要な値と推奨値を超えるネットワーク待機時間により、レプリカが常に遅れる可能性があります。

管理アクセスと監視

[Management Console] は、レプリカで利用可能ですか?

[Management Console] は、パッシブレプリカまたはキャッシュレプリカでは使用できません。アクティブレプリカでのみ使用できます (アクティブレプリカは、ほとんどの要求をプライマリに転送します)。

レプリカに SSH 接続できますか?

管理シェルアクセス権を持つオペレーターは、任意のレプリカに SSH 接続できます。オペレーターは、[Management Console] を使用して新しいレプリカに公開キーを追加してから、レプリカをクラスターに追加できます。詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。

レプリカのサポートバンドルのしくみ

クラスターバンドルまたはノード固有のバンドルを生成できます。クラスターバンドルには HA デプロイ内のすべてのノードのバンドルが含まれますが、ノード固有のバンドルには 1 つのノードからのデータだけが含まれます。

レプリカを監視することはできますか?

すべてのレプリカを監視できます。プライマリインスタンスの [Management Console] には、デプロイ内のパッシブレプリカノードとアクティブレプリカノードを含むすべてのノードのダッシュボードが用意されています。

さらに、デプロイ内のすべてのノードからサードパーティの監視プラットフォームにメトリックとログをエクスポートできます。

レプリカノード間のデータレプリケーションの状態を監視する方法については、高可用性構成の監視を参照してください。

バックアップは、データのコピーを作成し、別の GitHub Enterprise Server 環境に復元できるようにするために使用します。お客様は、多くの場合、バックアップを使用して災害から復旧したり、新しいインストールを作成したりします。要するに、バックアップデータは別の GitHub Enterprise Server インスタンスを復元するために使用されますが、レプリカは高可用性と冗長性をリアルタイムで実現するように設計されています。

レプリカ自体はGitHub Enterprise Server インスタンスです。 Backup-host はGitHub Enterprise Server インストールではありません。

レプリカで実行されているソフトウェアは何ですか?

レプリカは、GitHub Enterprise Server の個別のインストールです。プライマリインスタンスとすべてのレプリカで、同じバージョンの GitHub Enterprise Server が実行されている必要があります。

メンテナンス操作

アップグレードに推奨される一連の操作は何ですか?

プライマリレプリカとすべてのレプリカでメンテナンス期間を開始します。
すべてのレプリカでレプリケーションを停止します。
プライマリをターゲットバージョンにアップグレードします。
レプリカを同じターゲットバージョンにアップグレードします。すべてのレプリカを並列でアップグレードできます。
すべてのアップグレードが完了したら、レプリケーションプロセスを再起動します。
メンテナンス期間を閉じます。

場合によっては、レプリカのアップグレードを後で延期することが必要になる場合があります。その場合は、デプロイからレプリカノードを削除し、スタンドアロンノードに変換します。プライマリと同じバージョンにアップグレードし、デプロイに追加し直します。

ホットパッチの推奨される一連の操作は何ですか?

ホットパッチは、中断を最小限に抑えながら実行できます。最初にプライマリにホットパッチを適用してから、レプリカにホットパッチを適用できます。

適切なレプリカの種類の選択

パッシブレプリカを使用する場合

高可用性が必要で、プライマリがダウンした場合に最新のインスタンスに切り替える必要がある場合は、パッシブレプリカを利用してください。ほとんどのお客様はパッシブレプリカを使用しています。

Geo レプリカを使用する場合

地理的に分散した開発者の従業員がいる場合は、geo レプリカを設定すると、特定のリージョンのユーザーに役立ちます。たとえば、北米、ヨーロッパ、アジアにエンジニアリングチームを持つ多国籍企業を想像してみてください。プライマリインスタンスが米国にある場合、ヨーロッパに geo レプリカをデプロイすると、ヨーロッパのユーザーの読み取り操作のパフォーマンスが大幅に向上する可能性があります。ただし、書き込み操作でも同じことはできません。操作が完了する前に、すべての書き込みが geo レプリカとプライマリの両方に到達する必要があります。プライマリとレプリカ間の地理的な距離により待機時間が長くなり、書き込み操作が遅くなる可能性があります。

キャッシュレプリカを使用するタイミング

CI ファームのような読み取り負荷の高いユースケースの場合は、キャッシュレプリカの方が適しています。キャッシュレプリカが理にかなっているシナリオをいくつか次に示します。

メインデータセンターへの帯域幅が制限されているリージョンに小規模なサテライトオフィスがある会社。開発者はリポジトリにすばやくアクセスする必要がありますが、書き込みアクセスは必要ありません。
リポジトリを頻繁に複製する必要があり、プライマリインスタンスへのネットワークトラフィックを最小限に抑える必要がある、リモートデータセンターで CI/CD ジョブを実行している組織。

設計上、キャッシュレプリカにはトレードオフが伴います。キャッシュレプリカは最終的に一貫性があり、常に最新のリポジトリコンテンツを提供するとは限りません。ただし、最新の変更がレプリカに反映されたときにトリガーされる Webhook があるため、関連する CI/CD ジョブを開始できます。キャッシュレプリカを使用する GitHub のお客様はほとんどありません。