アクティブなレプリカが複数あれば、最も近いレプリカへの距離を短くできます。 たとえばサンフランシスコ、ニューヨーク、ロンドンにオフィスを持つ組織は、プライマリのアプライアンスをニューヨークの近くのデータセンター内で動作させ、2つのレプリカをサンフランシスコとロンドンの近くのデータセンターで動作させることができます。 地理的な� �所を認識するDNSを利用すれば、ユーザーは利用可能な最も近いサーバへ振り分けられ、リポジトリのデータに高速にアクセスできます。 ニューヨークの近くにあるアプライアンスをプライマリにすれば、ロンドンへのレイテンシが大きいサンフランシスコ近くのアプライアンスをプライマリにする� �合に比べ、ホスト間のレイテンシの削減に役立ちます。
アクティブなレプリカは、自身では処理できないリクエストをプライマリインスタンスに中継します。 レプリカは、すべてのSSL接続をターミネートする接続点として機能します。 ホスト間のトラフィックは、暗号化されたVPN接続を通じて送信されます。これは、Geo-replicationなしの2ノードのHigh Availability構成に似ています。
Git リクエストと、LFS やファイルアップロードなどの特定のファイルサーバーリクエストは、プライマリからデータをロードせずにレプリカから直接処理できます。 Webリクエストは常にプライマリにルーティングされますが、レプリカがユーザに近ければ、近くでSSLのターミネーションが行われることからリクエストは高速に処理されます。
Amazon の Route 53 サービスなど、Geo DNS は、geo レプリケーションがシー� レスに機能するために必要です。 インスタンスのホスト名は、ユーザの� �所に最も近いレプリカに解決されるべきです。
制限事� �
レプリカへの書き込みリクエストには、データをプライマリとすべてのレプリカへ送信することが必要です。 これは、すべての書き込みのパフォーマンスが最も遅いレプリカによって制限されることを意味しますが、新しい Geo-replication レプリカは、プライマリからではなく、既存の同じ� �所に配置された Geo-replication レプリカからデータの大部分をシードできます。
Geo-replication は、GitHub Enterprise Server インスタンスに容量を追� したり、不十分な CPU やメモリリソースに関連するパフォーマンスの問題を解決したりしません。 プライマリのアプライアンスがオフラインである� �合、アクティブなレプリカはいかなる読み込みや書き込みのリクエストも処理できません。
注: GitHub Enterprise Server では、最大で 8 つの高可用性レプリカ (パッシブとアクティブ/Go のいずれでも) が利用できます。
Geo-replication設定のモニタリング
https://HOSTNAME/status URL に対して返される状態コードを確認して、GitHub Enterprise Server の可用性を監視できます。 ユーザー トラフィックを処理できるアプライアンスは、状態コード 200 (OK) を返します。 いくつかの理由でアプライアンスが 503 (サービス利用不可) を返す� �合があります。
- 2ノードの高可用性構成のレプリカなど、そのアプライアンスがパッシブなレプリカである� �合。
- アプライアンスがメンテナンスモードになっている� �合。
- アプライアンスがGeo-replication構成の一部で、た� しアクティブではないレプリカの� �合。
以下からアクセスできるレプリケーションの概要ダッシュボードを使うこともできます。
https://HOSTNAME/setup/replication