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

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

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

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

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

必要な環境

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

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

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

Note: 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
```
パッシブノードのホスト名のパターンを決定します。

Warning: パッシブノードのホスト名は一意であり、対応するアクティブノードのホスト名とは違うものにする必要があります。
ステップ 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
```
Warning: 続行する前に、クラスタ設定ファイルを確認してく� さい。
- 最上位の [cluster] セクションで、mysql-master-replica および redis-master-replica の値が、フェイルオーバー後に MySQL と Redis のプライマリとして機能するセカンダリデータセンターのパッシブノードの正しいホスト名であることを確認します。
- [cluster "<em>ACTIVE NODE HOSTNAME</em>"] という名前のアクティブノードの各セクションで、次のキー/値ペアを再確認します。
  - datacenter は、最上位の[ [cluster] セクションの primary-datacenter の値と一致する必要があります。
  - 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
```
In the top-level [cluster] section, delete the redis-master-replica, and mysql-master-replica key-value pairs.
パッシブノードの各セクションを削除します。パッシブノードの� �合、replica は enabled として設定されます。
新しい設定を適用してく� さい。このコマンドは完了するまで時間がかかるので、screenやtmuxのようなターミナルマルチプレクサ内で実行することをおすすめします。
```
ghe-cluster-config-apply
```
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
```
Finished cluster configuration
```

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