このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-12-19. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの 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

プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。

  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

プライマリ データベース ノードを置き換える場合は、「プライマリ データベース ノードを置き換える」を参照してください。

緊急時にノードを交換するには、新しい VM に GitHub Enterprise Server アプライアンスをインストールし、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 ノードでもある場合は、プライマリ データベース ノードの置き換えに関する記事を参照してください。

    たとえば、この変更された 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 と MSSQL)

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

クラスターで GitHub Actions が有効な場合は、以下の手順で MSSQL も考慮する必要があります。

プライマリ MySQL (または MySQL と MSSQL) ノードにさらにリソースを割り当てる必要がある場合、または障害が発生したノードを置き換える必要がある場合は、クラスターに新しいノードを追加できます。 ダウンタイムを最小限に抑えるには、新しいノードを追加し、MySQL (または MySQL と MSSQL) データをレプリケートしてから、それをプライマリ ノードに昇格させます。 昇格プロセス中には、ある程度のダウンタイムが必ず発生します。

  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 キーと値のペアを必ず含めます。
    • クラスターで 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
  ...
...

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

  7. cluster.conf を変更したノードの管理シェルから、ghe-cluster-config-apply を実行します。 新しく追加されたノードはレプリカ MySQL ノードになり、他の構成済みサービスはそこで実行されます。

    Note

    前のスニペットは、クラスター内で GitHub Actions が有効になっていることを前提としていません。

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

    クラスター内で GitHub Actions が有効な場合は、MSSQL レプリケーションが完了するまで待つ必要があります。

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

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

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

    Warning

    MySQL (または MySQL と MSSQL) のレプリケーションが完了するまで待たないと、インスタンス上のデータが失われる恐れがあります。

  11. 現在の MySQL プライマリ ノードを読み取り専用モードに設定するには、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'
    • グローバル MySQL 変数が正常に設定されたことをチェックするには、次のコマンドを実行します。
    Shell
     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql

  13. クラスター内で GitHub Actions が有効な場合は、新しいプライマリ MSSQL ノードとなるノードに SSH で接続します。

    Shell
    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    • screen セッション内から次のコマンドを実行して、MSSQL を新しいノードに昇格させます。
    Shell
    /usr/local/share/enterprise/ghe-mssql-repl-promote

    これにより、現在のプライマリ MSSQL ノードへのアクセスが試行され、正常なフェールオーバーが実行されます

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

  15. cluster.conf を変更したノードの管理シェルで、screen セッションを開始し、ghe-cluster-config-apply を実行します。 このコマンドを実行すると、クラスターを再構成し、新しく追加されたノードをプライマリ MySQL ノードに昇格させ、元のプライマリ MySQL ノードをレプリカに変換することができます。

    Note

    前のスニペットは、クラスター内で GitHub Actions が有効になっていることを前提としていません。

  16. ghe-cluster-status -v を実行して、クラスター内の任意のノードから MySQL (または MySQL と MSSQL) のレプリケーションの状態をチェックします。

  17. クラスター内で GitHub Actions が有効な場合は、新しい MySQL および MSSQL ノードから次のコマンドを実行します。

    Shell
    /usr/local/share/enterprise/ghe-repl-post-failover-mssql

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