クラスタリングと High Availability (HA) の違い

GitHub Enterprise Server のデプロイトポロジについて

GitHub Enterprise Server インスタンスの仮想マシンは、環境とユーザーのニーズに応じてさまざまなトポロジにデプロイできます。

ディザスターリカバリーと補足バックアップの計画をサポートしたり、地理的に分散したユーザーのネットワークや書き込みパフォーマンスを改善したりするため、高可用性を構成できます。高可用性構成では、1 つのノードがプライマリとして機能し、他のノードがレプリカとして機能します。
数万人の開発者を持つ環境に水平スケーリングを提供するために、クラスタートポロジを使用できます。クラスタリングは、1 つのプライマリノードでリソースの枯渇が日常的に発生する状況に対処します。この構成には、慎重な計画と追加の管理オーバーヘッドが必要です。 GitHub は、お客様と協力してクラスタリングの適格性を判断します。

フェイルオーバーのシナリオ

高可用性 (HA) とクラスタリングはどちらも、障害の原因となる単一ノードを排除することによって冗長性を提供します。可用性は次のシナリオで提供できます:

ソフトウェアのクラッシュ: オペレーティングシステムの障害や、回復不能なアプリケーションによる。
ハードウェアの障害: ストレージハードウェア、CPU、RAM、ネットワークインターフェイスなどを含む。
仮想化ホストシステムの障害: AWS、Azure、または GCP の計画外とスケジュールされたメンテナンスイベントを含む。
論理的あるいは物理的に切断されたネットワーク: フェールオーバーアプライアンスがその障害によって影響されない別のネットワーク上にある場合。

スケーラビリティ

クラスタリングは、負荷を複数のノードに分配することによってスケーラビリティを向上させます。この水平スケーリングは、数万の開発者を持つような組織に適しているかもしれません。HAでは、アプライアンスのスケールはプライマリノードにのみ依存し、負荷がレプリカサーバーに分配されることはありません。

フェイルオーバーの方法と構成における相違点

機能	フェイルオーバーの構成	フェールオーバー方式
高可用性構成	プライマリアプライアンスもしくはロードバランサを指す短いTTLのDNSレコード。	DNSフェイルオーバー及びロードバランサ構成のどちらでも、レプリカアプライアンスを手作業で昇格させなければならない。
クラスタリング	DNSレコードはロードバランサを指さなければならない。	ロードバランサの背後にあるノードが落ちた場合、トラフィックは動作している他のノードに自動的に送られる。

バックアップとディザスターリカバリー

HA もクラスタリングも、定期的なバックアップに代わるものと考えるべきではありません。詳しくは、「アプライアンスでのバックアップの設定」を参照してください。

監視

可用性の機能、特にクラスタリングのように自動フェールオーバーを持つものは、何かが失敗しても通常はサービスが破綻しないので、障害を覆い隠すことができます。 HA またはクラスタリングを利用する場合、障害が起きたことに気づけるよう、各インスタンスの健全性をモニタリングすることが重要です。監視の詳細については、「アラートの推奨閾値」と「クラスターノードの監視」を参照してください。

参考資料

GitHub Enterprise Server クラスタリングの詳細については、「クラスタリングについて」を参照してください。
HA について詳しくは、「高可用性の構成」を参照してください。