クラスタリングとHigh Availability(HA)との違い
GitHub Enterprise Server High Availability (HA) は冗長性を提供するプライマリ/セカンダリフェイルオーバー構成ですが、クラスタリングは読み書きの負荷を複数のノードに分散させることによって冗長性とスケーラビリティを提供します。
フェイルオーバーのシナリオ
High Availability (HA) とクラスタリングはどちらも、障害の原因となる単一ノードを排除することによって冗長性を提供します。 可用性は次のシナリオで提供できます:
- ソフトウエアのクラッシュ。オペレーティングシステムの障害や、回復不能なアプリケーションによるもの。
- ハードウェア障害。ストレージのハードウェア、CPU、RAM、ネットワークインターフェースなどを含みます。
- 仮想化ホストのシステム障害。計画外の、あるいはスケジュール済みの AWS のメンテナンスイベントを含みます。
- 論理的もしくは物理的なネットワークの切断。フェイルオーバーアプライアンスがその障害に影響されない別のネットワークにある場合。
スケーラビリティ
クラスタリングは、負荷を複数のノードにまたがって分散させることでスケーラビリティを向上させます。この水平スケーリングは、数万の開発者を持つような組織などに推奨されます。 HAでは、アプライアンスのスケールはプライマリノードにのみ依存し、負荷がレプリカサーバーに分配されることはありません。
フェイルオーバーの方法と構成における相違点
機能 | フェイルオーバーの構成 | フェイルオーバーの方法 |
---|---|---|
High Availability構成 | プライマリアプライアンスもしくはロードバランサを指す短いTTLのDNSレコード。 | DNSフェイルオーバー及びロードバランサ構成のどちらでも、レプリカアプライアンスを手作業で昇格させなければならない。 |
クラスタリング | DNSレコードはロードバランサを指さなければならない。 | ロードバランサの背後にあるノードが落ちた場合、トラフィックは動作している他のノードに自動的に送られる。 |
バックアップとシステム災害復旧
HAもクラスタリングも、定期的なバックアップに代わるものと考えるべきではありません。 詳しくは、" アプライアンスでのバックアップの設定。"を参照してください。
モニタリング
可用性の機能、特にクラスタリングのように自動フェイルオーバーを持つものは、通常は何かが失敗してもサービスが破綻しないので、障害を覆い隠すことができます。 HAもしくはクラスタリングを利用する場合、障害が起きたことに気づけるよう、各インスタンスの健全性をモニタリングすることが重要です。 モニタリングに関する詳しい情報については、「アラートの推奨閾値」および「クラスタノードのモニタリング」を参照してください。
参考リンク
- GitHub Enterprise Server のクラスタリングに関する詳しい情報については、「クラスタリングの概要」を参照してください。
- HA についての詳しい情報は、「High Availability 向けに GitHub Enterprise Server を設定する」を参照してください。