クラスタの High Availability レプリケーションについて
高可用性に GitHub Enterprise Server のクラスター デプロイを構成することで、データセンターまたはクラウド リージョンの中断に対して保護できます。 高可用性構成では、レプリカ ノードの同じセットが、アクティブなクラスター内のノードと同期されます。 ハードウェアまたはソフトウェアの障害がアクティブなクラスタのデータセンターに影響を与える場合は、手動でレプリカノードにフェイルオーバーし、ユーザリクエストの処理を続行して、停止の影響を最小限に抑えることができます。
高可用性構成では、データ サービスをホストするノードは、レプリカ クラスターと定期的に同期されます。 レプリカ ノードはスタンバイで実行され、アプリケーションへのサービスや、ユーザー リクエストの処理は行われません。
GitHub Enterprise Server クラスタリングの包括的ディザスター リカバリー プランの一環として、高可用性を構成することをおすすめします。 また、定期的なバックアップを実行することをお勧めします。 詳しくは、「インスタンスでのバックアップの構成」を参照してください。
前提条件
ハードウェアとソフトウェア
アクティブなクラスタ内の既存のノードごとに、同一のハードウェアリソースを使用して2番目の仮想マシンをプロビジョニングする必要があります。 たとえば、クラスターに 13 個のノードがあり、各ノードに 12 個の vCPU、96 GB の RAM、750 GB の接続ストレージがある場合、それぞれが 12 個の vCPU、96 GB の RAM、750 GB の接続ストレージを備えた 13 個の新しい仮想マシンをプロビジョニングする必要があります。
新しい仮想マシンごとに、アクティブクラスタ内のノードで実行されているものと同じバージョンの GitHub Enterprise Server をインストールします。 ライセンスをアップロードしたり、追加の設定を実行したりする必要はありません。 詳しくは、「GitHub Enterprise Server インスタンスをセットアップする」を参照してください。
Note
高可用性レプリケーションに使う予定のノードは、スタンドアロンの GitHub Enterprise Server インスタンスである必要があります。 レプリカ ノードを 2 番目のクラスターとして初期化しないでください。
ネットワーク
プロビジョニングする新しいノードごとに静的 IP アドレスを割り当てる必要があります。また、接続を受け入れてクラスタのフロントエンド層のノードに転送するようにロードバランサを設定する必要があります。
プライマリ ノードとレプリカ ノード間の待機時間は 70 ミリ秒未満である必要があります。 ノードのネットワーク間にファイアウォールを設定することはお勧めしません。 レプリカ クラスター内のノード間のネットワーク接続の詳細については、「クラスタのネットワーク設定」を参照してください。
クラスタの High Availability レプリカを作成する
クラスターの高可用性レプリカを作成するには、次のタスクを完了する必要があります。 構成例をレビューすることもできます。
1. アクティブ ノードをプライマリ データセンターに割り当てる
レプリカ ノードのセカンダリ データセンターを定義する前に、アクティブ ノードをプライマリ データセンターに割り当てていることを確認してください。
-
クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
-
テキスト エディターで、
/data/user/common/cluster.conf
のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、cluster.conf
ファイルのバックアップを作成します。Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
クラスタのプライマリデータセンターの名前に注意します。 クラスター構成ファイルの上部にある
[cluster]
セクションでは、キーと値のペアprimary-datacenter
を使用して、プライマリ データセンターの名前を定義します。[cluster] mysql-master = HOSTNAME redis-master = HOSTNAME primary-datacenter = primary
- 必要に応じて、
primary-datacenter
の値を編集して、プライマリ データセンター名をよりわかりやすい名前に変更します。
- 必要に応じて、
-
クラスター構成ファイルでは、
[cluster "HOSTNAME"]
見出しの下に各ノードが示されます。 各ノードの見出しの下に、新しいキー/値ペアのペアを追加して、ノードをデータセンターに割り当てます。 上記のステップ 3 と同じ値primary-datacenter
を使用します。 たとえば、既定の名前 (default
) を使用する場合は、次のキーと値のペアを各ノードのセクションに追加します。datacenter = primary
完了すると、クラスタ設定ファイルの各ノードのセクションは次の例のようになります。 キー/値ペアの順序は問題になりません。
[cluster "HOSTNAME"] datacenter = default hostname = HOSTNAME ipv4 = IP-ADDRESS ... ...
Note
ステップ 3 でプライマリ データセンターの名前を変更した場合は、各ノードのセクションでキーと値のペア
consul-datacenter
を見つけ、その値を名前変更したプライマリ データセンターに変更します。 たとえば、プライマリ データセンターにprimary
という名前を付けた場合は、ノードごとに次のキーと値のペアを使用します。consul-datacenter = primary
-
新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、
screen
またはtmux
などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。ghe-cluster-config-apply
-
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
Finished cluster configuration
GitHub Enterprise Server がプロンプトに戻ったら、ノードをクラスタのプライマリデータセンターに割り当てます。
2. レプリカ ノードをクラスター構成ファイルに追加する
高可用性を構成するには、クラスタ内のすべてのアクティブ ノードに対応するレプリカ ノードを定義する必要があります。 アクティブ ノードとレプリカ ノードの両方を定義する新しいクラスター構成を作成するには、次のタスクを完了します。
- アクティブなクラスタ設定ファイルのコピーを作成します。
- コピーを編集して、アクティブノードに対応するレプリカ ノードを定義し、プロビジョニングした新しい仮想マシンの IP アドレスを追加します。
- クラスタ設定の変更されたコピーをアクティブな設定にマージします。
- 新しい設定を適用してレプリケーションを開始します。
構成例については、「構成例のレビュー」を参照してください。
-
クラスタ内のノードごとに、同じバージョンの GitHub Enterprise Server を実行して、同じ仕様で一致する仮想マシンをプロビジョニングします。 新しい各クラスターノードの IPv4 アドレスとホスト名に注意してください。 詳しい情報については、「前提条件」を参照してください。
Note
フェイルオーバー後に高可用性を再構成する場合は、代わりにプライマリ データセンターの古いノードを使用できます。
-
クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
-
既存のクラスタ設定をバックアップします。
cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
-
/home/admin/cluster-replica.conf
などの一時的な場所に、既存のクラスター設定ファイルのコピーを作成します。grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf
-
前のステップでコピーした一時クラスター構成ファイルから
[cluster]
セクションを削除します。git config -f ~/cluster-replica.conf --remove-section cluster
-
レプリカ ノードをプロビジョニングしたセカンダリ データセンターの名前を決定してから、一時クラスター設定ファイルを新しいデータセンター名で更新します。
SECONDARY
を、選んだ名前に置き換えます。sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf
-
レプリカ ノードのホスト名のパターンを決定します。
Warning
レプリカ ノードのホスト名は、一意で、対応するアクティブ ノードのホスト名とは異なっている必要があります。
-
ステップ 3 の一時クラスタ設定ファイルをテキストエディタで開きます。 たとえばVimを利用できます。
sudo vim ~/cluster-replica.conf
-
一時クラスタ設定ファイル内の各セクションで、ノードの設定を更新します。 クラスター構成ファイルでは、
[cluster "HOSTNAME"]
見出しの下に各ノードが示されます。- 上記のステップ 7 で選んだパターンに従って、セクション見出しの引用符で囲まれたホスト名とセクション内の
hostname
の値をレプリカ ノードのホスト名に変更します。 ipv4
という名前の新しいキーを追加し、値をレプリカ ノードの静的 IPv4 アドレスに設定します。- 新しいキーと値のペア
replica = enabled
を追加します。
[cluster "NEW REPLICA NODE HOSTNAME"] ... hostname = NEW REPLICA NODE HOSTNAME ipv4 = NEW REPLICA NODE IPV4 ADDRESS replica = enabled ... ...
- 上記のステップ 7 で選んだパターンに従って、セクション見出しの引用符で囲まれたホスト名とセクション内の
-
ステップ 4 で作成した一時クラスタ設定ファイルの内容をアクティブ設定ファイルに追加します。
cat ~/cluster-replica.conf >> /data/user/common/cluster.conf
-
セカンダリデータセンターのプライマリ MySQL ノードと Redis ノードを指定します。
REPLICA MYSQL PRIMARY HOSTNAME
とREPLICA REDIS PRIMARY HOSTNAME
を、既存の MySQL および Redis プライマリと一致するようにプロビジョニングしたレプリカ ノードのホスト名に置き換えます。git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME
Warning
続ける前に、クラスター構成ファイルを確認してください。
- トップ階層の
[cluster]
セクションで、mysql-master-replica
とredis-master-replica
の値が、フェールオーバー後に MySQL と Redis のプライマリとして機能するセカンダリ データセンター内のレプリカ ノードに対する正しいホスト名であることを保証します。 [cluster "ACTIVE NODE HOSTNAME"]
という名前の付いたアクティブ ノードの各セクションで、次のキーと値のペアをもう一度確認します。datacenter
は、最上位セクションprimary-datacenter
の[cluster]
値と一致する必要があります。consul-datacenter
は、datacenter
の値と一致する必要があります。これは、最上位セクション[cluster]
にあるprimary-datacenter
の値と同じです。
- アクティブ ノードごとに、同じロールを持つ 1 つのレプリカ ノードに対応するセクションが 1 つ存在するように構成します。 レプリカ ノードの各セクションで、各キーと値のペアを再確認します。
datacenter
は、他のすべてのレプリカ ノードと一致している必要があります。consul-datacenter
は、他のすべてのレプリカ ノードと一致している必要があります。hostname
は、セクション見出しのホスト名と一致する必要があります。ipv4
は、ノードの一意の静的 IPv4 アドレスと一致する必要があります。replica
はenabled
として構成する必要があります。
- 必要に応じて、使用されなくなったオフラインノードのセクションを削除してください。
構成例を確認するには、「構成例のレビュー」を参照してください。
- トップ階層の
-
新しいクラスタ設定を初期化します。 このコマンドの完了には時間がかかる場合があるため、
screen
またはtmux
などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。ghe-cluster-config-init
-
初期化が完了すると、GitHub Enterprise Server は次のメッセージを表示します。
Finished cluster initialization
-
新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、
screen
またはtmux
などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。ghe-cluster-config-apply
-
構成の実行が完了したら、クラスター レプリケーションが正しく設定され、動作していることを確認します。
ghe-cluster-repl-status
-
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
Finished cluster configuration
-
レプリカ ノードにフェイルオーバーした後にユーザからの接続を受け入れるロードバランサーを構成します。 詳しくは、「クラスタのネットワーク設定」を参照してください。
クラスタ内のノードの High Availability レプリケーションの設定が完了しました。 各アクティブノードは、設定とデータの複製を対応するレプリカ ノードに対して開始します。障害が発生した場合は、トラフィックをセカンダリ データセンターのロード バランサーに転送できます。 フェールオーバーの詳細については、「レプリカ クラスターへのフェールオーバーを開始する」を参照してください。
3. 構成例をレビューする
最上位の [cluster]
構成は、次の例のようになります。
[cluster]
mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
primary-datacenter = PRIMARY-DATACENTER-NAME
mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
mysql-auto-failover = false
...
クラスタのストレージ層のアクティブノードの設定は、次の例のようになります。
...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
datacenter = default
hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
ipv4 = IPV4-ADDRESS
consul-datacenter = default
consul-server = true
git-server = true
pages-server = true
mysql-server = true
elasticsearch-server = true
redis-server = true
memcache-server = true
metrics-server = true
storage-server = true
uuid = UUID SET AUTOMATICALLY
...
ストレージ層内の対応するレプリカ ノードの設定は、次の例のようになります。
- 対応するアクティブ ノードとの大きな違いは太字であることです。
- GitHub Enterprise Server は自動的に
uuid
の値を割り当てるため、初期化するレプリカ ノードでは、この値を定義しないようご注意ください。 *-server
キーで定義されたサーバー ロールは、対応するアクティブ ノードと一致します。
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
replica = enabled
ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
datacenter = SECONDARY DATACENTER NAME
hostname = UNIQUE REPLICA NODE HOSTNAME
consul-datacenter = SECONDARY DATACENTER NAME
consul-server = true
git-server = true
pages-server = true
mysql-server = true
elasticsearch-server = true
redis-server = true
memcache-server = true
metrics-server = true
storage-server = true
uuid = DO NOT DEFINE
...
アクティブ クラスター ノードとレプリカ クラスター ノード間のレプリケーションを監視する
クラスター内のアクティブ ノードとレプリカ ノード間の初回レプリケーションには時間がかかります。 時間は、複製するデータの量と GitHub Enterprise Server のアクティビティレベルによって異なります。
GitHub Enterprise Server 管理シェルから利用できるコマンドラインツールを使用して、クラスタ内の任意のノードの進行状況を監視できます。 管理シェルの詳細については、「管理シェル (SSH) にアクセスする」を参照してください。
すべてのサービスのレプリケーションを監視するには、次のコマンドを使用します。
ghe-cluster-repl-status
ghe-cluster-status
を使用すると、クラスターの全体的な正常性を確認することができます。 詳細については、「コマンド ライン ユーティリティ」を参照してください。
フェイルオーバー後の High Availability レプリケーションを再設定する
クラスターのアクティブ ノードからクラスタのレプリカ ノードにフェールオーバーした後、高可用性のレプリケーションを再設定するには、2 つの方法のうちいずれかを使用します。 選択する方法は、フェイルオーバーした理由と元のアクティブノードの状態によって異なります。
- セカンダリ データセンターの新しいアクティブノードごとに、レプリカ ノードの新しいセットをプロビジョニングして設定します。
- 元のアクティブ ノードを新しいレプリカ ノードとして使用します。
High Availability を再設定するプロセスは、High Availability の初期設定と同じです。 詳細については、「クラスターの High Availability レプリカを作成する」を参照してください。
元のアクティブ ノードを使用する場合は、高可用性を再構成した後、ノード上のメンテナンス モードの設定を解除する必要があります。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
クラスタの High Availability レプリケーションを無効化する
GitHub Enterprise Server のクラスター デプロイメントのレプリカ ノードへのレプリケーションを停止できます。
-
クラスタ内のいずれかのノードにSSHで接続してください。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
-
テキスト エディターで、
/data/user/common/cluster.conf
のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、cluster.conf
ファイルのバックアップを作成します。Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
最上位のセクション
[cluster]
で、redis-master-replica
とmysql-master-replica
のキーと値のペアを削除します。 -
レプリカ ノードの各セクションを削除します。 レプリカ ノードの場合、
replica
はenabled
として構成されます。 -
新しい設定を適用してください。 このコマンドの完了には時間がかかる場合があるため、
screen
またはtmux
などのターミナル マルチプレクサーでコマンドを実行することをお勧めします。ghe-cluster-config-apply
-
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
Finished cluster configuration