クラスタリングの設定

GitHub Enterprise Serverのクラスター トポロジは、他のトポロジでリソース枯渇が発生する数万人のユーザーをサポートするように設計されています。 クラスターでは、インスタンスのサービスは複数のノードにわたって水平にスケーリングされます。

GitHub Enterprise Server インスタンスを構成する仮想マシン (VM) のデプロイ トポロジの違いについて説明します。

GitHub Enterprise Server クラスターのノードとは、インスタンスを構成する GitHub Enterprise Server ソフトウェアを実行する個々の仮想マシン (VM) です。 各ノードは、一連のサービスを実行します。

GitHub Enterprise Server クラスターには、適切なDNSの名前解決、ロードバランシング、およびノード間の通信が必要です。

GitHub Enterprise Server クラスターはライセンスで設定し、管理シェル (SSH) を使用して初期化する必要があります。

データベースのシード処理の延期で、新しい MySQL レプリカ ノードをクラスターに追加するプロセスを高速化できます。

GitHub Enterprise Server クラスターを最新リリースにアップグレードするには、管理シェル (SSH) を使用します。

GitHub Enterprise Server クラスターのパフォーマンスと冗長性を確保するために、クラスターの正常性を監視できます。

GitHub Enterprise Server を使うと、Node Eligibility Service クラスター内のノードが問題を起こすほど長くオフラインになったタイミングを監視できます。

GitHub Enterprise Server クラスターで、クラスターのノード全体にわたってワークロードのジョブの割り当てが均等に分散されるように強制できます。

ノードが提供するサービスを維持しながら、 GitHub Enterprise Server クラスター内の機能しているノードまたは障害が発生したノードを置き換えます。

GitHub Enterprise Server クラスター全体のレプリカを別のデータセンターに構成して、クラスターを冗長ノードにフェールオーバーできます。

GitHub Enterprise Server クラスターで障害が発生した場合は、レプリカにフェールオーバーできます。