クラスタノードの入れ替え

GitHub Enterprise Server クラスターでノードが失敗した場合、またはリソースが多い新しいノードを追加する場合は、置き換えるノードをオフラインとしてマークしてから、新しいノードを追加します。

この機能を使用できるユーザーについて

GitHub はクラスタリングの適格性を決定し、インスタンスのライセンスの構成を有効にする必要があります。 クラスタリングには、慎重な計画と追加の管理オーバーヘッドが必要です。 詳しくは、「クラスタリングについて」を参照してください。

この記事の内容

GitHub Enterprise Server クラスター ノードの置換について

GitHub Enterprise Server クラスター内の機能ノードを置き換えたり、予期せず失敗したノードを置き換えたりすることもできます。

ノードを置き換えた後、お使いの GitHub Enterprise Server インスタンス は新しいノードにジョブを自動的に分散しません。 ノード間でジョブのバランスを取るためにインスタンスを強制できます。 詳しくは、「クラスター ワークロードの再調整」を参照してください。

警告: 競合を回避するには、クラスター内のノードに以前割り当てられていたホスト名を再利用しないでください。

関数ノードの入れ替え

クラスター内の既存の関数ノードを置き換えることができます。 たとえば、追加の CPU、メモリ、またはストレージ リソースを仮想マシン (VM) に提供できます。

関数ノードを置き換えるには、新しい VM に GitHub Enterprise Server アプライアンスをインストールし、IP アドレスを構成し、クラスター構成ファイルに新しいノードを追加し、クラスターを初期化して構成を適用してから、置き換えたノードをオフラインにします。

注： プライマリ MySQL ノードを置き換える場合は、「プライマリ MySQL ノードの置き換え」を参照してください。

  1. 置き換えノードに一意のホスト名を指定し、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
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
    1. 変更された `cluster.conf` があるノードの管理シェルから、`ghe-cluster-config-init` を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。1. 同じノードから、`ghe-cluster-config-apply` を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更された `cluster.conf` ファイルに従って各ノードが設定されます。

  2. 置き換えるノードをオフラインにするには、クラスターのプライマリ MySQL ノードから次のコマンドを実行します。

    ghe-remove-node NODE-HOSTNAME

    このコマンドは、ノードで実行されているデータ サービスからデータを除外し、ノードを構成でオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。

緊急時のノードの入れ替え

クラスター内の障害が発生したノードを置き換えることができます。 たとえば、ソフトウェアまたはハードウェアの問題がノードの可用性に影響を与える可能性があります。

注： プライマリ MySQL ノードを置き換える場合は、「プライマリ MySQL ノードの置き換え」を参照してください。

緊急時にノードを置き換えるには、障害が発生したノードをオフラインにし、交換ノードをクラスターに追加してから、コマンドを実行して、削除されたノード上のデータ サービスへの参照を削除します。

  1. クラスターから問題が発生しているノードを削除するには、クラスターのプライマリ MySQL ノードから、次のコマンドを実行します。 NODE-HOSTNAME を、オフラインにするノードのホスト名に置き換えます。

    ghe-remove-node --no-evacuate NODE-HOSTNAME

    このコマンドは、構成でノードをオフラインとしてマークし、ノードへのトラフィックのルーティングを停止します。 このコマンドを no-evacuate モードで実行できるようになりました。これは、この手順の後半で、クラスター内の他の使用可能なノードにレプリカをコピーするようにノード上のデータ サービスに指示するコマンドを実行するためです。 詳しくは、「コマンド ライン ユーティリティ」を参照してください。

  2. 代替ノードをクラスターに追加します。

    1. 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。

  3. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。

    1. 任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、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

    2. 変更された cluster.conf があるノードの管理シェルから、ghe-cluster-config-init を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。

  4. 同じノードから、ghe-cluster-config-apply を実行します。 これにより、構成ファイルが検証され、クラスター内の各ノードにコピーされ、変更された cluster.conf ファイルに従って各ノードが設定されます。

  5. 削除したノード上のデータ サービスへの参照を削除します。

    1. 削除したノードの UUID を見つけます。 UUID を見つけるには、次のコマンドを実行し、HOSTNAME をノードのホスト名に置き換えます。 この UUID は次のステップで使用します。

      ghe-config cluster.HOSTNAME.uuid

    2. データ サービスへの参照を削除するには、次のコマンドを実行します。 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

  6. 必要に応じて、 cluster.conf ファイル内の削除されたノードのエントリを削除します。 そうすることで、cluster.conf ファイルが整理された状態に保たれ、今後の config-apply の実行時の時間を節約できます。

    1. ファイルからエントリを削除するには、次のコマンドを実行し、HOSTNAME が削除されたノードのホスト名に置き換えます。

      ghe-config --remove-section "cluster.HOSTNAME"

    2. 構成をクラスター内の他のノードにコピーするには、cluster.conf を変更したノードの管理シェルから ghe-cluster-config-apply を実行します。

プライマリ MySQL ノードの置き換え

データベース サービスを提供するには、クラスターにプライマリ MySQL ノードと少なくとも 1 つのセカンダリ MySQL ノードが必要です。 詳しくは、「クラスタノードについて」を参照してください。

プライマリ MySQL ノードの VM に追加のリソースを提供する場合、またはノードが失敗した場合は、ノードを置き換えることができます。 ダウンタイムを最小限に抑えるには、新しいノードをクラスターに追加し、MySQL データをレプリケートしてから、ノードを昇格します。 昇格中はダウンタイムが必要です。

  1. 置き換えノードに一意のホスト名を指定し、GitHub Enterprise Server をプロビジョニングしてインストールします。

  2. 管理シェルまたは DHCP を使用して、置換ノードの IP アドレスのみを構成します。 その他の設定は行わないでください。

  3. お使いの GitHub Enterprise Server インスタンス に接続するには、クラスターのいずれかのノードに SSH 接続します。 ワークステーションから、次のコマンドを実行します。 HOSTNAME は、ノードのホスト名に置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME

  4. テキスト エディターで、/data/user/common/cluster.conf のクラスター構成ファイルを開きます。 たとえばVimを利用できます。 ファイルを編集する前に、 cluster.conf ファイルのバックアップを作成します。

    Shell
    sudo vim /data/user/common/cluster.conf

  5. クラスター構成ファイルでは、[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
  ...
...

  6. 変更された cluster.conf があるノードの管理シェルから、ghe-cluster-config-init を実行します。 これで、クラスタに新たに追加されたノードが初期化されます。

  7. cluster.conf を変更したノードの管理シェルから、ghe-cluster-config-apply を実行します。 これで設定ファイルが検証され、クラスタ内の各ノードにコピーされ、そのノードがオフラインとしてマークされます。

  8. MySQL レプリケーションが完了するまで待ちます。 クラスター内の任意のノードからの MySQL レプリケーションを監視するには、ghe-cluster-status -v を実行します。

    クラスターにノードを追加した直後、レプリケーションが追いつくまでレプリケーション ステータスのエラーが表示される場合があります。 インスタンスの負荷と、インスタンスが最後にデータベース シードを生成した時間によっては、レプリケーションに数時間かかる場合があります。

  9. 予定メンテナンス ウィンドウで、メンテナンス モードを有効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  10. ghe-cluster-status -v を実行して、クラスター内の任意のノードから MySQL レプリケーションが完了していることを確認します。

    警告: MySQL レプリケーションが完了するまで待たないと、インスタンスでデータが失われるリスクがあります。

  11. 現在の MySQL プライマリ ノードを読み取り専用モードに設定するには、インスタンスのノードから次のコマンドを実行します。

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql

  12. プライマリ MySQL ノードとセカンダリ MySQL ノードで設定されたグローバル トランザクション識別子 (GTID) が同じになるまで待ちます。 GTID をチェックするには、インスタンスのいずれかのノードから次のコマンドを実行します。

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

  13. プライマリ 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
...

  14. cluster.conf を変更したノードの管理シェルから、ghe-cluster-config-apply を実行します。 これで設定ファイルが検証され、クラスタ内の各ノードにコピーされ、そのノードがオフラインとしてマークされます。

  15. ghe-cluster-status -v を実行して、クラスター内の任意のノードからの MySQL レプリケーションの状態を確認します。

  16. MySQL レプリケーションが完了した場合は、クラスター内の任意のノードから、メインテナント モードを無効にします。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。