クラスタの 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 ミリ秒未満である必要があります。 パッシブクラスタ内のノード間のネットワーク接続の詳細については、「クラスタネットワーク設定」を参照してください。
クラスタの High Availability レプリカを作成する
アクティブノードをプライマリデータセンターに割り当てる
パッシブノードのセカンダリデータセンターを定義する前に、アクティブノードをプライマリデータセンターに割り当てていることを確認してください。
-
クラスタ内のいずれかのノードに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 ... ...
- 上記のステップ 7 で選択したパターンに従って、セクション見出しの引用符で囲まれたホスト名とセクション内の
-
ステップ 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 theredis-master-replica
, andmysql-master-replica
key-value pairs. -
パッシブノードの各セクションを削除します。 パッシブノードの場合、
replica
はenabled
として設定されます。 -
新しい設定を適用してください。 このコマンドは完了するまで時間がかかるので、
screen
やtmux
のようなターミナルマルチプレクサ内で実行することをおすすめします。ghe-cluster-config-apply
-
設定の実行を終了すると、GitHub Enterprise Serverは以下のメッセージを表示します。
Finished cluster configuration
GitHub Enterprise Server がプロンプトに戻ったら、High Availability レプリケーションの無効化が完了したことになります。