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