クラスタノードについて

推奨する最小のハードウェア構成

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

サービス	最小のメモリ	最小のデータボリュー� の空き� �域
job-server, memcache-server, web-server	14 GB	1 GB
consul-server, mysql-server, redis-server	14 GB	10 GB
git-server, metrics-server, pages-server, storage-server	14 GB	10 GB
elasticsearch-server	14 GB	10 GB

クラスタリングに必要なサービス

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

サービス	必要な最小ノード数
job-server, memcache-server, metrics-server, web-server	2
mysql-server, redis-server	2
consul-server	3
git-server, pages-server, storage-server	3
elasticsearch-server	3

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

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

• 冗長なノードは、独立したハードウェアに分散させてく� さい。 CPU、メモリ、ストレージデバイスを共用するなら、パフォーマンスの低下が生じ、単一障害点を作ることになります。 ネットワーキングのコンポーネントを共用することも、スループットの低下と障害発生時に接続が失われるリスクの増大を招くことがあります。
• 高速なストレージを使ってく� さい。 ストレージエリアネットワーク（SAN）は、しばしば絶対的なスループットではなく、最大限の� �域の利用、可用性、耐障害性に最適化されます。 GitHub Enterprise Server クラスタリングは冗長性と可用性を提供し、利用可能な最速のストレージ上で最高のパフォーマンスを発揮します。 ローカルのSSDストレージをおすすめします。
• Organization にとって意味のあるノードの層を確立します。 設定例:
  • 2つのノードと以下のサービスを持つフロントエンド層：
    • web-server
    • job-server
    • memcache-server
  • 3つのノードと以下のサービスを持つデータベース層：
    • consul-server
    • mysql-server
    • redis-server
  • 3つのノードと以下のサービスを持つ検索層：
    • elasticsearch-server
  • 3つのノードと以下のサービスを持つストレージ層：
    • git-server
    • pages-server
    • storage-server
    • metrics-server

クラスタの図の例