Geo

Geoは、広範囲にわたる分散型開発チーム向けのソリューションです。ディザスターリカバリー戦略の一環としてウォームスタンバイを提供することを目的としています。ただし、Geoはすぐに使用できるHAソリューションnot（ではありません）。

適切なバージョンのドキュメントを使用しているかどうかを確認するには、GitLab.comのGeoページに移動し、ブランチ/タグを切り替えドロップダウンリストから適切なリリースを選択します。たとえば、v15.7.6-eeなどです。

単一のGitLabインスタンスから遠く離れた場所にいるチームやRunnerにとって、大規模なリポジトリのフェッチは時間がかかる場合があります。

Geoは、リモートチームに地理的に近い場所に配置できるローカルキャッシュを提供し、読み取りリクエストに対応できるようにします。これにより、大規模なリポジトリのクローン作成やフェッチにかかる時間を短縮し、開発を加速させ、リモートチームの生産性を高めることができます。

Geoセカンダリサイトは、書き込みリクエストを透過的にプライマリサイトにプロキシします。すべてのGeoサイトは、単一のGitLab URLに応答するように設定できます。したがって、ユーザーがどのサイトにアクセスしたとしても、一貫性がありシームレスで包括的なエクスペリエンスを提供できます。

Geoでは、Geo用語集に記載された定義済みの用語を使用しています。これらの用語をよく理解しておくようにしましょう。

ユースケース

Geoの実装は、いくつかのユースケースに対応しています。このセクションでは、想定されるユースケースをいくつか紹介し、それぞれの利点を説明します。

リージョナルディザスターリカバリー

Geoをディザスターリカバリーソリューションとして使用すると、プライマリサイトとは異なるリージョンにウォームスタンバイセカンダリサイトを用意できます。データはセカンダリサイトに継続的に同期され、常に最新の状態に保たれます。データセンターやネットワークの停止、ハードウェアの故障などの障害が発生した場合、完全に稼働しているセカンダリサイトにフェイルオーバーすることが可能です。計画フェイルオーバーを使用して、ディザスターリカバリーのプロセスとインフラストラクチャをテストできます。

利点:

• 地域的な災害が発生した場合の事業継続性。
• 低い目標リカバリー時間（RTO）と目標リカバリー時点（RPO）。
• GitLab Environment Toolkit（GET）による自動化された（ただし完全に自動ではない）フェイルオーバー。
• 最小限の運用作業。人による介入なしの継続的なレプリケーションと検証により、セカンダリサイトは常に最新状態に保たれ、レプリケートされたデータが転送中や保存中に破損しないことが保証されます。

リモートチームの迅速化

リモートチームに地理的に近い場所にGeoセカンダリサイトを配置することで、読み取り操作を高速化するローカルキャッシュを提供します。複数のGeoセカンダリサイトを配置して、それぞれにリモートチームが必要とするプロジェクトのみを同期するように調整できます。透過的なプロキシと統一されたURLによる地理的ルーティングにより、一貫性のあるシームレスなデベロッパーエクスペリエンスを実現します。

利点:

• 地理的に分散したチームのGitLabエクスペリエンスを向上させます。Geoはセカンダリサイトで完全なGitLabエクスペリエンスを提供します。1つのプライマリGitLabサイトを維持しながら、セカンダリサイトで各分散チーム向けに読み取り/書き込みアクセスと完全なUIエクスペリエンスを提供します。
• 分散したデベロッパーが大規模なリポジトリやプロジェクトをクローンおよびフェッチするのにかかる時間を、数分から数秒に短縮します。
• すべてのデベロッパーが、どこにいてもアイデアを提案したり、並行して作業したりすることが可能となります。
• プライマリサイトとセカンダリサイト間で読み取りの負荷を分散します。
• 遠隔オフィス間の低速な接続を克服し、分散チームの速度を向上させることで時間を節約します。
• 自動化されたタスク、カスタムインテグレーション、内部ワークフローの読み込み時間を短縮します。

CI/CDトラフィックのオフロード

Geoセカンダリサイトからクローンを作成するようにCI/CD Runnerを設定できます。セカンダリサイトはRunnerのワークロードのニーズに合わせて調整でき、プライマリサイトをミラーリングする必要はありません。サポートされている読み取りリクエストは、セカンダリサイトのキャッシュされたデータで処理され、セカンダリサイトのデータが古くなっているか利用できない場合、リクエストは透過的にプライマリサイトに転送されます。

利点:

• プライマリサイトでは、トラフィックをセカンダリサイトに分散することで、CI/CDトラフィックがユーザーエクスペリエンスに与える影響を軽減できます。
• リージョン間のトラフィックを削減し、組織にとって最もコスト効率の良い場所でCI/CDコンピューティングを実行できます。データのリージョン間コピーを1つ作成し、それをセカンダリサイトに対する繰り返しの読み取りリクエストで利用できるようにします。

追加のユースケース

インフラストラクチャの移行

Geoを使用して、新しいインフラストラクチャに移行できます。GitLabインスタンスを新しいサーバーまたはデータセンターに移行する場合、Geoを使用することで、旧インスタンスがユーザーへのサービス提供を継続している間に、GitLabデータを新しいインスタンスにバックグラウンドで移行できます。アクティブなGitLabデータへの変更はすべて新しいインスタンスにコピーされるため、切り替え中にデータが失われることはありません。

ただし、Geoを使用して、PostgreSQLデータベースを別のオペレーティングシステムに移行することはできません。PostgreSQLが動作しているオペレーティングシステムをアップグレードするを参照してください。

利点:

• バックアップと復元を使用する移行方式と比べて、移行中のダウンタイムを大幅に短縮できます。切り替え時のダウンタイムウィンドウの前にアクティブなGitLabインスタンスを停止することなく、バックグラウンドでデータを新しいインスタンスにコピーします。

GitLab Dedicatedへの移行

Geoを使用して、GitLab Self-ManagedからGitLab Dedicatedに移行することもできます。GitLab Dedicatedへの移行は、インフラストラクチャの移行に似ています。

利点:

• ダウンタイムが大幅に短縮され、オンボーディングエクスペリエンスがスムーズになります。データ移行がバックグラウンドで行われている間、GitLab Self-Managedを引き続き使用できます。

Geoでは対応できないユースケース

Geoは、すべてのユースケースに対応できるよう設計されているわけではありません。このセクションでは、Geoが適切なソリューションではないユースケースの例を紹介します。

データ輸出コンプライアンスを強制する

Geoの選択的同期機能を使用すると、セカンダリサイトに同期されるプロジェクトを制限できますが、これはリージョン間のトラフィックやストレージ要件を削減するために設計されており、輸出コンプライアンスを強制することを目的としたものではありません。プライバシー、サイバーセキュリティ、および該当する貿易管理法に関する法的義務については、ソリューションおよびドキュメントに基づいて、ご自身で継続的に判断する必要があります。ソリューションおよびドキュメントは変更される可能性があります。

アクセス制御を提供する

Geoの読み取り専用セカンダリサイト機能は、中核的な機能ではなく、将来的にサポートされない可能性があります。そのため、アクセス制御の目的でこの機能に依存しないでください。GitLabは、アクセス制御により適した、認証および認可の制御機能を提供しています。

ゼロダウンタイムアップグレードの代替手段

Geoは、ゼロダウンタイムアップグレードのためのソリューションではありません。Geoセカンダリサイトをアップグレードする前に、Geoプライマリサイトをアップグレードする必要があります。

悪意のある破損や意図しない破損から保護する

Geoは、プライマリサイトの破損をすべてのセカンダリサイトにレプリケートします。悪意のある破損や意図しない破損から保護するには、バックアップでGeoを補完する必要があります。

アクティブ-アクティブ型の高可用性設定

Geoは、アクティブ-パッシブ型の高可用性ソリューションとして設計されています。結果整合性の同期モデルで動作します。つまり、セカンダリサイトはプライマリサイトと緊密に同期されているわけではありません。セカンダリサイトはわずかに遅れてプライマリサイトに追従するため、災害発生時に少量のデータが失われる可能性があります。災害発生時にセカンダリサイトにフェイルオーバーするには、人的介入が必要です。ただし、GitLab Environment Toolkit（GET）を使用してすべてのサイトをデプロイしている場合、セカンダリサイトをプライマリサイトに昇格させるプロセスの大部分はGETによって自動化されています。

Gitaly Cluster (Praefect)

GeoをGitaly Cluster (Praefect)と混同しないようにご注意ください。GeoとGitaly Clusterの違いの詳細については、Geoとの比較を参照してください。

Geoの仕組み

以下は、GitLab環境におけるGeoの動作の簡単な概要です。詳細については、Geoの開発ドキュメントを参照してください。

Geoインスタンスは、データの読み取りに加えて、プロジェクトのクローン作成やフェッチにも使用できます。これにより、遠隔地との間で大規模なリポジトリの操作がはるかに高速化されます。

Geoを有効にすると、次のようになります:

• 元のインスタンスはプライマリサイトと呼ばれます。
• レプリケートを行うサイトはセカンダリサイトと呼ばれます。

次の点に注意してください:

• セカンダリサイトは、プライマリサイトと通信して、次のことを行います:
  • ログイン用のユーザーデータを取得する（API）。
  • リポジトリ、LFSオブジェクト、添付ファイルをレプリケートする（HTTPS + JWT）。
• プライマリサイトは、レプリケーションの詳細を表示するためにセカンダリサイトと通信します。プライマリサイトは、同期および検証データを取得するためにセカンダリサイトに対してGraphQLクエリ（API）を実行します。
• Git LFSを含め、HTTPおよびSSHを通じてセカンダリサイトに直接プッシュできます。その際、セカンダリサイトはリクエストをプライマリサイトにプロキシします。
• Geoを使用する場合、既知の問題がいくつか存在します。

アーキテクチャ

次の図は、Geoの基盤アーキテクチャを示しています。

この図の説明:

• プライマリサイトと1つのセカンダリサイトの詳細を示しています。
• データベースへの書き込みは、プライマリサイトでのみ実行できます。セカンダリサイトは、PostgreSQLストリーミングレプリケーションを使用してデータベースの更新を受信します。
• LDAPサーバーが存在する場合は、ディザスターリカバリーシナリオに備えてレプリケートするよう設定する必要があります。
• セカンダリサイトは、JWTによって保護された特別な認証メカニズムを使用して、プライマリサイトに対してさまざまなタイプの同期を実行します:
  • リポジトリは、HTTPS経由でGitを介してクローンまたは更新されます。
  • 添付ファイル、LFSオブジェクト、およびその他のファイルは、プライベートAPIエンドポイントを通じてHTTPS経由でダウンロードされます。

Git操作を実行するユーザーの視点では、次のように動作します:

• プライマリサイトは、完全な読み取り/書き込み可能なGitLabインスタンスとして動作します。
• セカンダリサイトは、完全な読み取り/書き込み可能なGitLabインスタンスとして動作します。セカンダリサイトは、すべての操作をプライマリサイトに透過的にプロキシしますが、いくつかの重要な例外があります。特に、セカンダリサイトが最新の状態であれば、Gitのフェッチはセカンダリサイトによって処理されます。

GitLab UIを閲覧するユーザーやAPIを使用するユーザーの視点では、次のように動作します:

• プライマリサイトは、完全な読み取り/書き込み可能なGitLabインスタンスとして動作します。
• セカンダリサイトは、完全な読み取り/書き込み可能なGitLabインスタンスとして動作します。セカンダリサイトは、すべての操作をプライマリサイトに透過的にプロキシしますが、いくつかの重要な例外があります。特に、Web UIアセットはセカンダリサイトによって提供されます。

図を簡略化するために、一部の必要なコンポーネントは省略されています。

• SSH経由のGitの操作には、gitlab-shellが必要です。
• HTTPS経由のGitの操作には、gitlab-workhorseが必要です。

セカンダリサイトには、2つの異なるPostgreSQLデータベースが必要です:

• メインGitLabデータベースからデータをストリーミングする、読み取り専用データベースインスタンス。
• セカンダリサイトが内部的に使用し、レプリケートされたデータを記録するための読み取り/書き込みデータベースインスタンス（トラッキングデータベース）。

セカンダリサイトでは、追加のデーモンである: Geo Log Cursorも実行します。

Geoを実行するための要件

Geoを実行するには、次の要件を満たす必要があります:

• OpenSSH 6.9以降をサポートするオペレーティングシステム（データベース内の許可されたSSHキーの高速検索に必要）。次のオペレーティングシステムは、最新バージョンのOpenSSHが含まれていることが確認されています:
  • CentOS 7.4以降
  • Ubuntu 16.04以降
• 可能な場合は、すべてのGeoサイトで同じバージョンのオペレーティングシステムを使用する必要があります。Geoサイト間で異なるバージョンのオペレーティングシステムを使用する場合は、データベースインデックスのサイレントな破損を防ぐため、Geoサイト間でmust（必ず）OSのロケールデータの互換性を確認してください。
• ストリーミングレプリケーション機能を使用するGitLabリリースでは、サポートされているPostgreSQLのバージョンを使用する必要があります。
  • PostgreSQLの論理レプリケーションはサポートされていません。
• すべてのサイトで同じPostgreSQLバージョンを実行する必要があります。
• Git 2.9以降
• LFSを使用する場合、ユーザー側ではGit-lfs 2.4.2以降が必要です。
• すべてのサイトで、完全に同じGitLabバージョンを実行する必要があります。メジャー、マイナー、パッチバージョンのすべてが一致していなくてはなりません。
• すべてのサイトで、同じリポジトリストレージを定義する必要があります。

さらに、GitLabの最小要件も確認し、より良いエクスペリエンスのために最新バージョンのGitLabを使用してください。

ファイアウォールルール

次の表に、Geoのプライマリサイトとセカンダリサイト間で開いておく必要がある基本的なポートを示します。フェイルオーバーを簡素化するために、ポートを双方向で解放することをおすすめします。

GitLabで使用するポートの完全なリストについては、パッケージのデフォルトを参照してください。

内部URL

GeoセカンダリサイトからGeoプライマリサイトへのHTTPリクエストは、Geoプライマリサイトの内部URLを使用します。管理者エリアのGeoプライマリサイト設定でこれが明示的に定義されていない場合、プライマリサイトのパブリックURLが使用されます。

Geoプライマリサイトの内部URLを更新するには、次の手順に従います:

1. 左側のサイドバーの下部で、管理者を選択します。新しいナビゲーションをオンにしている場合は、右上隅でアバターを選択し、次に管理者を選択します。
2. Geo > サイトを選択します。
3. プライマリサイトで編集を選択します。
4. 内部URLを変更し、変更を保存を選択します。

Geoトラッキングデータベース

トラッキングデータベースインスタンスは、ローカルインスタンスで何を更新する必要があるかを制御するメタデータとして使用されます。例:

• 新しいアセットをダウンロードする。
• 新しいLFSオブジェクトをフェッチする。
• 最近更新されたリポジトリから変更をフェッチする。

レプリケートされたデータベースインスタンスは読み取り専用であるため、各セカンダリサイトにはこの追加のデータベースインスタンスが必要です。

Geo Log Cursor

このデーモンは次の処理を行います:

• プライマリサイトからセカンダリデータベースインスタンスにレプリケートされたイベントのログを読み取る。
• 実行する必要がある変更内容で、Geoトラッキングデータベースインスタンスを更新する。

トラッキングデータベースインスタンス上で何らかの項目が更新対象としてマークされると、セカンダリサイト上の非同期ジョブが必要な操作を実行し、状態を更新します。

この新しいアーキテクチャにより、GitLabはサイト間の接続の問題に対して高い回復力を持つようになります。セカンダリサイトがプライマリサイトからどれだけ長く切断されていても、すべてのイベントを正しい順序で再生し、再びプライマリサイトと同期できるようになります。

既知の問題

• セカンダリサイトに直接プッシュすると、セカンダリサイトが直接処理するのではなく、リクエストをプライマリサイトにリダイレクトする（HTTPの場合）か、またはリクエストをプライマリサイトにプロキシします（SSHの場合）。URIに認証情報が埋め込まれている場合、HTTP経由でGitを使用することはできません（例: https://user:personal-access-token@secondary.tld）。詳細については、Geoサイトの使用方法を参照してください。
• OAuthログインを行うには、プライマリサイトがオンラインである必要があります。既存のセッションやGitには影響しません。セカンダリサイトがプライマリとは別のOAuthプロバイダーを使用できるようにするためのサポートは、現在計画中です。
• インストールでは、いくつかの手順を手動で実行する必要があり、状況によっては全体で約1時間かかる場合があります。GitLabのリファレンスアーキテクチャに基づいて、GitLab Environment ToolkitのTerraformやAnsibleスクリプトを使用して、本番環境のGitLabインスタンスをデプロイおよび運用することを検討してください。これには、日常的なタスクの自動化も含まれます。エピック1465では、Geoのインストールをさらに改善する提案がなされています。
• イシュー/マージリクエストのリアルタイム更新（たとえば、ロングポーリングを使用した更新）は、HTTPプロキシが無効になっているセカンダリサイトでは機能しません。
• 選択的同期は、レプリケート対象となるリポジトリとファイルを制限するだけです。PostgreSQLのデータ全体は引き続きレプリケートされます。選択的同期は、コンプライアンス対応や輸出規制のユースケースに対応するように構築されたものではありません。
• Pagesのアクセス制御は、セカンダリサイトでは機能しません。詳細については、イシュー9336（詳細）を参照してください。
• 複数のセカンダリサイトを持つデプロイにおけるディザスターリカバリーでは、プロモートされなかったすべてのセカンダリサイトで、PostgreSQLのストリーミングレプリケーションを再初期化して新しいプライマリサイトに従わせる必要があるため、ダウンタイムが発生します。
• SSH経由のGitの場合、どのサイトを閲覧してもプロジェクトのクローンURLが正しく表示されるようにするには、セカンダリサイトがプライマリサイトと同じポートを使用する必要があります。詳細については、イシュー339262を参照してください。
• セカンダリサイトに対してSSH経由でGitプッシュを行う場合、1.86 GBを超えるプッシュは機能しません。このバグについては、イシュー413109で追跡しています。
• バックアップは、Geoセカンダリサイトでは実行できません。
• セカンダリサイトに対してSSH経由でオプション付きのGitプッシュを行うと、機能せず、接続が切断されます。詳細については、イシュー417186を参照してください。
• Geoセカンダリサイトは、ほとんどの場合、パイプラインの最初のステージにおけるクローンリクエストを高速化（提供）しません。Gitの変更が大きい、帯域幅が小さい、パイプラインステージが短いといった理由により、後続のステージもセカンダリサイトから提供されるとは限りません。一般に、後続のステージに対するクローンリクエストはセカンダリサイトから提供されます。イシュー446176では、この理由について説明するとともに、Runnerのクローンリクエストがセカンダリサイトから提供される可能性を高めるための機能拡張が提案されています。
• 単一のGitリポジトリに対して高頻度でプッシュが行われると、セカンダリサイトのローカルコピーが常に最新ではないという状態に陥る可能性があります。このような場合、そのリポジトリに対するすべてのGitフェッチがプライマリサイトに転送されることになります。詳細については、イシュー455870を参照してください。
• プロキシ機能は、PumaサービスまたはWebサービスのGitLabアプリケーションでのみ実装されているため、他のサービスではこの動作の恩恵を受けることができません。リクエストが常にプライマリサイトに送信されるようにするには、別のURLを使用する必要があります。該当するサービスには、次のようなものがあります:
  • GitLabコンテナレジストリ - registry.example.comのように、別のドメインを使用するように設定できます。セカンダリサイトのコンテナレジストリは、ディザスターリカバリーのみを目的としています。特にプッシュ操作の場合、ユーザーをセカンダリサイトにルーティングしないでください。データがプライマリサイトに伝播されないからです。
  • GitLab Pages - GitLab Pagesを運用するための前提要件の一部として、常に別のドメインを使用する必要があります。
• 統一されたURLを使用している場合、Let’s Encryptは同じドメインを通じて両方のIPアドレスに到達できなければ、証明書を生成できません。Let’s Encryptが発行するTLS証明書を使用するには、ドメインをいずれかのGeoサイトに手動で割り当てて証明書を生成し、その後、その証明書を他のすべてのサイトにコピーします。
• セカンダリサイトがプライマリサイトとは異なるURLを使用している場合、SAMLを使用してセカンダリサイトにサインインするには、SAML Identity Provider（IdP）がアプリケーションに複数のコールバックURLを設定できる必要があります。
• セカンダリサイトに対してSSH経由でオプション--depthを指定してGitのクローンやフェッチリクエストを実行した場合、リクエスト開始時点でセカンダリサイトが最新の状態でなければ、処理が進行せず、無期限にハングします。これは、プロキシ処理中にGit SSHをGit HTTPSに変換する際に発生する問題が原因です。詳細については、イシュー391980を参照してください。前述の変換処理を含まない新しいワークフローが、LinuxパッケージのGitLab Geoセカンダリサイトで使用できるようになりました。これは、機能フラグで有効にできます。詳細については、イシュー454707のコメントを参照してください。クラウドネイティブGitLab Geoセカンダリサイト向けの修正は、イシュー5641で追跡されています。
• 一部のお客様から、セカンダリサイトが最新の状態でない場合、SSH経由でgit fetchを実行するとハングまたはタイムアウトして失敗すると報告されています。SSH経由でのgit cloneリクエストには影響しません。詳細については、イシュー454707を参照してください。LinuxパッケージのGitLab Geoセカンダリサイト向けには、この問題に対する修正が用意されており、機能フラグで有効にできます。詳細については、イシュー454707のコメントを参照してください。クラウドネイティブGitLab Geoセカンダリサイト向けの修正は、イシュー5641で追跡されています。
• 相対URLをGitLab Geoで使用しないでください。サイト間のプロキシが中断されます。詳細については、イシュー456427を参照してください。

レプリケートされるデータタイプ

GitLabのすべてのデータタイプとレプリケート対象のデータタイプについては、完全なリストがあります。

インストール後の作業に関するドキュメント

セカンダリサイトにGitLabをインストールして初期設定を行ったら、インストール後の情報については次のドキュメントを参照してください。

Geoをセットアップする

Geoの設定の詳細については、Geoのセットアップを参照してください。

Geoでオブジェクトストレージを使用する

Geoでオブジェクトストレージを使用するよう設定する方法については、Geoとオブジェクトストレージを参照してください。

コンテナレジストリをレプリケートする

コンテナレジストリをレプリケートする方法の詳細については、セカンダリサイトのコンテナレジストリを参照してください。

Geoサイトの統一されたURLを設定する

AWS Route53やGoogle Cloud DNSを使用して、単一のロケーション認識型のURLを設定する方法の例については、Geoサイトの統一されたURLを設定するを参照してください。

シングルサインオン（SSO）

シングルサインオン（SSO）の設定の詳細については、Geoにおけるシングルサインオン（SSO）を参照してください。

LDAP

LDAPの設定の詳細については、Geoにおけるシングルサインオン（SSO）> LDAPを参照してください。

Geoを調整する

Geoの調整の詳細については、Geoの調整を参照してください。

レプリケーションを一時停止および再開する

詳細については、レプリケーションの一時停止と再開を参照してください。

バックフィル

セカンダリサイトをセットアップすると、プライマリサイトから不足しているデータのレプリケートを開始します。このプロセスはbackfill（バックフィル）と呼ばれます。ブラウザで、プライマリサイトのGeo Nodes（Geoノード）ダッシュボードから、各Geoサイトの同期プロセスをモニタリングできます。

バックフィル中に発生したエラーは、バックフィルの最後に再試行するようスケジュールされます。

Runner

• 標準的なRunnerフリートのベストプラクティスに加えて、RunnerをGeoセカンダリサイトに接続するよう設定することで、ジョブの負荷を分散させることもできます。セカンダリに対するRunnerの登録方法を参照してください。
• フェイルオーバー中のRunner接続の処理方法も参照してください。

Geoをアップグレードする

Geoサイトを最新のGitLabバージョンに更新する方法については、Geoサイトをアップグレードするを参照してください。

セキュリティレビュー

Geoのセキュリティの詳細については、Geoセキュリティレビューを参照してください。

Geoサイトを削除する

Geoサイトの削除の詳細については、セカンダリGeoサイトを削除するを参照してください。

Geoを無効化する

Geoを無効にする方法については、Geoを無効化するを参照してください。

ログファイル

Geoは、構造化されたログメッセージをgeo.logファイルに保存します。

Geoのログへのアクセス方法と使用方法の詳細については、ログシステムドキュメントのGeoのセクションを参照してください。

ディザスターリカバリー

ディザスターリカバリーの状況でGeoを使用してデータ損失を軽減し、サービスを復元する方法の詳細については、ディザスターリカバリーを参照してください。

よくある質問

一般的な質問への回答については、GeoのFAQを参照してください。

トラブルシューティング

• Geoのトラブルシューティングの手順については、Geoのトラブルシューティングを参照してください。

• ディザスターリカバリのトラブルシューティングの手順については、Geoフェイルオーバーのトラブルシューティングを参照してください。