このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2023-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

About high availability configuration

この記事の内容

In a high availability configuration, a fully redundant secondary GitHub Enterprise Server appliance is kept in sync with the primary appliance through replication of all major datastores.

When you configure high availability, there is an automated setup of one-way, asynchronous replication of all datastores (Git repositories, MySQL, Redis, and Elasticsearch) from the primary to the replica appliance. Most GitHub Enterprise Server configuration settings are also replicated, including the [Management Console] password. For more information, see "Web UI からインスタンスを管理する."

GitHub Enterprise Server supports an active/passive configuration, where the replica appliance runs as a standby with database services running in replication mode but application services stopped.

After replication has been established, the [Management Console] is no longer accessible on replica appliances. If you navigate to the replica's IP address or hostname on port 8443, you'll see a "Server in replication mode" message, which indicates that the appliance is currently configured as a replica.

注: GitHub Enterprise Server では、最大で 8 つの高可用性レプリカ (パッシブとアクティブ/Go のいずれでも) が利用できます。

Targeted failure scenarios

Use a high availability configuration for protection against:

  • ソフトウェアのクラッシュ: オペレーティング システムの障害や、回復不能なアプリケーションによる。
  • ハードウェアの障害: ストレージ ハードウェア、CPU、RAM、ネットワーク インターフェイスなどを含む。
  • 仮想化ホスト システムの障害: AWS、Azure、または GCP の計画外とスケジュールされたメンテナンス イベントを含む。
  • 論理的あるいは物理的に切断されたネットワーク: フェールオーバー アプライアンスがその障害によって影響されない別のネットワーク上にある場合。

A high availability configuration is not a good solution for:

  • Scaling-out. While you can distribute traffic geographically using geo-replication, the performance of writes is limited to the speed and availability of the primary appliance. For more information, see "About geo-replication."
  • CI/CD load. If you have a large number of CI clients that are geographically distant from your primary instance, you may benefit from configuring a repository cache. For more information, see "About repository caching."
  • Backing up your primary appliance. A high availability replica does not replace off-site backups in your disaster recovery plan. Some forms of data corruption or loss may be replicated immediately from the primary to the replica. To ensure safe rollback to a stable past state, you must perform regular backups with historical snapshots.
  • Zero downtime upgrades. To prevent data loss and split-brain situations in controlled promotion scenarios, place the primary appliance in maintenance mode and wait for all writes to complete before promoting the replica.

Network traffic failover strategies

During failover, you must separately configure and manage redirecting network traffic from the primary to the replica.

DNS failover

With DNS failover, use short TTL values in the DNS records that point to the primary GitHub Enterprise Server appliance. We recommend a TTL between 60 seconds and five minutes.

During failover, you must place the primary into maintenance mode and redirect its DNS records to the replica appliance's IP address. The time needed to redirect traffic from primary to replica will depend on the TTL configuration and time required to update the DNS records.

If you are using geo-replication, you must configure Geo DNS to direct traffic to the nearest replica. For more information, see "About geo-replication."

Load balancer

ロードバランサの設計では、ネットワークデバイスを使ってGit及びHTTPのトラフィックを個々のGitHub Enterprise Serverアプライアンスに向かわせます。 ロードバランサを使って、セキュリティのためにアプライアンスへの直接のトラフィックを制限したり、必要に応じてDNSのレコードを変更することなくトラフィックをリダイレクトしたりできます。 PROXYプロトコルをサポートするTCPベースのロードバランサを使うことを強くおすすめします。 GitHub Enterprise Serverのホスト名に対するDNSルックアップは、ロードバランサに解決されなければなりません。 Subdomain Isolationを有効化することをおすすめします。 サブドメイン分離が有効化されている場合、追加のワイルドカード レコード (*.HOSTNAME) もロード バランサーに解決されなければなりません。 詳しくは、「Subdomain Isolationの有効化」を参照してください。

During failover, you must place the primary appliance into maintenance mode. You can configure the load balancer to automatically detect when the replica has been promoted to primary, or it may require a manual configuration change. You must manually promote the replica to primary before it will respond to user traffic. For more information, see "GitHub Enterprise Server でロードバランサを使用する."

https://HOSTNAME/status URL に対して返される状態コードを確認して、GitHub Enterprise Server の可用性を監視できます。 ユーザー トラフィックを処理できるアプライアンスは、状態コード 200 (OK) を返します。 アプライアンスは、いくつかの理由で、この URL および他の Web や API 要求に対して 503 (サービス利用不可) を返す場合があります。

  • 2ノードの高可用性構成のレプリカなど、そのアプライアンスがパッシブなレプリカである場合。
  • アプライアンスがメンテナンスモードになっている場合。
  • アプライアンスがGeo-replication構成の一部で、ただしアクティブではないレプリカの場合。

以下からアクセスできるレプリケーションの概要ダッシュボードを使うこともできます。

https://HOSTNAME/setup/replication

Utilities for replication management

People with administrative SSH access to an instance in a high-availability configuration can use command-line utilities to manage replication. For more information, see "コマンド ライン ユーティリティ."

Further reading