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