高可用性構成について

高可用性構成においては、完全に冗長なセカンダリの GitHub Enterprise Server アプライアンスが、すべての主要データストアのレプリケーションを通じてプライマリアプライアンスとの同期を保ちます。

この記事で

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

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

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

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

メモ

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

狙いを定めた障害シナリオ

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

データ 再利用可能.enterprise_installation.haとクラスタリングの失敗シナリオ %}

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

  •         **スケールアウト**: geo レプリケーションを使えば地理的にトラフィックを分散させることができるものの、書き込みのパフォーマンスはプライマリ アプライアンスの速度と可用性によって制限されます。 詳しくは、「[AUTOTITLE](/admin/enterprise-management/configuring-high-availability/about-geo-replication)」をご覧ください。

  •         **CI/CD の読み込み**: プライマリ インスタンスから地理的に離れている多数の CI クライアントがある場合は、リポジトリ キャッシュを構成するとメリットが得られる場合があります。 詳しくは、「[AUTOTITLE](/admin/enterprise-management/caching-repositories/about-repository-caching)」をご覧ください。

  •         **プライマリ アプライアンスのバックアップ**: 高可用性レプリカは、災害復旧計画におけるオフサイトバックアップを置き換えるものではありません。 データ破壊や損失の中には、プライマリからレプリカへ即座にレプリケーションされてしまうものもあります。 安定した過去の状態への安全なロールバックを保証するには、履歴スナップショットでの定期的なバックアップを行う必要があります。

  •         **ダウンタイムなしのアップグレード**: コントロールされた昇格のシナリオにおけるデータ損失やスプリットブレインの状況を避けるには、プライマリアプライアンスをメンテナンスモードにして、すべての書き込みが完了するのを待ってからレプリカを昇格させてください。

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

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

DNSフェイルオーバー

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

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

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

負荷分散装置

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

フェイルオーバーの間、プライマリアプライアンスはメンテナンスモードにしなければなりません。 ロードバランサは、レプリカがプライマリに昇格したときに自動的に検出するように設定することも、手動での設定変更が必要なようにしておくこともできます。 ユーザからのトラフィックに反応する前に、レプリカはプライマリに手動で昇格させておかなければなりません、 詳しくは、「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 アクセス権を持つユーザーは、コマンド ライン ユーティリティを使用してレプリケーションを管理できます。 詳しくは、「コマンド ライン ユーティリティ」をご覧ください。

参考資料

  •         [AUTOTITLE](/admin/enterprise-management/configuring-high-availability/creating-a-high-availability-replica)

  •         [AUTOTITLE](/admin/configuration/configuring-network-settings/network-ports)