Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-06-03. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

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

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

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

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もしくはクラスタリングを利用する� �合、障害が起きたことに気づけるよう、各インスタンスの健全性をモニタリングすることが重要です。 For more information on monitoring, see "Recommended alert thresholds" and "Monitoring cluster nodes."

参考リンク