Skip to main content
ドキュメントへの更新が� �繁に発行されており、このページの翻訳はま� 行われている� �合があります。最新情� �については、英語版のドキュメントをご覧く� さい。
� 

� 

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい。

High Availability設定について

この記事では、次の� �目が扱われます。

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

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

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

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

注: GitHub Enterprise Server では、最大で 8 つの高可用性レプリカ (パッシブとアクティブ/Go のいずれでも) が利用できます。

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

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

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

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

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

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

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

DNSフェイルオーバー

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

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

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

Load Balancer

ロードバランサの設計では、ネットワークデバイスを使って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) を返します。 いくつかの理由でアプライアンスが 503 (サービス利用不可) を返す� �合があります。

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

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

https://HOSTNAME/setup/replication

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

GitHub Enterprise Server でレプリケーションを管理するには、SSH を使用してレプリカアプライアンスに接続して以下のコマンドラインユーティリティを使用します。

ghe-repl-setup

ghe-repl-setup コマンドは、GitHub Enterprise Server アプライアンスをレプリカ スタンバイ モードにします。

  • 2 つのアプライアンス間の通信のために、暗号化された WireGuard VPN トンネルが設定されます。
  • レプリケーションのためのデータベースサービスが設定され、起動されます。
  • アプリケーションサービスは無効化されます。 HTTP、Git、あるいはその他のサポートされているプロトコルでレプリカアプライアンスへアクセスしようとすると、"appliance in replica mode"メンテナンスページあるいはエラーメッセージが返されます。
admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

ghe-repl-start コマンドは、すべてのデータストアのアクティブなレプリケーションを有効にします。

admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

ghe-repl-status コマンドは、データストア レプリケーション ストリー� ごとに OK、WARNING、または CRITICAL 状態を返します。 レプリケーション チャネルのいずれかが WARNING 状態の� �合、コマンドはコード 1 で終了します。 同様に、チャネルのいずれかが CRITICAL 状態の� �合、コマンドはコード 2 で終了します。

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

-v および -vv オプションを使用すると、各データストアのレプリケーション状態の詳細が得られます。

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-stop

ghe-repl-stop コマンドは、すべてのデータストアのレプリケーションを一時的に無効にし、レプリケーション サービスを停止します。 レプリケーションを再開するには、ghe-repl-start コマンドを使用します。

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Success: replication was stopped for all services.

ghe-repl-promote

ghe-repl-promote コマンドはレプリケーションを無効にし、レプリカ アプライアンスをプライマリに変換します。 アプライアンスはオリジナルのプライマリと同じ設定がなされ、すべてのサービスが有効化されます。

レプリカを昇� �させても、既存のアプライアンスのためのレプリケーションは自動的にセットアップされません。 レプリカを昇� �させたあと、希望する� �合には新しいプライマリから既存のアプライアンス及び以前のプライマリへのレプリケーションをセットアップできます。

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

ghe-repl-teardown コマンドはレプリケーション モードを完全に無効にし、レプリカ構成を削除します。

参考資料