高可用性構成へのノードの追加

プライマリ 高可用性 (HA) データセンターにノードを追加します。 これは、プライマリ ノードから CPU 負荷の高いタスクをオフロードすることを目的としており、GitHub Enterprise Server インスタンスの水平方向のスケーリングが可能になります。

この記事で

メモ

HA にコンピューティング ノードを追加する機能はパブリック プレビュー にあり、変更される可能性があります。 プレビュー期間中は、カスタマー サクセス チームにフィードバックをお寄せください。

GitHub Enterprise Server を利用しているお客様で水平方向へのスケーリングを検討している場合、クラスターへの移行と運用は選択肢の一つですが、リソースを多く消費し、時間もかかります。 別の方法として、HA 構成にノードを追加することをお勧めします。

"追加ノード" と "ステートレス ノード" という用語は、この記事全体で同じ意味で使用されます。 ステートレス ノードは、少なくとも 1 つのレプリカを含む HA デプロイにのみ追加できます。

その他のノード

GitHub Enterprise Server アプライアンスで実行できるすべてのサービスの中で、Unicorn は最も CPU とメモリを消費する傾向があり、Aqueduct、Git、MySQL が続きます。 Unicorn と Aqueduct はステートレス サービスであるため、水平スケーリングに適しており、個別のノードセットで実行できます。 残りのサービスは、データセンターごとに 1 つのインスタンスで動作し続けることができます。

追加のノードを使用すると、Web ワークロードとジョブ ワークロードを水平方向にスケーリングできます。 プライマリノードから、Unicorn と Aqueduct をオフロードして、残りのステートフルサービスに対する多くのコンピューティング リソースとメモリ リソースを解放することもできます。 ユニコーン インスタンスによる CPU 使用率の高さからパフォーマンスに関連した障害が発生している場合は、ノードを追加することをお勧めします。 データセンター内で追加できるこれらのノードの数に大きな制限はありません。

条件

HA 構成でプライマリ ノードの過負荷が原因でパフォーマンスが低下している場合は、HA 環境にノードを追加することを検討する必要があります。 プライマリ ノードを超えて Web ロールとジョブ ロールを水平方向にスケーリングすることで、これらの追加ノードはプライマリ ホストの負荷を軽減するのに役立ちます。

たとえば、UnicornまたはAqueductキューでバックログに気付いた場合や、他の種類のリソース競合が発生している場合は、この方法を検討する必要があります。 目に見えるキューがない場合でも、プライマリ ノードで CPU が不足することは、もう 1 つの明確なシグナルです。 このような場合は、ノードを追加し、ノードあたりのワーカー数を減らすことができます。そのため、プライマリ ノードは全体的なワークロードの処理量を減らすことができます。

ノードの追加

HA デプロイに追加する各ノードは、GitHub Enterprise Server ソフトウェアを実行する仮想マシン (VM) です。 プライマリと同じソフトウェアを実行している必要があります。 一般に、ステートレス ノードは、プライマリのメモリ、CPU、またはストレージの仕様と一致する必要はありません。 ただし、ステートレス ノードとプライマリ インスタンスの両方にミリ秒未満の接続が必要です。 レプリカの接続要件は変更されません。

HA 構成のプライマリ データセンターにノードを追加するには、 ghe-add-node コマンドを使用します。 ghe-add-node コマンドは、HA デプロイ内のノードとして現在のアプライアンスを設定し、プライマリ データ ノードから CPU 負荷の高いタスクをオフロードし、水平スケーリングを可能にすることを目的としています。 これらのノードは、Web ワークロードとジョブ ワークロードを処理するように設計されているため、ワークロードの分散と管理をより効率的に行うことができます。 このコマンドは次の形式になります。

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

  •         `PRIMARY_IP`: プライマリ ノードの IP アドレス。

  •         `HOSTNAME` (省略可能): 追加されたホストに必要なホスト名。

たとえば、ホスト名が ghes-node-1 されたノードを HA プライマリ データセンターの IP アドレス 192.168.1.1 HA プライマリ インスタンスに追加するには、次のコマンドを実行します。

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

次に、プライマリ ノードで、次のコマンドを実行する必要があります。

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

          `ghe-config-apply` コマンドは、ステートレス ノードを追加するための要件です。

パブリック プレビューでは、ダウンタイムについて特にテストしていません。メンテナンス期間が必要かどうかは明確ではありません。

追加ノードの削除

ノードを削除するには、削除するノードから ghe-remove-node を実行します。 次に、プライマリ ノードで次を実行する必要があります。

Shell
ghe-config-apply

          `ghe-config-apply` コマンドは、ステートレス ノードを削除する必要があります。

パブリック プレビューでは、ダウンタイムについて特にテストしていません。メンテナンス期間が必要かどうかは明確ではありません。

以前に GitHub Enterprise Server をホストしていたノードの再プロビジョニング

以前に GitHub Enterprise Server をホストして実行したノードを、ステートレスノードとして利用できます。 そのためには、ノードをバージョン 3.18 以降に更新し、デプロイ内のすべてのノードで同じバージョンが実行されている必要があります。 そのノードで、 /data/user/common/cluster.conf が既に存在するかどうかを確認します。 その場合は、ステートレス ノードで ghe-add-node コマンドを実行する前にクリーンアップを実行する必要があります。

例えば次が挙げられます。

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

制限と動作

追加できるノードの数に理論的な制限はありません。 ただし、実際には、ノードを追加しすぎると、問題が発生し、安定性やパフォーマンスに影響を与える可能性があります。 現時点では、新しく追加されたノードは、定義済みの一連のタスクを処理します。 オフロードするタスクの種類を選択することはできません。 すべての API は、追加ノードによって処理できます。

Git 操作がパス内にある場合は、プライマリ ノードでのみ Git 操作を処理するロジックが存在します。 Git 操作は、追加のノードでは処理されません。 たとえば、ブランチの削除は Git 操作であり、ステートレス ノードでは処理されません。

ステートレス ノードは Elasticsearch ワークロードを実行しませんが、kafka-lite を実行します。

システムとネットワークの要件

一般に、ステートレス ノードは、プライマリ ノードのメモリ、CPU、ストレージの仕様と一致する必要はありません。 システム要件では、プライマリ ノード上の Web サービスとジョブ サービスの既存のリソース消費量と、プライマリ ノードがそれらのワークロードを新しいノードに完全にオフロードするかどうかを考慮する必要があります。

ステートレス ノードとプライマリ インスタンスには、ミリ秒未満の接続が必要です。 一般に、プライマリ データセンター内のすべてのノードにはミリ秒未満の接続が必要です。 レプリカの接続要件は変更されません。

トラフィック ルーティングと要求の処理

プライマリは、トラフィックを追加のノードにルーティングします。 複数のステートレス ノードが存在する場合、プライマリは、その時点でアクティブな接続が最も少ない新しい接続をサーバーに送信します。

追加ノードを使用した HA デプロイのアップグレード

アップグレード シーケンスの例を次に示します。

  • メンテナンス期間を開始します。
  • レプリカを停止します。
  • ステートレス ノードを並列でアップグレードします。
  • プライマリ ノードをアップグレードします。
  • レプリカをアップグレードします。 これらは、ディザスター リカバリーの設定に応じて、並列または順番にアップグレードできます。
  • レプリカを起動します。
  • メンテナンスウィンドウを削除します。

追加のノードでは、アップグレード中に追加のダウンタイムが発生しないようにする必要があります。

フェールオーバーとディザスター リカバリーの動作

データが含まれていないため、追加のノードを "破棄" する必要はありません。

フェールオーバー中、レプリカ ノードは元のデプロイから削除され、スタンドアロン ノードに変換されます。 ステートレスノードは、フェールオーバー後に追加のレプリカを再アタッチする方法と同様に、プロモートされたレプリカに再アタッチする必要があります。

プライマリ ノードが機能していて、レプリカをプライマリに昇格させる場合は、昇格されたノードに再度追加する前に、 ghe-remove-node コマンドを使用してプライマリからステートレス ノードを削除する必要があります。

プライマリ ノードに到達できず、回復できない場合は、元のプライマリからノードを削除せずにステートレス ノードを再追加できます。

監視、ログ、およびサポート バンドル

プライマリ ノードの管理コンソール監視ダッシュボードには、ステートレス ノードを含むすべてのノードのメトリックが表示されます。 ghe-cluster-nodesやghe-cluster-statusなどのコマンドには、ステートレス ノードの詳細が含まれています。 すべての管理コンソール要求は、プライマリ ノードによって処理されます。

ログは、ステートレス ノードにローカルに格納されます。 これらのノードからサードパーティのログ管理サービスにエクスポートできます。

          `ghe-cluster-support-bundle`コマンドと`ghe-support-bundle` コマンドを使用して、クラスターバンドルまたは単一ノードバンドルを生成およびアップロードできます。

既知の制限

この機能は monorepos 向けに設計されていませんが、新しいステートレス ノードを追加すると、プライマリ ノード上の Web ワークロードとジョブ ワークロードを減らすことで、モノレポ操作が間接的に向上する可能性があります。 自動スケール機能とスケールダウン機能はありません。