16.2. Geo レプリケーションの要件と制約
Red Hat Quay で地理的レプリケーションを確実に実行するには、共有オブジェクトストレージ、ネットワーク、ロードバランシング、および外部ヘルスモニタリングに関する厳格な要件を満たす必要があります。地理的レプリケーションでは、自動フェイルオーバー、データベースレプリケーション、ストレージ認識機能は提供されないため、これらの動作は Red Hat Quay の外部で設計および管理する必要があります。
地理的レプリケーションに関する要件と制約は以下のとおりです。
- Geo レプリケーション設定では、Red Hat Quay で、すべてのリージョンが他の全リージョンのオブジェクトストレージに対して読み取りと書き込みができるようにする必要があります。オブジェクトストレージは、他のすべてのリージョンから地理的にアクセスできる必要があります。
- 1 つの Geo レプリケーションサイトでオブジェクトストレージシステムに障害が発生した場合に、そのサイトの Red Hat Quay デプロイメントをシャットダウンして、クライアントがグローバルロードバランサーにより、ストレージシステムで問題のない残りのサイトにリダイレクトされるようにする必要があります。そうしないと、クライアントでプルとプッシュの失敗が発生します。
- Red Hat Quay は、接続されたオブジェクトストレージシステムの健全性や可用性を内部的に認識しません。分散システムの健全性を監視し、ストレージのステータスに基づいてトラフィックを別のサイトにルーティングするには、ユーザーがグローバルロードバランサー (LB) を設定する必要があります。
-
Geo レプリケーションデプロイメントのステータスを確認するには、
/health/endtoendチェックポイントを使用する必要があります。このチェックポイントは全体的な健全性の監視に使用されます。/health/endtoendエンドポイントを使用してリダイレクトを手動で設定する必要があります。/health/instanceエンドポイントは、ローカルインスタンスの健全性のみをチェックします。 - 1 つのサイトのオブジェクトストレージシステムが利用できなくなった場合に、残りのサイトの残りのストレージシステム (複数可) に自動的にリダイレクトされません。
- Geo レプリケーションは非同期です。サイトが完全に失われると、そのサイトのオブジェクトストレージシステムに保存されていても、障害発生時に残りのサイトに複製されていないデータが失われます。
単一のデータベース、つまりすべてのメタデータと Red Hat Quay 設定がすべてのリージョンで共有されます。
Geo レプリケーションはデータベースをレプリケートしません。障害が発生すると、Geo レプリケーションが有効になっている Red Hat Quay は別のデータベースにフェイルオーバーしません。
- 1 つの Redis キャッシュは Red Hat Quay のセットアップ全体で共有され、すべての Red Hat Quay Pod からアクセスできる必要があります。
-
ストレージバックエンド以外のすべてのリージョンで同じ設定を使用する必要があります。これは、
QUAY_DISTRIBUTED_STORAGE_PREFERENCE環境変数を使用して明示的に設定できます。 - Geo レプリケーションでは、各リージョンにオブジェクトストレージが必要です。ローカルストレージでは機能しません。
- 各リージョンは、ネットワークパスを必要とする各リージョン内のすべてのストレージエンジンにアクセスできる必要があります。
- また、ストレージプロキシーオプションを使用することもできます。
- ストレージバックエンド全体 (たとえば、すべての Blob) がレプリケートされます。対照的に、リポジトリーミラーリングはリポジトリーまたはイメージに限定できます。
- すべての Red Hat Quay インスタンスは、通常はロードバランサーを介して同じエントリーポイントを共有する必要があります。
- すべての Red Hat Quay インスタンスは、共通の設定ファイル内で定義されているため、スーパーユーザーの同じセットが含まれる必要があります。
geo レプリケーション環境では、Clair 設定を
unmanagedに設定できます。アンマネージド Clair データベースにより、Red Hat Quay オペレーターは、Operator の複数のインスタンスが同じデータベースと通信する必要がある地理的に複製された環境で作業できます。詳細は、Clair の詳細設定 を参照してください。Clair 設定を
managedのままにする場合は、Operator によってデプロイされた Clair インスタンスの設定ファイルを取得する必要があります。詳細は、OpenShift Container Platform での Clair デプロイメントの Clair 設定シークレットの取得とデコード を参照してください。- Geo レプリケーションには SSL/TLS 証明書とキーが必要です。詳細は、「Geo-Replication には SSL/TLS 証明書とキーが必要」を参照してください。詳細は、SSL/TLS 証明書を使用した概念実証のデプロイメント を参照してください。
上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Red Hat Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。
16.2.1. スタンドアロン Red Hat Quay のストレージレプリケーションを有効にする リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、Red Hat Quay でストレージのレプリケーションを有効にします。
手順
config.yamlファイルを更新して、データのレプリケート先のストレージエンジンを含めます。使用するすべてのストレージエンジンをリストする必要があります。# ... FEATURE_STORAGE_REPLICATION: true # ... DISTRIBUTED_STORAGE_CONFIG: usstorage: - RHOCSStorage - access_key: <access_key> bucket_name: <example_bucket> hostname: my.noobaa.hostname is_secure: false port: "443" secret_key: <secret_key> storage_path: /datastorage/registry eustorage: - S3Storage - host: s3.amazon.com port: "443" s3_access_key: <access_key> s3_bucket: <example bucket> s3_secret_key: <secret_key> storage_path: /datastorage/registry DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: [] DISTRIBUTED_STORAGE_PREFERENCE: - usstorage - eustorage # ...オプション: すべてのイメージをすべてのストレージエンジンに完全にレプリケートする必要がある場合は、
DISTRIBUTED_STORAGE_DEFAULT_LOCATIONSフィールドを手動で設定すると、イメージをストレージエンジンにレプリケートできます。これにより、すべてのイメージがそのストレージエンジンにレプリケートされます。以下に例を示します。# ... DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - usstorage - eustorage # ...注記namespace ごとのレプリケーションを有効にするには、Red Hat Quay サポートにお問い合わせください。
ストレージを追加して Geo レプリケーションの Replicate to storage engine by default を有効にした後、すべてのストレージで既存のイメージデータを同期する必要があります。これを行うには、次のコマンドを実行してコンテナー内で実行する必要があります。
$ podman exec -it <container_id>新しいストレージを追加した後にコンテンツを同期するために、次のコマンドを入力します。
# scl enable python27 bash# python -m util.backfillreplication注記この操作は、新しいストレージを追加した後にコンテンツを同期するための 1 回限りの操作です。