• Geo サイト用の統一 URL の設定
  • 両方のサイトにトラフィックを送信する外部 URL の設定
  • Geo サイトが同じ外部 URL を使用するように更新します。
• 別々のURLによるGeoプロキシ
• 制限事項
• プライマリ Geo サイトが停止している場合のセカンダリ・サイトの動作
• セカンダリ Geo サイトによって高速化される機能
• Geo プロキシを無効にします。

セカンダリサイトのGeoプロキシ

• GitLab 14.4 でgeo_secondary_proxyというフラグで導入されました。デフォルトでは無効になっています。
• GitLab 14.6のユニファイドURLではデフォルトで有効。
• GitLab 14.6の異なるURLでは、geo_secondary_proxy_separate_urlsというフラグでデフォルトで無効。
• GitLab 15.1では異なるURLに対してデフォルトで有効。

Geoプロキシを使用してください：

• セカンダリサイトがプライマリサイトにプロキシすることで、読み書きトラフィックを提供します。
• 読み取り専用のオペレーションをローカル・サイトに向けることで、レプリケートされたデータタイプを選択的に高速化します。

有効にすると、セカンダリ・サイトのユーザーは、プライマリ・サイトの UI にアクセスしているかのように WebUI を使用できます。これにより、セカンダリ・サイトの全体的なユーザー・エクスペリエンスが大幅に向上します。

セカンダリプロキシでは、セカンダリ Geo サイトへの Web リクエストはプライマリに直接プロキシされ、読み書き可能なサイトとして動作するように見えます。

プロキシ処理はgitlab-workhorse コンポーネントによって行われます。通常 Geo セカンダリサイトの Rails アプリケーションに送られるトラフィックは、代わりにプライマリ Geo サイトの内部 URLにプロキシされます。

セカンダリプロキシは次のような用途に使用します：

• すべてのGeoサイトを1つのURLで管理する場合。
• 書き込みアクセスを気にすることなく、トラフィックを地理的に負荷分散。

概要についてはGeographic load-balancer と AWS Route53 を使ったセカンダリプロキシ。

Geo サイト用の統一 URL の設定

セカンダリサイトは透過的に読み書きトラフィックを提供できます。単一の外部 URL を使用し、リクエストがプライマリ Geo サイトまたは Geo プロキシを使用するセカンダリ Geo サイトのいずれかにヒットできるようにします。

両方のサイトにトラフィックを送信する外部 URL の設定

Location-aware 公開 URLの手順に従って、プライマリを含むすべての Geo サイトで使用される単一の URL を作成します。

Geo サイトが同じ外部 URL を使用するように更新します。

1. Geoサイトで、Rails（Puma、Sidekiq、Log-Cursor）を実行している各ノードにSSH **イントし、external_url を単一のURLのものに変更します：

   sudo editor /etc/gitlab/gitlab.rb
   

2. URL がすでに設定されているものと異なる場合は、変更が有効になるように更新されたノードを再設定してください：

   gitlab-ctl reconfigure
   

3. セカンダリGeoサイトに設定された新しい外部URLと一致させるには、プライマリデータベースにこの変更を反映させる必要があります。

   プライマリサイトのGeo 管理ページで、セカンダリプロキシを使っている各 Geo セカンダリを編集し、URL フィールドを単一の URL に設定します。プライマリサイトもこの URL を使用していることを確認してください。

Kubernetesでは、global.hosts.domain でプライマリサイトと同じドメインを使用できます。

別々のURLによるGeoプロキシ

GitLab15.1では、別URLのGeoセカンダリプロキシがデフォルトで有効になっています。

Geo secondary proxying with separate URLs” エピックにリンクされているマイナーな既知の問題があります。また、プロキシを有効にした場合に不可能になったユースケースについてのフィードバックをエピックに追加することもできます。

イシューが発生した場合、この機能を無効にするには、geo_secondary_proxy_separate_urls 機能フラグを無効にしてください。

1. プライマリGeoサイトでRailsを実行している1つのノードにSSH接続して実行します：

   sudo gitlab-rails runner "Feature.disable(:geo_secondary_proxy_separate_urls)"
   

2. セカンダリノードでRailsを実行しているすべてのノードでPumaを再起動します：

   sudo gitlab-ctl restart puma
   

Kubernetesでは、toolboxポッドで同じコマンドを実行できます。詳細はKubernetesチートシートを参照してください。

制限事項

• セカンダリプロキシが使用されている場合、非同期 Geo レプリケーションは、Geo セカンダリに遅延を伴ってレプリケートされる可能性のある高速データ型に対して予期せぬイシューを引き起こす可能性があります。

  たとえば、レプリケーションの遅延によって読み取り後書き込みの不整合が発生する潜在的なイシューが見つかりました。レプリケーションの遅延が十分に大きい場合、セカンダリにヒットしたときに Git の読み取りが古いデータを受け取る結果になる可能性があります。

• Rails以外のリクエストはプロキシされないため、他のサービスではリクエストが常にプライマリに送られるように、統一されていない別のURLを使う必要があるかもしれません。このようなサービスには次のようなものがあります：

  • GitLab コンテナレジストリ -別ドメインを使用するように設定できます。
  • GitLab Pages -GitLab Pagesを実行するための前提条件の一部として、常に別ドメインを使用する必要があります。

• 統一されたURLでは、Let’s Encryptは同じドメインを通して両方のIPに到達できなければ証明書を生成することができません。Let’s EncryptでTLS証明書を使うには、手動でドメインをGeoサイトの一つに向け、証明書を生成し、それを他の全てのサイトにコピーします。

• Geo セカンダリサイトを使った Runner の高速化は公式にはサポートされていません。この機能のサポートは計画されており、エピック 9779 で追跡できます。プライマリサイトとセカンダリサイトの間でレプリケーションラグが発生し、ジョブの実行時にセカンダリサイトでパイプライン参照が利用できない場合、ジョブは失敗します。

• セカンダリプロキシと個別の URL を併用する場合、SAML を使用したセカンダリサイトでの署名は、SAML アイデンティティプロバイダ (IdP) がアプリケーションに複数のコールバック URL を設定できる場合にのみサポートされます。

プライマリ Geo サイトが停止している場合のセカンダリ・サイトの動作

ウェブトラフィックがプライマリにプロキシされることを考慮すると、プライマリサイトがアクセスできない場合のセカンダリサイトの動作は異なります：

• UIとAPIトラフィックはプライマリと同じエラーを返します（プライマリがまったくアクセスできない場合は失敗します）。
• アクセスしている特定のセカンダリサイトにすでに存在するリポジトリについては、HTTP(s) や SSH による認証も含め、Git の読み込みオペレーションは期待通りに動作します。
• セカンダリサイトにレプリケートされていないリポジトリに対する Git のオペレーションは、プライマリサイトと同じエラーを返します。
• Git のすべての書き込みオペレーションは、プライマリサイトと同じエラーを返します。

セカンダリ Geo サイトによって高速化される機能

セカンダリ Geo サイトに送信される HTTP トラフィックのほとんどは、プライマリ Geo サイトにプロキシすることができます。このアーキテクチャにより、セカンダリ Geo サイトは書き込みリクエストをサポートすることができます。特定の読み取りリクエストは、セカンダリ サイトでローカルに処理されるため、レイテンシと帯域幅が改善されます。すべての書き込みリクエストはプライマリサイトにプロキシされます。

以下の表は、Geo セカンダリサイト Workhorse プロキシを通して現在テストされているコンポーネントの詳細です。すべてのデータタイプを網羅しているわけではありません。

この文脈では、アクセラリードとは、セカンダリサイト上のコンポーネントのデータが最新である場合に、セカンダリサイトから提供される読み取りリクエストを指します。セカンダリサイトのデータが最新でないと判断された場合、リクエストはプライマリサイトに転送されます。以下の表に記載されていないコンポーネントの読み取り要求は、常に自動的にプライマリ・サイトに転送されます。

1. Git の読み込みはローカルのセカンダリから行われ、プッシュはプライマリにプロキシされます。選択的同期や、リポジトリがGeoセカンダリのローカルに存在しない場合は、”not found “エラーを投げます。
2. Pages は（アクセスコントロールなしで）同じ URL を使用できますが、個別に設定する必要があり、プロキシされません。
3. コンテナレジストリは、ディザスタリカバリシナリオでのみ推奨されます。セカンダリサイトのコンテナレジストリが最新でない場合、要求はプライマリサイトに転送されないため、読み取り要求は古いデータで処理されます。

Geo プロキシを無効にします。

セカンダリサイトが統一URL、つまりプライマリサイトと同じexternal_url を使用している場合、セカンダリプロキシはデフォルトで有効になります。この場合、プロキシを無効にしても、ルーティングによって同じURLでまったく異なる動作が提供されるため、役に立たない傾向があります。

GitLab 15.1では、統一URLがなくてもセカンダリサイトでセカンダリプロキシがデフォルトで有効になっています。セカンダリサイトでプロキシを無効にする必要がある場合は、Geo proxying with Separate URLsの機能フラグを無効にする方がずっと簡単です。しかし、複数のセカンダリサイトがある場合は、このセクションの説明を使ってサイトごとにセカンダリプロキシ機能を無効にすることができます。

さらに、gitlab-workhorse サービスは/api/v4/geo/proxy を10秒ごとにポーリングします。GitLab 15.2以降では、Geoが有効になっていない場合、ポーリングは一度だけ行われます。GitLab 15.2以前では、セカンダリプロキシ機能を無効にすることでこのポーリングを停止することができます。

Linuxパッケージのインストールでは、以下の手順で各Geoサイトで個別にセカンダリー・プロキシ機能を無効にすることができます：

1. セカンダリ Geo サイトの各アプリケーションノード（直接ユーザー トラフィックを提供）に SSH で入り、次の環境変数を追加します：

   sudo editor /etc/gitlab/gitlab.rb
   

   gitlab_workhorse['env'] = {
     "GEO_SECONDARY_PROXY" => "0"
   }
   

2. 変更を有効にするため、更新したノードを再設定します：

   gitlab-ctl reconfigure
   

Kubernetesでは、--set gitlab.webservice.extraEnv.GEO_SECONDARY_PROXY="0" 、またはvaluesファイルに以下を指定します：

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"