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

クラスタの High Availability レプリケーションについて

High Availability を実現するために、GitHub Enterprise Server のクラスタデプロイメントを設定できます。この� �合、パッシブノードの同一のセットがアクティブクラスタ内のノードと同期されます。ハードウェアまたはソフトウェアの障害がアクティブなクラスタのデータセンターに影響を与える� �合は、手動でレプリカノードにフェイルオーバーし、ユーザリクエストの処理を続行して、停止の影響を最小限に抑えることができます。

High Availability モードでは、各アクティブノードは対応するパッシブノードと定期的に同期します。パッシブノードはスタンバイで実行され、アプリケーションへのサービス提供や、ユーザ要求の処理は行われません。

GitHub Enterprise Server の包括的なシステ� 災害復旧計画の一部として High Availability を設定することをお勧めします。また、定期的なバックアップを実行することをお勧めします。詳細については、「アプライアンスでのバックアップの設定」を参照してく� さい。

前提条件

ハードウェアとソフトウェア

アクティブなクラスタ内の既存のノードごとに、同一のハードウェアリソースを使用して2番目の仮想マシンをプロビジョニングする必要があります。たとえば、クラスターに 11 個のノードがあり、各ノードに 12 個の vCPU、96 GB の RAM、および 750 GB の接続ストレージがある� �合、それぞれが 12 個の vCPU、96 GB の RAM、および 750 GB の接続ストレージを備えた 11 個の新しい仮想マシンをプロビジョニングする必要があります。

新しい仮想マシンごとに、アクティブクラスタ内のノードで実行されているものと同じバージョンの GitHub Enterprise Server をインストールします。ライセンスをアップロードしたり、追� の設定を実行したりする必要はありません。詳細については、「GitHub Enterprise Server インスタンスをセットアップする」を参照してく� さい。

注: High Availability レプリケーションに使用する予定のノードは、スタンドアロンの GitHub Enterprise Server インスタンスである必要があります。パッシブノードを2番目のクラスタとして初期化しないでく� さい。

ネットワーク

プロビジョニングする新しいノードごとに静的 IP アドレスを割り当てる必要があります。また、接続を受け入れてクラスタのフロントエンド層のノードに転送するようにロードバランサを設定する必要があります。

アクティブクラスタを使用するネットワークとパッシブクラスタを使用するネットワークの間にファイアウォールを設定することはお勧めしません。アクティブノードのあるネットワークとパッシブノードのあるネットワークの間の遅延は、70 ミリ秒未満である必要があります。パッシブクラスター内のノード間のネットワーク接続の詳細については、「クラスターのネットワーク構成」を参照してく� さい。

アクティブノードをプライマリデータセンターに割り当てる

パッシブノードのセカンダリデータセンターを定義する前に、アクティブノードをプライマリデータセンターに割り当てていることを確認してく� さい。

クラスタ内のいずれかのノードにSSHで接続してく� さい。詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
/data/user/common/cluster.conf のクラスター設定ファイルをテキストエディターで開いてく� さい。たとえばVimを利用できます。
```
sudo vim /data/user/common/cluster.conf
```
クラスタのプライマリデータセンターの名前に注意します。クラスター構成ファイルの上部にある [cluster] セクションでは、キーと値のペア primary-datacenter を使用して、プライマリデータセンターの名前を定義します。既定では、クラスターのプライマリデータセンターの名前は default です。
```
[cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = default
```
- 必要に応じて、primary-datacenter の値を編集して、プライマリデータセンター名をよりわかりやすい名前に変更します。
クラスター構成ファイルでは、[cluster "HOSTNAME"] 見出しの下に各ノードが示されます。各ノードの見出しの下に、新しいキー/値ペアのペアを追� して、ノードをデータセンターに割り当てます。上記のステップ 3 と同じ値 primary-datacenter を使用します。たとえば、既定の名前 (default) を使用する� �合は、次のキーと値のペアを各ノードのセクションに追� します。
```
datacenter = default
```
完了すると、クラスタ設定ファイルの各ノードのセクションは次の例のようになります。キー/値ペアの� �序は問題になりません。
```
[cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP ADDRESS
  ...
...
```
注: ステップ 3 でプライマリデータセンター名を変更した� �合は、各ノードのセクションでキーと値のペア consul-datacenter を見つけ、その値を名前変更したプライマリデータセンターに変更します。たとえば、プライマリデータセンターに primary という名前を付けた� �合は、ノードごとに次のキーと値のペアを使用します。
```
consul-datacenter = primary
```
新しい設定を適用してく� さい。このコマンドの完了には時間がかかる� �合があるため、screen または tmux などのターミナルマルチプレクサーでコマンドを実行することをお勧めします。
```
ghe-cluster-config-apply
```
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
```
Finished cluster configuration
```

GitHub Enterprise Server がプロンプトに戻ったら、ノードをクラスタのプライマリデータセンターに割り当てます。

パッシブノードをクラスタ設定ファイルに追� する

High Availability を設定するには、クラスタ内のすべてのアクティブノードに対応するパッシブノードを定義する必要があります。次の手� �では、アクティブノードとパッシブノードの両方を定義する新しいクラスタ設定を作成します。このチュートリアルの内容は次のとおりです。

アクティブなクラスタ設定ファイルのコピーを作成します。
コピーを編集して、アクティブノードに対応するパッシブノードを定義し、プロビジョニングした新しい仮想マシンの IP アドレスを追� します。
クラスタ設定の変更されたコピーをアクティブな設定にマージします。
新しい設定を適用してレプリケーションを開始します。

構成例については、「構成例」を参照してく� さい。

クラスタ内のノードごとに、同じバージョンの GitHub Enterprise Server を実行して、同じ仕様で一致する仮想マシンをプロビジョニングします。新しい各クラスターノードの IPv4 アドレスとホスト名に注意してく� さい。詳しい情� �については、「前提条件」を参照してく� さい。

注: フェイルオーバー後に High Availability を再構成する� �合は、代わりにプライマリデータセンターの古いノードを使用できます。
クラスタ内のいずれかのノードにSSHで接続してく� さい。詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。

既存のクラスタ設定をバックアップします。

cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

/home/admin/cluster-passive.conf などの一時的な� �所に、既存のクラスター設定ファイルのコピーを作成します。 IP アドレス (ipv*)、UUID (uuid)、WireGuard の公開キー (wireguard-pubkey) に対するキーと値のペアを削除します。
```
grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
```
前のステップでコピーした一時クラスター構成ファイルから [cluster] セクションを削除します。
```
git config -f ~/cluster-passive.conf --remove-section cluster
```
パッシブノードをプロビジョニングしたセカンダリデータセンターの名前を決定してから、一時クラスタ設定ファイルを新しいデータセンター名で更新します。 SECONDARY を、選ん� 名前に置き換えます。
```
sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-passive.conf
```
パッシブノードのホスト名のパターンを決定します。

警告: パッシブノードのホスト名は一意であり、対応するアクティブノードのホスト名とは違うものにする必要があります。
ステップ 3 の一時クラスタ設定ファイルをテキストエディタで開きます。たとえばVimを利用できます。
```
sudo vim ~/cluster-passive.conf
```
一時クラスタ設定ファイル内の各セクションで、ノードの設定を更新します。クラスター構成ファイルでは、[cluster "HOSTNAME"] 見出しの下に各ノードが示されます。
- 上記のステップ 7 で選ん� パターンに従って、セクション見出しの引用符で囲まれたホスト名とセクション内の hostname の値をパッシブノードのホスト名に変更します。
- ipv4 という名前の新しいキーを追� し、その値をパッシブノードの静的 IPv4 アドレスに設定します。
- 新しいキーと値のペア replica = enabled を追� します。
```
[cluster "NEW PASSIVE NODE HOSTNAME"]
  ...
  hostname = NEW PASSIVE NODE HOSTNAME
  ipv4 = NEW PASSIVE NODE IPV4 ADDRESS
  replica = enabled
  ...
...
```
ステップ 4 で作成した一時クラスタ設定ファイルの内容をアクティブ設定ファイルに追� します。
```
cat ~/cluster-passive.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
```
警告: 続ける前に、クラスター構成ファイルを確認してく� さい。
- トップレベルの [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
```
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
```
Finished cluster configuration
```
パッシブノードにフェイルオーバーした� �合にユーザからの接続を受け入れるロードバランサを設定します。詳細については、クラスターネットワーク構成に関する記事を参照してく� さい。

クラスタ内のノードの High Availability レプリケーションの設定が完了しました。各アクティブノードは、対応するパッシブノードへの設定とデータの複製を開始します。障害が発生した� �合は、トラフィックをセカンダリデータセンターのロードバランサに転送できます。フェールオーバーの詳細については、「レプリカクラスターへのフェールオーバーの開始」を参照してく� さい。

構成例

最上位の [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 PASSIVE MYSQL MASTER
  redis-master-replica = HOSTNAME OF PASSIVE 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
  vpn = IPV4 ADDRESS SET AUTOMATICALLY
  uuid = UUID SET AUTOMATICALLY
  wireguard-pubkey = PUBLIC KEY SET AUTOMATICALLY
...

ストレージ層内の対応するパッシブノードの設定は、次の例のようになります。

対応するアクティブノードとの大きな違いは太字であることです。
GitHub Enterprise Server は、vpn、uuid、および wireguard-pubkey の値を自動的に割り当てるため、初期化するパッシブノードの値を定義しないでく� さい。
*-server キーで定義されたサーバーロールは、対応するアクティブノードと一致します。

...
[cluster "UNIQUE PASSIVE NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE PASSIVE 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
  vpn = DO NOT DEFINE
  uuid = DO NOT DEFINE
  wireguard-pubkey = DO NOT DEFINE
...

アクティブクラスターノードとパッシブクラスターノード間のレプリケーションを監視する

クラスタ内のアクティブノードとパッシブノード間の初期レプリケーションには時間がかかります。時間は、複製するデータの量と GitHub Enterprise Server のアクティビティレベルによって異なります。

GitHub Enterprise Server 管理シェルから利用できるコマンドラインツールを使用して、クラスタ内の任意のノードの進行状況を監視できます。管理シェルの詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。

データベースのレプリケーションの監視する:
```
/usr/local/share/enterprise/ghe-cluster-status-mysql
```
リポジトリと Gist データのレプリケーションを監視する:
```
ghe-spokes status
```
添付ファイルと LFS データのレプリケーションを監視する:
```
ghe-storage replication-status
```
Pages データのレプリケーションを監視する:
```
ghe-dpages replication-status
```

ghe-cluster-status を使用すると、クラスターの全体的な正常性を確認することができます。詳細については、「コマンドラインユーティリティ」を参照してく� さい。

フェイルオーバー後の High Availability レプリケーションを再設定する

クラスタのアクティブノードからクラスタのパッシブノードにフェイルオーバーした後、2 つの方法で High Availability レプリケーションを再設定できます。

新しいパッシブノードのプロビジョニングと設定

フェイルオーバー後、2 つの方法で High Availability を再設定できます。選択する方法は、フェイルオーバーした理由と元のアクティブノードの状態によって異なります。

セカンダリデータセンターの新しいアクティブノードごとに、パッシブノードの新しいセットをプロビジョニングして設定します。
古いアクティブノードを新しいパッシブノードとして使用します。

High Availability を再設定するプロセスは、High Availability の初期設定と同じです。詳細については、「クラスターの High Availability レプリカを作成する」を参照してく� さい。

クラスタの High Availability レプリケーションを無効化する

GitHub Enterprise Server のクラスタデプロイメントのパッシブノードへのレプリケーションを停止できます。

クラスタ内のいずれかのノードにSSHで接続してく� さい。詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
/data/user/common/cluster.conf のクラスター設定ファイルをテキストエディターで開いてく� さい。たとえばVimを利用できます。
```
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
```

GitHub Enterprise Server がプロンプトに戻ったら、High Availability レプリケーションの無効化が完了したことになります。