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

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

Geo-replicationについて

GitHub Enterprise Server 上の Geo-replication は、地理的に分散したデータセンターからの要求を満たすために、複数のアクティブなレプリカを使用します。

アクティブなレプリカが複数あれば、最も近いレプリカへの距離を短くできます。 たとえばサンフランシスコ、ニューヨーク、ロンドンにオフィスを持つ組織は、プライマリのアプライアンスをニューヨークの近くのデータセンター内で動作させ、2つのレプリカをサンフランシスコとロンドンの近くのデータセンターで動作させることができます。 地理的な場所を認識するDNSを利用すれば、ユーザーは利用可能な最も近いサーバへ振り分けられ、リポジトリのデータに高速にアクセスできます。 ニューヨークの近くにあるアプライアンスをプライマリにすれば、ロンドンへのレイテンシが大きいサンフランシスコ近くのアプライアンスをプライマリにする場合に比べ、ホスト間のレイテンシの削減に役立ちます。

アクティブなレプリカは、自身では処理できないリクエストをプライマリインスタンスに中継します。 レプリカは、すべてのSSL接続をターミネートする接続点として機能します。 ホスト間のトラフィックは、暗号化されたVPN接続を通じて送信されます。これは、Geo-replicationなしの2ノードのHigh Availability構成に似ています。

Gitのリクエストや、LFSやファイルアップロードのような特定のファイルサーバのリクエストは、プライマリからデータをロードすることなくレプリカが直接処理できます。 Webリクエストは常にプライマリにルーティングされますが、レプリカがユーザに近ければ、近くでSSLのターミネーションが行われることからリクエストは高速に処理されます。

Geo-replicationがスムーズに動作するためには、Amazon's Route 53 サービスのようなGeo DNSが必要です。 インスタンスのホスト名は、ユーザの場所に最も近いレプリカに解決されるべきです。

制限事項

レプリカへの書き込みリクエストには、データをプライマリとすべてのレプリカへ送信することが必要です。 これはすなわち、すべての書き込みのパフォーマンスは最も低速なレプリカによって制約されるということです。 Geo-replication は、GitHub Enterprise Server インスタンスに容量を追加したり、不十分な CPU やメモリリソースに関連するパフォーマンスの問題を解決したりしません。

Geo-replication設定のモニタリング

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

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

https://HOSTNAME/setup/replication

参考リンク

担当者にお尋ねください

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

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