ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
記事のバージョン: Enterprise Server 2.15

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2019-10-16. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

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

GitHub Enterprise Server High Availability (HA) は冗長性を提供するプライマリ/セカンダリフェイルオーバー構成ですが、クラスタリングは読み書きの負荷を複数のノードに分散させることによって冗長性とスケーラビリティを提供します。

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

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

スケーラビリティ

Clustering provides better scalability by distributing load across multiple nodes. This horizontal scaling may be preferable for some organizations with tens of thousands of developers. HAでは、アプライアンスのスケールはプライマリノードにのみ依存し、負荷がレプリカサーバーに分配されることはありません。

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

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

バックアップとシステム災害復旧

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

モニタリング

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

参考リンク

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください