High Availability設定をする際には、プライマリからレプリカアプライアンスへのすべてのデータストア（Gitリポジトリ、MySQL、Redis、Elasticsearch）の一方方向の非同期レプリケーションが、自動的にセットアップされます。 ほとんどの GitHub Enterprise Server 構成設定も、[Management Console] パスワードを含めてレプリケートされます。 詳しくは、「管理コンソールからのインスタンスの管理」を参照してください。
GitHub Enterprise Server はアクティブ／パッシブ設定をサポートします。この設定では、レプリカアプライアンスはデータベースサービスをレプリケーションモードで実行しながらスタンバイとして実行しますが、アプリケーションサービスは停止します。
レプリケーションが確立されると、レプリカ アプライアンスで [Management Console] にアクセスできなくなります。 ポート 8443 でレプリカの IP アドレスまたはホスト名に移動すると、"レプリケーション モードのサーバー" というメッセージが表示されます。これは、アプライアンスが現在レプリカとして構成されていることを示します。
注: GitHub Enterprise Server では、最大で 8 つの高可用性レプリカ (パッシブとアクティブ/Go のいずれでも) が利用できます。
ターゲットとなる障害のシナリオ
以下に対する保護として、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の有効化」を参照してください。
フェイルオーバーの間、プライマリアプライアンスはメンテナンスモードにしなければなりません。 ロードバランサは、レプリカがプライマリに昇格したときに自動的に検出するように設定することも、手動での設定変更が必要なようにしておくこともできます。 ユーザからのトラフィックに反応する前に、レプリカはプライマリに手動で昇格させておかなければなりません、 詳しくは、「Using GitHub Enterprise Server with a load balancer」を参照してください。
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 syncghe-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 コマンドはレプリケーション モードを完全に無効にし、レプリカ構成を削除します。