Enterprise Server 3.15 は、現在リリース候補として使用できます。

High Availability設定について

High Availability 設定では、完全に冗長なセカンダリの GitHub Enterprise Server アプライアンスは、すべての主要なデータストアのレプリケーションによってプライマリアプライアンスとの同期を保ちます。

この記事の内容

High Availability設定をする際には、プライマリからレプリカアプライアンスへのすべてのデータストア（Gitリポジトリ、MySQL、Redis、Elasticsearch）の一方方向の非同期レプリケーションが、自動的にセットアップされます。 ほとんどの GitHub Enterprise Server 構成設定も、[Management Console] パスワードを含めてレプリケートされます。 詳しくは、「Web UI からインスタンスを管理する」を参照してください。

GitHub Enterprise Server はアクティブ／パッシブ設定をサポートします。この設定では、レプリカアプライアンスはデータベースサービスをレプリケーションモードで実行しながらスタンバイとして実行しますが、アプリケーションサービスは停止します。

レプリケーションが確立されると、レプリカ アプライアンスで [Management Console] にアクセスできなくなります。 ポート 8443 でレプリカの IP アドレスまたはホスト名に移動すると、"レプリケーション モードのサーバー" というメッセージが表示されます。これは、アプライアンスが現在レプリカとして構成されていることを示します。

レプリカ アプライアンスが Git クライアント要求を受け入れると、これらの要求はアクティブなアプライアンスに転送されます。

Note

GitHub Enterprise Server では、高可用性レプリカ（パッシブおよびアクティブ/ジオレプリカ、リポジトリキャッシュインスタンスを含む）は最大8つまで許可されています。

ターゲットとなる障害のシナリオ

以下に対する保護として、High Availability設定を使ってください。

  • ソフトウェアのクラッシュ: オペレーティング システムの障害や、回復不能なアプリケーションによる。
  • ハードウェアの障害: ストレージ ハードウェア、CPU、RAM、ネットワーク インターフェイスなどを含む。
  • 仮想化ホスト システムの障害: AWS、Azure、または GCP の計画外とスケジュールされたメンテナンス イベントを含む。
  • 論理的あるいは物理的に切断されたネットワーク: フェールオーバー アプライアンスがその障害によって影響されない別のネットワーク上にある場合。

High Availability設定は、以下に対するソリューションとしては適切ではありません。

  • スケールアウト: geo レプリケーションを使えば地理的にトラフィックを分散させることができるものの、書き込みのパフォーマンスはプライマリ アプライアンスの速度と可用性によって制限されます。 詳しくは、「Geo-replicationについて」を参照してください。
  • CI/CD の読み込み: プライマリ インスタンスから地理的に離れている多数の CI クライアントがある場合は、リポジトリ キャッシュを構成するとメリットが得られる場合があります。 詳しくは、「リポジトリのキャッシュについて」を参照してください。
  • プライマリ アプライアンスのバックアップ: High Availabilityレプリカは、システム災害復旧計画のオフサイトバックアップを置き換えるものではありません。 データ破壊や損失の中には、プライマリからレプリカへ即座にレプリケーションされてしまうものもあります。 安定した過去の状態への安全なロールバックを保証するには、履歴スナップショットでの定期的なバックアップを行う必要があります。
  • ダウンタイムなしのアップグレード: コントロールされた昇格のシナリオにおけるデータ損失やスプリットブレインの状況を避けるには、プライマリアプライアンスをメンテナンスモードにして、すべての書き込みが完了するのを待ってからレプリカを昇格させてください。

ネットワークトラフィックのフェイルオーバー戦略

フェイルオーバーの間は、ネットワークトラフィックをプライマリからレプリカへリダイレクトするよう、別個に設定管理しなければなりません。

DNSフェイルオーバー

DNS フェイルオーバーでは、プライマリの GitHub Enterprise Server アプライアンスを指す DNS レコードに短い TTL 値を使用します。 60秒から5分の間のTTLを推奨します。

フェイルオーバーの間、プライマリはメンテナンスモードにして、プライマリのDNSレコードはレプリカアプライアンスのIPアドレスへリダイレクトしなければなりません。 トラフィックをプライマリからレプリカへリダイレクトするのに要する時間は、TTLの設定とDNSレコードの更新に必要な時間に依存します。

Geo-replication を使用している場合は、トラフィックを最も近いレプリカに転送するように Geo DNS を設定する必要があります。 詳しくは、「Geo-replicationについて」を参照してください。

Load Balancer

ロードバランサの設計では、ネットワークデバイスを使ってGit及びHTTPのトラフィックを個々のGitHub Enterprise Serverアプライアンスに向かわせます。 ロードバランサを使って、セキュリティのためにアプライアンスへの直接のトラフィックを制限したり、必要に応じてDNSのレコードを変更することなくトラフィックをリダイレクトしたりできます。 PROXYプロトコルをサポートするTCPベースのロードバランサを使うことを強くおすすめします。 GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている場合、追加のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳しくは、「Subdomain Isolationの有効化」を参照してください。

フェイルオーバーの間、プライマリアプライアンスはメンテナンスモードにしなければなりません。 ロードバランサは、レプリカがプライマリに昇格したときに自動的に検出するように設定することも、手動での設定変更が必要なようにしておくこともできます。 ユーザからのトラフィックに反応する前に、レプリカはプライマリに手動で昇格させておかなければなりません、 詳しくは、「GitHub Enterprise Server でロードバランサを使用する」を参照してください。

https://HOSTNAME/status URL に対して返される状態コードを確認して、GitHub Enterprise Server の可用性を監視できます。 ユーザー トラフィックを処理できるアプライアンスは、状態コード 200 (OK) を返します。 アプライアンスは、いくつかの理由で、この URL および他の Web や API 要求に対して 503 (サービス利用不可) を返す場合があります。

  • 2ノードの高可用性構成のレプリカなど、そのアプライアンスがパッシブなレプリカである場合。
  • アプライアンスがメンテナンスモードになっている場合。
  • アプライアンスがGeo-replication構成の一部で、ただしアクティブではないレプリカの場合。

以下からアクセスできるレプリケーションの概要ダッシュボードを使うこともできます。

https://HOSTNAME/setup/replication

レプリケーション管理のユーティリティ

High Availability 設定のインスタンスへの管理 SSH アクセス権を持つユーザーは、コマンド ライン ユーティリティを使用してレプリケーションを管理できます。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。

参考資料