6.2. Geo レプリケーションの要件と制約
- 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 は geo-replicated environment で作業できます。この環境では、Red Hat Quay Operator の複数のインスタンスが同じデータベースと通信する必要があります。詳細は、Clair の詳細設定 を参照してください。 - Geo レプリケーションには SSL/TLS 証明書とキーが必要です。詳細は、「Geo-Replication には SSL/TLS 証明書とキーが必要」を参照してください。詳細は、SSL/TLS 証明書を使用した概念実証のデプロイメント を参照してください。
上記の要件を満たすことができない場合は、代わりに 2 つ以上の異なる Red Hat Quay のデプロイメントを使用し、リポジトリーミラーリング機能を利用する必要があります。
6.2.1. OpenShift Container Platform での Geo レプリケーションのセットアップ
OpenShift Container Platform で Geo レプリケーションを設定するには、次の手順を実行します。
手順
- Red Hat Quay の postgres インスタンスをデプロイします。
次のコマンドを入力してデータベースにログインします。
psql -U <username> -h <hostname> -p <port> -d <database_name>
quay
という名前で Red Hat Quay のデータベースを作成します。以下に例を示します。CREATE DATABASE quay;
データベース内で pg_trm 拡張機能を有効にします。
\c quay; CREATE EXTENSION IF NOT EXISTS pg_trgm;
Redis インスタンスをデプロイします。
注記- クラウドプロバイダーに独自のサービスが含まれている場合は、Redis インスタンスをデプロイする必要がない可能性があります。
- Builder を利用している場合は、Redis インスタンスをデプロイする必要があります。
- Redis 用の VM をデプロイします。
- Red Hat Quay が実行されているクラスターからアクセスできることを確認します。
- ポート 6379/TCP が開いている必要があります。
インスタンス内で Redis を実行します。
sudo dnf install -y podman podman run -d --name redis -p 6379:6379 redis
- クラスターごとに 1 つずつ、2 つのオブジェクトストレージバックエンドを作成します。1 つのオブジェクトストレージバケットが最初のクラスター (プライマリークラスター) の近くにあり、もう 1 つが 2 番目のクラスター (セカンダリークラスター) の近くにあると理想的です。
- 環境変数のオーバーライドを使用して、同じ設定バンドルでクラスターをデプロイし、個々のクラスターに適切なストレージバックエンドを選択します。
- クラスターへの単一のエントリーポイントを提供するように、ロードバランサーを設定します。
6.2.1.1. Red Hat Quay on OpenShift Container Platform での geo レプリケーションの設定
Red Hat Quay on OpenShift Container Platform の geo レプリケーションを設定するには、次の手順を使用します。
手順
クラスター間で共有される
config.yaml
ファイルを作成します。このconfig.yaml
ファイルには、一般的な PostgreSQL、Redis、ストレージバックエンドの詳細が含まれています。Geo レプリケーションの
config.yaml
ファイルSERVER_HOSTNAME: <georep.quayteam.org or any other name> 1 DB_CONNECTION_ARGS: autorollback: true threadlocals: true DB_URI: postgresql://postgres:password@10.19.0.1:5432/quay 2 BUILDLOGS_REDIS: host: 10.19.0.2 port: 6379 USER_EVENTS_REDIS: host: 10.19.0.2 port: 6379 DATABASE_SECRET_KEY: 0ce4f796-c295-415b-bf9d-b315114704b8 DISTRIBUTED_STORAGE_CONFIG: usstorage: - GoogleCloudStorage - access_key: GOOGQGPGVMASAAMQABCDEFG bucket_name: georep-test-bucket-0 secret_key: AYWfEaxX/u84XRA2vUX5C987654321 storage_path: /quaygcp eustorage: - GoogleCloudStorage - access_key: GOOGQGPGVMASAAMQWERTYUIOP bucket_name: georep-test-bucket-1 secret_key: AYWfEaxX/u84XRA2vUX5Cuj12345678 storage_path: /quaygcp DISTRIBUTED_STORAGE_DEFAULT_LOCATIONS: - usstorage - eustorage DISTRIBUTED_STORAGE_PREFERENCE: - usstorage - eustorage FEATURE_STORAGE_REPLICATION: true
- 1
- ルートには適切な
SERVER_HOSTNAME
を使用する必要があり、グローバルロードバランサーのホスト名と一致する必要があります。 - 2
- OpenShift Container Platform Operator を使用してデプロイされた Clair インスタンスの設定ファイルを取得するには、Clair 設定の取得 を参照してください。
次のコマンドを入力して、
configBundleSecret
を作成します。$ oc create secret generic --from-file config.yaml=./config.yaml georep-config-bundle
各クラスターで、
configBundleSecret
を設定し、QUAY_DISTRIBUTED_STORAGE_PREFERENCE
環境変数のオーバーライドを使用して、そのクラスターに適切なストレージを設定します。以下に例を示します。注記両方のデプロイメント間の
config.yaml
ファイルは一致する必要があります。一方のクラスターに変更を加える場合は、もう一方のクラスターでも変更する必要があります。US クラスター
QuayRegistry
の例apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: georep-config-bundle components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: postgres managed: false - kind: clairpostgres managed: false - kind: redis managed: false - kind: quay managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: usstorage - kind: mirror managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: usstorage
注記SSL/TLS が管理対象であり、ルートが管理対象外であるため、証明書を設定バンドルで直接指定する必要があります。詳細は、TLS およびルートの設定 を参照してください。
ヨーロッパのクラスター
apiVersion: quay.redhat.com/v1 kind: QuayRegistry metadata: name: example-registry namespace: quay-enterprise spec: configBundleSecret: georep-config-bundle components: - kind: objectstorage managed: false - kind: route managed: true - kind: tls managed: false - kind: postgres managed: false - kind: clairpostgres managed: false - kind: redis managed: false - kind: quay managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: eustorage - kind: mirror managed: true overrides: env: - name: QUAY_DISTRIBUTED_STORAGE_PREFERENCE value: eustorage
注記SSL/TLS が管理対象であり、ルートが管理対象外であるため、証明書を設定バンドルで直接指定する必要があります。詳細は、TLS およびルートの設定 を参照してください。
6.2.2. Geo レプリケーションのための複合ストレージ
Red Hat Quay の Geo レプリケーションは、異なる複数のレプリケーションターゲットの使用をサポートしています。たとえば、パブリッククラウドの AWS S3 ストレージとオンプレミスの Ceph ストレージを使用します。これは、すべての Red Hat Quay Pod とクラスターノードからすべてのストレージバックエンドへのアクセスを許可するという重要な要件を複雑にします。そのため、以下を使用することを推奨します。
- 内部ストレージの可視性を防ぐための VPN、または
- Red Hat Quay が使用する特定のバケットへのアクセスのみを許可するトークンペア
これにより、Red Hat Quay のパブリッククラウドインスタンスがオンプレミスのストレージにアクセスできるようになりますが、ネットワークは暗号化され、保護され、ACL を使用するため、セキュリティー要件が満たされます。
これらのセキュリティー対策を実施できない場合は、2 つの異なる Red Hat Quay レジストリーをデプロイし、Geo レプリケーションの代わりにリポジトリーミラーリングを使用することが推奨されます。