記事のバージョン： Enterprise Server 2.17
High Availability設定について
High Availability 設定では、完全に冗長なセカンダリの GitHub Enterprise Server アプライアンスは、すべての主要なデータストアのレプリケーションによってプライマリアプライアンスとの同期を保ちます。
High Availability設定をする際には、プライマリからレプリカアプライアンスへのすべてのデータストア（Gitリポジトリ、MySQL、Redis、Elasticsearch）の一方方向の非同期レプリケーションが、自動的にセットアップされます。
GitHub Enterprise Server はアクティブ／パッシブ設定をサポートします。この設定では、レプリカアプライアンスはデータベースサービスをレプリケーションモードで実行しながらスタンバイとして実行しますが、アプリケーションサービスは停止します。
ターゲットとなる障害のシナリオ
以下に対する保護として、High Availability設定を使ってください。
- ソフトウェアのクラッシュ。オペレーティングシステムの障害や、アプリケーションが回復不能になった場合。
- ハードウェアの障害。ストレージのハードウェア、CPU、RAM、ネットワークインターフェースなどを含みます。
- 仮想ホストシステムの障害。計画外及びスケジュールされたAWSにおけるメンテナンスイベントを含みます。
- 論理的あるいは物理的に切断されたネットワーク。フェイルオーバーアプライアンスがその障害によって影響されない別のネットワーク上にある場合。
High Availability設定は、以下に対するソリューションとしては適切ではありません。
- スケーリング外。 Geo-replicationを使えば地理的にトラフィックを分散させることができるものの、書き込みのパフォーマンスはプライマリアプライアンスの速度と可用性によって制限されます。 詳細は「Geo-replication について」を参照してください。
- プライマリアプライアンスのバックアップ。 High Availabilityレプリカは、システム災害復旧計画のオフサイトバックアップを置き換えるものではありません。 データ破壊や損失の中には、プライマリからレプリカへ即座にレプリケーションされてしまうものもあります。 安定した過去の状態への安全なロールバックを保証するには、履歴スナップショットでの定期的なバックアップを行う必要があります。
- ダウンタイムゼロのアップグレード。 コントロールされた昇格のシナリオにおけるデータ損失やスプリットブレインの状況を避けるには、プライマリアプライアンスをメンテナンスモードにして、すべての書き込みが完了するのを待ってからレプリカを昇格させてください。
ネットワークトラフィックのフェイルオーバー戦略
フェイルオーバーの間は、ネットワークトラフィックをプライマリからレプリカへリダイレクトするよう、別個に設定管理しなければなりません。
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を有効化することをおすすめします。 Subdomain Isolationが有効化されている場合、追加のワイルドカードレコード(*.HOSTNAME)もロードバランサに解決されなければなりません。 詳しい情報については"Subdomain Isolationの有効化"を参照してください。
フェイルオーバーの間、プライマリアプライアンスはメンテナンスモードにしなければなりません。 ロードバランサは、レプリカがプライマリに昇格したときに自動的に検出するように設定することも、手動での設定変更が必要なようにしておくこともできます。 ユーザからのトラフィックに反応する前に、レプリカはプライマリに手動で昇格させておかなければなりません、 詳細は「ロードバランサとともに GitHub Enterprise Server を使用する」を参照してください。
GitHub Enterprise Serverの可用性は、https://HOSTNAME/statusというURLに対して返されるステータスコードをチェックすればモニタリングできます。 ユーザトラフィックを処理できるアプライアンスは、ステータスコード200 (OK)を返します。 いくつかの理由で、アプライアンスが503 (Service Unavailable) を返すことがあります。
- 2ノードの高可用性構成のレプリカなど、そのアプライアンスがパッシブなレプリカである場合。
- アプライアンスがメンテナンスモードになっている場合。
- アプライアンスがGeo-replication構成の一部で、ただしアクティブではないレプリカの場合。
以下からアクセスできるレプリケーションの概要ダッシュボードを使うこともできます。
https://HOSTNAME/setup/replication
レプリケーション管理のユーティリティ
GitHub Enterprise Server でレプリケーションを管理するには、SSH を使用してレプリカアプライアンスに接続して以下のコマンドラインユーティリティを使用します。
ghe-repl-setup
ghe-repl-setup コマンドは、GitHub Enterprise Server アプライアンスをレプリカスタンバイモードにします。
- 2 つのアプライアンス間の通信のために、暗号化されたOpenVPNトンネルが設定されます。
- レプリケーションのためのデータベースサービスが設定され、起動されます。
- アプリケーションサービスは無効化されます。 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.
レプリカモードを無効化してこれらの変更を取り消すには`ghe-repl-teardown'を実行してください。
新たに設定されたプライマリに対してレプリケーションを開始するには`ghe-repl-start'を実行してください。ghe-repl-start
ghe-repl-startコマンドは、すべてのデータストアのアクティブなレプリケーションを有効化します。
admin@169-254-1-2:~$ ghe-repl-start
Starting OpenVPN tunnel ...
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
レプリケーションの健全性と進行状況をモニタリングするには`ghe-repl-status'を使ってください。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 ...
Stopping OpenVPN tunnel ...
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 ...
| Stopping OpenVPN tunnel ...
| 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コマンドはレプリケーションモードを完全に無効化し、レプリカの設定を削除します。