Skip to main content

クラスタノードについて

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

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

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

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

GitHub Enterprise Server クラスター内の各ノードは、GitHub Enterprise Server ソフトウェアを実行する個別の仮想マシン (VM) に相当します。 クラスターをデプロイする前に、ハードウェア要件、必要なサービス、設計に関する推奨事項を確認できます。

Note

GitHub Enterprise Server のクラスタリングは HTTPS を使用して構成する必要があります。

ハードウェア要件

各ノードには、ルートボリュームに加えてデータボリュームが別途必要です。 以下に最小の推奨構成を示します。 ユーザのアクティビティや他の製品との結合といった利用方法によっては、さらに多くのリソースが必要になることがあります。

サービス最低限必要なメモリ最低限必要なデータボリュームの空き領域
job-server,
memcache-server,
web-server
14 GB1 GB
consul-server,
mysql-server,
redis-server
14 GB10 GB
git-server,
metrics-server,
pages-server,
storage-server
14 GB10 GB
elasticsearch-server14 GB10 GB

クラスタリングのサービス要件

GitHub Enterprise Server は、一連のサービスから構成されています。 クラスタでは、これらのサービスは複数のノードをまたいで動作し、インスタンスはノード間でリクエストのバランスをとります。 インスタンスは、データの冗長コピーを各ノードに自動的に格納します。 ほとんどのサービスは、同じサービスの他のインスタンスと同等のピア群です。 この分散処理では、mysql-server サービスと redis-server サービスは例外です。これらは 1 つ以上のレプリカ ノードを持つ単一のプライマリ ノードで動作するサービスです。

適切な冗長性を持たせるために、各サービスの運用には少なくとも以下のノードを使ってください。

Note

環境の拡張要件は、リポジトリの規模と数、ユーザーの数、全体的な利用率など、さまざまな要因に左右されます。

クラスター構成の例

次の例は、必要なサービスを実行する 11 個のノードを含む最小クラスター構成を示しています。

サービス必要な最小ノード数
フロントエンドjob-server,
memcache-server,
web-server
2
データベースconsul-server,
mysql-server,
redis-server
3
Storagegit-server,
metrics-server,
pages-server,
storage-server
3
検索するelasticsearch-server3

クラスタ設計に関する推奨

GitHub Enterprise Server を構成するサービス群は、クラスタリングによってそれぞれ個別にスケールアウトできるようになります。 この柔軟性は、様々なスケーラビリティに対する要求を有する組織に適したクラスタの設計と実装に利用できます。 たとえば、組織によっては、大規模あるいは頻繁なフェッチのためにストレージのスループットに対する要求は高いものの、Webサーバーの利用は比較的少ないことがあるでしょう。 別の Organization では、より少ないストレージ リソースで良好なパフォーマンスを発揮する可能性がありますが、pages-serverelasticsearch-server を実行する多くのノードを必要とします。 多くの様々な組み合わせが可能です。 お客様の固有の要求に最も適したクラスタの構成を決めるため、顧客担当と共同で作業してください。

  • 冗長なノードは、独立したハードウェアに分散させてください。 CPU、メモリ、ストレージデバイスを共用するなら、パフォーマンスの低下が生じ、単一障害点を作ることになります。 ネットワーキングのコンポーネントを共用することも、スループットの低下と障害発生時に接続が失われるリスクの増大を招くことがあります。
  • 高速なストレージを使ってください。 ストレージエリアネットワーク(SAN)は、しばしば絶対的なスループットではなく、最大限の領域の利用、可用性、耐障害性に最適化されます。 GitHub Enterprise Server クラスタリングは冗長性と可用性を提供し、利用可能な最速のストレージ上で最高のパフォーマンスを発揮します。 ローカルのSSDストレージをおすすめします。