GitHub Enterprise Server クラスター ノードの置換について
GitHub Enterprise Server クラスター内の機能ノードを置き換えたり、予期せず失敗したノードを置き換えたりすることもできます。
ノードを置き換えた後、お使いの GitHub Enterprise Server インスタンス は新しいノードにジョブを自動的に分散しません。 ノード間でジョブのバランスを取るためにインスタンスを強制できます。 詳しくは、「クラスター ワークロードの再調整」を参照してください。
警告: 競合を回避するには、クラスター内のノードに以前割り当てられていたホスト名を再利用しないでください。
関数ノードの入れ替え
クラスター内の既存の関数ノードを置き換えることができます。 たとえば、追加の CPU、メモリ、またはストレージ リソースを仮想マシン (VM) に提供できます。
関数ノードを置き換えるには、新しい VM に GitHub Enterprise Server アプライアンスをインストールし、IP アドレスを構成し、クラスター構成ファイルに新しいノードを追加し、クラスターを初期化して構成を適用してから、置き換えたノードをオフラインにします。
注: プライマリ MySQL ノードを置き換える場合は、「プライマリ MySQL ノードの置き換え」を参照してください。
-
置き換えノードに一意のホスト名を指定し、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
ファイルに従って各ノードが設定されます。 -
置き換えるノードをオフラインにするには、クラスターのプライマリ MySQL ノードから次のコマンドを実行します。
ghe-remove-node NODE-HOSTNAME
このコマンドは、ノードで実行されているデータ サービスからデータを除外し、ノードを構成でオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。
緊急時のノードの入れ替え
クラスター内の障害が発生したノードを置き換えることができます。 たとえば、ソフトウェアまたはハードウェアの問題がノードの可用性に影響を与える可能性があります。
注: プライマリ MySQL ノードを置き換える場合は、「プライマリ MySQL ノードの置き換え」を参照してください。
緊急時にノードを置き換えるには、障害が発生したノードをオフラインにし、交換ノードをクラスターに追加してから、コマンドを実行して、削除されたノード上のデータ サービスへの参照を削除します。
-
クラスターから問題が発生しているノードを削除するには、クラスターのプライマリ MySQL ノードから、次のコマンドを実行します。 NODE-HOSTNAME を、オフラインにするノードのホスト名に置き換えます。
ghe-remove-node --no-evacuate NODE-HOSTNAME
このコマンドは、構成でノードをオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 このコマンドを
no-evacuate
モードで実行できるようになりました。これは、この手順の後半で、クラスター内の他の使用可能なノードにレプリカをコピーするようにノード上のデータ サービスに指示するコマンドを実行するためです。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。 -
代替ノードをクラスターに追加します。
- 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。
-
管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。
-
任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、
cluster.conf
ファイルを変更して置換ノードを追加します。 たとえば、次の変更されたcluster.conf
ファイルは、新しくプロビジョニングされたノード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 git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
-
変更された
cluster.conf
があるノードの管理シェルから、ghe-cluster-config-init
を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。
-
-
同じノードから、
ghe-cluster-config-apply
を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更されたcluster.conf
ファイルに従って各ノードが設定されます。 -
削除したノード上のデータ サービスへの参照を削除します。
-
削除したノードの UUID を見つけます。 UUID を見つけるには、次のコマンドを実行し、
HOSTNAME
をノードのホスト名に置き換えます。 この UUID は次のステップで使用します。ghe-config cluster.HOSTNAME.uuid
-
データ サービスへの参照を削除するには、次のコマンドを実行します。
UUID
をノードの UUID に置き換えます。これらのコマンドは、ノードが完全に削除されることを各サービスに示します。 サービスは、クラスター内の使用可能なノード上のノード内に含まれるすべてのレプリカを再作成します。
注: これらのコマンドは、レプリカ間でデータのバランスを取り戻す間、サーバーの負荷を増加させる可能性があります。
git-server
サービスの場合 (リポジトリ データに使用):ghe-spokesctl server destroy git-server-UUID
pages-server
サービスの場合 (GitHub Pages サイト ビルドに使用):ghe-dpages remove pages-server-UUID
storage-server
サービス (Git LFS データ、アバター 画像、添付ファイル、リリース アーカイブに使用):ghe-storage destroy-host storage-server-UUID --force
-
-
必要に応じて、
cluster.conf
ファイル内の削除されたノードのエントリを削除します。 そうすることで、cluster.conf
ファイルが整理された状態に保たれ、今後のconfig-apply
の実行時の時間を節約できます。-
ファイルからエントリを削除するには、次のコマンドを実行し、
HOSTNAME
が削除されたノードのホスト名に置き換えます。ghe-config --remove-section "cluster.HOSTNAME"
-
構成をクラスター内の他のノードにコピーするには、
cluster.conf
を変更したノードの管理シェルからghe-cluster-config-apply
を実行します。
-
プライマリ MySQL ノードの置き換え
データベース サービスを提供するには、クラスターにプライマリ MySQL ノードと少なくとも 1 つのレプリカ MySQL ノードが必要です。 詳しくは、「クラスタノードについて」を参照してください。
プライマリ MySQL ノードの VM に追加のリソースを提供する場合、またはノードが失敗した場合は、ノードを置き換えることができます。 ダウンタイムを最小限に抑えるには、新しいノードをクラスターに追加し、MySQL データをレプリケートしてから、ノードを昇格します。 昇格中はダウンタイムが必要です。
-
置き換えノードに一意のホスト名を指定し、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
キーと値のペアを必ず含めます。- 次のセクションは例であり、ノードの構成は異なる場合があります。
... [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 ノードになり、他の構成済みサービスはそこで実行されます。 -
MySQL レプリケーションが完了するまで待ちます。 クラスター内の任意のノードからの MySQL レプリケーションを監視するには、
ghe-cluster-status -v
を実行します。クラスターにノードを追加した直後、レプリケーションが追いつくまでレプリケーション ステータスのエラーが表示される場合があります。 インスタンスの負荷、データベースデータ量と、インスタンスが最後にデータベース シードを生成した時間によっては、レプリケーションに数時間かかる場合があります。
-
予定メンテナンス ウィンドウで、メンテナンス モードを有効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
-
ghe-cluster-status -v
を実行して、クラスター内の任意のノードから MySQL レプリケーションが完了していることを確認します。警告: 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 ノードとレプリカ MySQL ノードの GTID が一致したら、テキスト エディターの
/data/user/common/cluster.conf
でクラスター構成ファイルを開いてクラスター構成を更新します。- ファイルを編集する前に、
cluster.conf
ファイルのバックアップを作成します。 - トップレベルの
[cluster]
セクション で、置き換えたノードのホスト名をmysql-master
キーと値のペアから削除し、代わりに新しいノードを割り当てます。 新しいノードがプライマリ Redis ノードでもある場合は、redis-master
キーと値のペアを調整します。
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- ファイルを編集する前に、
-
cluster.conf
を変更したノードの管理シェルから、ghe-cluster-config-apply
を実行します。 これにより、新しく追加されたノードがプライマリ MySQL ノードになり、元のプライマリ MySQL ノードがレプリカ MySQL ノードになるようにクラスターが再構成されます。 1.ghe-cluster-status -v
を実行して、クラスター内の任意のノードからの MySQL レプリケーションの状態を確認します。 -
MySQL レプリケーションが完了した場合は、クラスター内の任意のノードから、メインテナント モードを無効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。