クラスタリングについて→
GitHub Enterprise Server クラスタリングを利用することで、GitHub Enterprise Server を構成するサービス群を複数のノードにまたがってスケールアウトできるようになります。
Differences between clustering and high availability (HA)→
GitHub Enterprise Server High Availability (HA) は冗長性を提供するプライマリ／セカンダリフェイルオーバー構成ですが、クラスタリングは読み書きの負荷を複数のノードに分散させることによって冗長性とスケーラビリティを提供します。
クラスタノードについて→
ノードは、クラスタ内で動作する GitHub Enterprise Server インスタンスです。 ぞれぞれのノードは、クラスターに提供される (最終的にはユーザーに提供される) 一連のサービスを実行します。
クラスタのネットワーク設定→
GitHub Enterprise Server クラスタリングが適切に動作するためには、DNS の名前解決、ロードバランシング、ノード間の通信が適切に行われなければなりません。
クラスタの初期化→
GitHub Enterprise Server クラスタはライセンスを使用して設定し、管理シェル (SSH) を使用して初期化する必要があります。
クラスタのアップグレード→
管理シェル (SSH) を使用して GitHub Enterprise Serverクラスタを最新のリリースにアップグレードします。
クラスタノードのモニタリング→
GitHub Enterprise Server クラスタは、2 つ以上のノードに分散された冗長サービスで構成されています。 もしも個々のサービスまたは1つのノード全体に障害があっても、それがクラスタのユーザに即座に見えることはありません。 ただし、パフォーマンスと冗長性が影響を受けるため、GitHub Enterprise Server クラスタの健全性を監視することが重要です。
クラスタノードの入れ替え→
GitHub Enterprise Server ノードを入れ替えるには、クラスタ設定ファイル (cluster.conf) 中で対象となるノードをオフラインとしてマークし、入れ替えるノードを追加しなければなりません。 ノードに障害があった場合、あるいはパフォーマンスを高めるためにリソースの多いノードを追加する場合、この作業が必要になることがあります。
クラスタノードからの待避→
データサービスをクラスタノードから待避させることができます。