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

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

記事のバージョン: Enterprise Server 2.18

About geo-replication

Geo-replication on GitHub Enterprise Server uses multiple active replicas to fulfill requests from geographically distributed data centers.

ここには以下の内容があります:

Multiple active replicas can provide a shorter distance to the nearest replica. For example, an organization with offices in San Francisco, New York, and London could run the primary appliance in a datacenter near New York and two replicas in datacenters near San Francisco and London. Using geolocation-aware DNS, users can be directed to the closest server available and access repository data faster. Designating the appliance near New York as the primary helps reduce the latency between the hosts, compared to the appliance near San Francisco being the primary which has a higher latency to London.

The active replica proxies requests that it can't process itself to the primary instance. The replicas function as a point of presence terminating all SSL connections. Traffic between hosts is sent through an encrypted VPN connection, similar to a two-node high availability configuration without geo-replication.

Git requests and specific fileserver requests, such as LFS and file uploads, can be served directly from the replica without loading any data from the primary. Web requests are always routed to the primary, but if the replica is closer to the user the requests are faster due to the closer SSL termination.

Geo DNS, such as Amazon's Route 53 service, is required for geo-replication to work seamlessly. The hostname for the instance should resolve to the replica that is closest to the user's location.

Limitations

Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. Geo-replication will not add capacity to a GitHub Enterprise Server instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.

Monitoring a geo-replication configuration

GitHub Enterprise Serverの可用性は、https://HOSTNAME/statusというURLに対して返されるステータスコードをチェックすればモニタリングできます。 ユーザトラフィックを処理できるアプライアンスは、ステータスコード200 (OK)を返します。 いくつかの理由で、アプライアンスが503 (Service Unavailable) を返すことがあります。

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

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

https://HOSTNAME/setup/replication

Further reading

担当者にお尋ねください

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

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