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

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2019-07-12. 重大なセキュリティ上の問題があっても、パッチはリリースされなくなります。優れたパフォーマンス、改善されたセキュリティ、そして新しい機能のために、GitHub Enterprise の最新バージョンにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise Support に連絡してください。

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

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

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

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

スケーラビリティ

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

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

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

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

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

モニタリング

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

参考リンク

担当者にお尋ねください

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

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