クラスタの High Availability レプリケーションを設定する

クラスタの 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
  ...
...
```
ステップ 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
```

クラスタの High Availability レプリケーションを設定する

この記事の内容