このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

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

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

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

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

この記事の内容

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

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

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

Warning

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

関数ノードの入れ替え

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

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

Note

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

プライマリ MySQL ノードを置き換える場合は、「プライマリ MySQL ノードの置き換え」をご覧ください。

緊急時にノードを置き換えるには、GitHub Enterprise Server アプライアンスを新しい VM にインストールし、IP アドレスを構成し、障害が発生したノードをオフラインにして、構成を適用し、クラスター構成ファイルに新しいノードを追加し、クラスターを初期化して構成を適用し、必要に応じて、障害が発生したノードを退避します。

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

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

  3. 障害が発生したノードをオフラインとしてマークするには、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

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

  5. 任意のノードに対して、新たにプロビジョニングされた置換ノードを追加するには、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 レプリカ ノードのデータベース シード処理の延期ができます。その結果、アプライアンスをトラフィックに対してより早く開くことができます。 詳しくは、「データベース シード処理の遅延」を参照してください。

  6. プライマリ Redis ノードを置き換える場合は、cluster.conf で、redis-master の値を置換ノード名に変更します。

    Note

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

    たとえば、この変更された cluster.conf ファイルは、プライマリ Redis ノードとして、新しくプロビジョニングされたクラスター ノード ghe-replacement-data-node-1 を指定します。

    redis-master = ghe-replacement-data-node-1

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

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

  9. git-server、pages-server、storage-server などのデータ サービスを提供するノードをオフラインにしている場合は、ノードを退避します。 詳しくは、「データ サービスを実行しているクラスター ノードの退避」を参照してください。

プライマリ 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 を実行します。 新しく追加されたノードはレプリカ MySQL ノードになり、他の構成済みサービスはそこで実行されます。

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

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

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

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

    Warning

    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を実行します。 これにより、新しく追加されたノードがプライマリ MySQL ノードになり、元のプライマリ MySQL ノードがレプリカ MySQL ノードになるようにクラスターが再構成されます。 1.ghe-cluster-status -vを実行して、クラスター内の任意のノードからの MySQL レプリケーションの状態を確認します。

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