GitHub Enterprise Server クラスター ノードの交換について
GitHub Enterprise Server クラスター内の問題なく動いているノードを交換することもでき、突然問題が発生したノードを交換することもできます。
ノードの交換後、お使いの GitHub Enterprise Server インスタンス によってジョブが新しいノードに自動的に配布されることはありません。 ノード間でジョブのバランスを取るためにインスタンスを強制できます。 詳しくは、「クラスター ワークロードの再調整」をご覧ください。
Warning
競合を避けるため、クラスターのノードに以前に割り当てられていたホスト名を再利用しないでください。
関数ノードの入れ替え
クラスター内の既存の関数ノードを置き換えることができます。 たとえば、追加の CPU、メモリ、またはストレージ リソースを仮想マシン (VM) に提供できます。
問題なく動いているノードを交換するには、新しい VM に GitHub Enterprise Server アプライアンスをインストールし、IP アドレスを構成し、新しいノードをクラスター構成ファイルに追加し、クラスターを初期化して構成を適用し、(新しいノードに取って代わられる) 古いノードをオフラインにします。
Note
プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。
-
置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。1. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。1. 任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、
cluster.conf
ファイルを修正し、障害が起きたノードを取り除き、置換ノードを追加します。 たとえば、このように変更したcluster.conf
ファイルでは、ghe-data-node-3
を新しくプロビジョニングされたghe-replacement-data-node-3
ノードで置換します。[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 consul-datacenter = PRIMARY-DATACENTER git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
新しい MySQL レプリカ ノードのデータベース シード処理の延期ができます。その結果、アプライアンスをトラフィックに対してより早く開くことができます。 詳しくは、「データベース シード処理の遅延」をご覧ください。1. 変更された
cluster.conf
があるノードの管理シェルから、ghe-cluster-config-init
を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。1. 同じノードから、ghe-cluster-config-apply
を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更されたcluster.conf
ファイルに従って各ノードが設定されます。1.git-server
、pages-server
、storage-server
などのデータ サービスを提供するノードをオフラインにしている場合は、ノードを退避します。 詳しくは、「データ サービスを実行しているクラスター ノードの退避」をご覧ください。1. 障害が発生したノードをオフラインとしてマークするには、offline = true
というテキストを含むようにクラスター構成ファイル (cluster.conf
) の関連するノードのセクションを変更します。たとえば、このように変更した
cluster.conf
では、ghe-data-node-3
ノードをオフラインとしてマークします。[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
1. `cluster.conf` を変更したノードの管理シェルから、`ghe-cluster-config-apply` を実行します。 これで設定ファイルが検証され、クラスタ内の各ノードにコピーされ、そのノードがオフラインとしてマークされます。
緊急時のノードの入れ替え
クラスター内の障害が発生したノードを置き換えることができます。 たとえば、ソフトウェアまたはハードウェアの問題がノードの可用性に影響を与える可能性があります。
Note
プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。
緊急時にノードを交換するには、新しい VM に GitHub Enterprise Server アプライアンスをインストールし、IP アドレスを構成し、故障したノードをオフラインにし、構成を適用し、新しいノードをクラスター構成ファイルに追加し、クラスターを初期化して構成を適用し、任意で故障したノードを削除します。
-
置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。
-
管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。
-
障害が発生したノードをオフラインとしてマークするには、
offline = true
というテキストを含むようにクラスター構成ファイル (cluster.conf
) の関連するノードのセクションを変更します。たとえば、このように変更した
cluster.conf
では、ghe-data-node-3
ノードをオフラインとしてマークします。[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
-
cluster.conf
を変更したノードの管理シェルから、ghe-cluster-config-apply
を実行します。 これで設定ファイルが検証され、クラスタ内の各ノードにコピーされ、そのノードがオフラインとしてマークされます。 -
任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、
cluster.conf
ファイルを修正し、障害が起きたノードを取り除き、置換ノードを追加します。 たとえば、このように変更したcluster.conf
ファイルでは、ghe-data-node-3
を新しくプロビジョニングされたghe-replacement-data-node-3
ノードで置換します。[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 consul-datacenter = PRIMARY-DATACENTER git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
新しい MySQL レプリカ ノードのデータベース シード処理の延期ができます。その結果、アプライアンスをトラフィックに対してより早く開くことができます。 詳しくは、「データベース シード処理の遅延」をご覧ください。
-
プライマリ Redis ノードを置き換える場合は、
cluster.conf
で、redis-master
の値を置換ノード名に変更します。Note
プライマリ Redis ノードがプライマリ MySQL ノードでもある場合は、プライマリ データベース ノードの置き換えに関する記事を参照してください。
たとえば、この変更された
cluster.conf
ファイルは、プライマリ Redis ノードとして、新しくプロビジョニングされたクラスター ノードghe-replacement-data-node-1
を指定します。redis-master = ghe-replacement-data-node-1
-
変更された
cluster.conf
があるノードの管理シェルから、ghe-cluster-config-init
を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。 -
同じノードから、
ghe-cluster-config-apply
を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更されたcluster.conf
ファイルに従って各ノードが設定されます。 -
git-server
、pages-server
、storage-server
などのデータ サービスを提供するノードをオフラインにしている場合は、ノードを退避します。 詳しくは、「データ サービスを実行しているクラスター ノードの退避」をご覧ください。
プライマリ データベース ノードを置き換える (MySQL または MySQL と MSSQL)
データベース サービスを提供するには、クラスターにプライマリ MySQL ノードと少なくとも 1 つのレプリカ MySQL ノードが必要です。 詳しくは、「クラスタノードについて」をご覧ください。
クラスターで GitHub Actions が有効な場合は、以下の手順で MSSQL も考慮する必要があります。
プライマリ MySQL (または MySQL と MSSQL) ノードにさらにリソースを割り当てる必要がある場合、または障害が発生したノードを置き換える必要がある場合は、クラスターに新しいノードを追加できます。 ダウンタイムを最小限に抑えるには、新しいノードを追加し、MySQL (または MySQL と MSSQL) データをレプリケートしてから、それをプライマリ ノードに昇格させます。 昇格プロセス中には、ある程度のダウンタイムが必ず発生します。
-
置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。
-
管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。
-
お使いの GitHub Enterprise Server インスタンス に接続するには、クラスターのいずれかのノードに SSH 接続します。 ワークステーションから、次のコマンドを実行します。 HOSTNAME は、ノードのホスト名に置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」をご覧ください。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
テキスト エディターで、
/data/user/common/cluster.conf
のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、cluster.conf
ファイルのバックアップを作成します。Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
クラスター構成ファイルでは、
[cluster "HOSTNAME"]
見出しの下に各ノードが示されます。 ノードの新しい見出しを追加し、構成のキーと値のペアを入力します。プレースホルダーは実際の値に置き換えます。mysql-server = true
キーと値のペアを必ず含めます。- クラスターで GitHub Actions が有効な場合は、
mssql-server = true
キーと値のペアも含める必要があります。 - 次のセクションは例であり、ノードの構成は異なる場合があります。
... [cluster "HOSTNAME"] hostname = HOSTNAME ipv4 = IPV4-ADDRESS # ipv6 = IPV6-ADDRESS consul-datacenter = PRIMARY-DATACENTER datacenter = DATACENTER mysql-server = true redis-server = true ... ...
-
変更された
cluster.conf
があるノードの管理シェルから、ghe-cluster-config-init
を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。 -
cluster.conf
を変更したノードの管理シェルから、ghe-cluster-config-apply
を実行します。 新しく追加されたノードはレプリカ MySQL ノードになり、他の構成済みサービスはそこで実行されます。Note
前のスニペットは、クラスター内で GitHub Actions が有効になっていることを前提としていません。
-
MySQL レプリケーションが完了するまで待ちます。 クラスター内の任意のノードからの MySQL レプリケーションを監視するには、
ghe-cluster-status -v
を実行します。クラスター内で GitHub Actions が有効な場合は、MSSQL レプリケーションが完了するまで待つ必要があります。
クラスターにノードを追加した直後、レプリケーションが追いつくまでレプリケーション ステータスのエラーが表示される場合があります。 インスタンスの負荷、データベースデータ量と、インスタンスが最後にデータベース シードを生成した時間によっては、レプリケーションに数時間かかる場合があります。
-
予定メンテナンス ウィンドウで、メンテナンス モードを有効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。
-
ghe-cluster-status -v
を実行して、クラスター内の任意のノードから MySQL (または MySQL と MSSQL) のレプリケーションが完了していることを確認します。Warning
MySQL (または MySQL と MSSQL) のレプリケーションが完了するまで待たないと、インスタンス上のデータが失われる恐れがあります。
-
現在の MySQL プライマリ ノードを読み取り専用モードに設定するには、MySQL プライマリ ノードから次のコマンドを実行します。
Shell echo "SET GLOBAL super_read_only = 1;" | sudo mysql
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
プライマリ MySQL ノードとレプリカ MySQL ノードで設定されたグローバル トランザクション識別子 (GTID) が同じになるまで待ちます。 GTID をチェックするには、いずれかのクラスター ノードから次のコマンドを実行します。
Shell ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
- グローバル MySQL 変数が正常に設定されたことをチェックするには、次のコマンドを実行します。
Shell echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
-
クラスター内で GitHub Actions が有効な場合は、新しいプライマリ MSSQL ノードとなるノードに SSH で接続します。
Shell ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
screen
セッション内から次のコマンドを実行して、MSSQL を新しいノードに昇格させます。
Shell /usr/local/share/enterprise/ghe-mssql-repl-promote
/usr/local/share/enterprise/ghe-mssql-repl-promote
これにより、現在のプライマリ MSSQL ノードへのアクセスが試行され、正常なフェールオーバーが実行されます
-
プライマリ MySQL ノードとレプリカ MySQL ノードの GTID が一致したら、テキスト エディターの
/data/user/common/cluster.conf
でクラスター構成ファイルを開いてクラスター構成を更新します。- ファイルを編集する前に、
cluster.conf
ファイルのバックアップを作成します。 - トップレベルの
[cluster]
セクション で、置き換えたノードのホスト名をmysql-master
キーと値のペアから削除し、代わりに新しいノードを割り当てます。 新しいノードがプライマリ Redis ノードでもある場合は、redis-master
キーと値のペアを調整します。 - クラスターで GitHub Actions が有効な場合は、
mssql-server = true
キーと値のペアも含める必要があります。
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- ファイルを編集する前に、
-
cluster.conf
を変更したノードの管理シェルで、screen
セッションを開始し、ghe-cluster-config-apply
を実行します。 このコマンドを実行すると、クラスターを再構成し、新しく追加されたノードをプライマリ MySQL ノードに昇格させ、元のプライマリ MySQL ノードをレプリカに変換することができます。Note
前のスニペットは、クラスター内で GitHub Actions が有効になっていることを前提としていません。
-
ghe-cluster-status -v
を実行して、クラスター内の任意のノードから MySQL (または MySQL と MSSQL) のレプリケーションの状態をチェックします。 -
クラスター内で GitHub Actions が有効な場合は、新しい MySQL および MSSQL ノードから次のコマンドを実行します。
Shell /usr/local/share/enterprise/ghe-repl-post-failover-mssql
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
-
MySQL (または MySQL と MSSQL) のレプリケーションが完了したら、クラスター内の任意のノードからメンテナンス モードを無効にします。 「メンテナンスモードの有効化とスケジューリング」を参照してください。