이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 7. Geo-replication
Geo-replication lets multiple geographically distributed Red Hat Quay deployments work as a single registry from the client perspective. This improves push and pull performance in globally distributed setups and provides transparent failover and redirect for clients.
Geo-replication is supported on standalone and Operator-based deployments.
7.1. Troubleshooting geo-replication for Red Hat Quay 링크 복사링크가 클립보드에 복사되었습니다!
To troubleshoot geo-replication for {product-title} and resolve replication issues, you can use the procedures in the following sections. These procedures enable you to identify and fix problems with geo-replication deployments.
7.1.1. Checking data replication in backend buckets 링크 복사링크가 클립보드에 복사되었습니다!
To ensure that your {product-title} data is properly replicated in all backend buckets, you can use the aws CLI to list objects in the bucket. Run aws s3 ls with --recursive, --human-readable, and --summarize to verify replication.
Prerequisites
-
You have installed the
awsCLI.
Procedure
Enter the following command to ensure that your data is replicated in all backend buckets:
aws --profile quay_prod_s3 --endpoint=http://10.0.x.x:port s3 ls ocp-quay --recursive --human-readable --summarize
$ aws --profile quay_prod_s3 --endpoint=http://10.0.x.x:port s3 ls ocp-quay --recursive --human-readable --summarizeCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Total Objects: 17996 Total Size: 514.4 GiB
Total Objects: 17996 Total Size: 514.4 GiBCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.2. Checking the status of your backend storage 링크 복사링크가 클립보드에 복사되었습니다!
To check the status of your {product-title} backend storage and verify access, you can use provider dashboards and CLIs for AWS, GCS, NooBaa, ODF, Ceph, Azure, or OpenStack Swift. Ensure all {product-title} instances have access to all S3 storage backends.
-
Amazon Web Service Storage (AWS). Check the AWS S3 service health status on the AWS Service Health Dashboard. Validate your access to S3 by listing objects in a known bucket using the
awsCLI or SDKs. - Google Cloud Storage (GCS). Check the Google Cloud Status Dashboard for the status of the GCS service. Verify your access to GCS by listing objects in a known bucket using the Google Cloud SDK or GCS client libraries.
- NooBaa. Check the NooBaa management console or administrative interface for any health or status indicators. Ensure that the NooBaa services and related components are running and accessible. Verify access to NooBaa by listing objects in a known bucket using the NooBaa CLI or SDK.
- Red Hat OpenShift Data Foundation. Check the OpenShift Container Platform Console or management interface for the status of the Red Hat OpenShift Data Foundation components. Verify the availability of Red Hat OpenShift Data Foundation S3 interface and services. Ensure that the Red Hat OpenShift Data Foundation services are running and accessible. Validate access to Red Hat OpenShift Data Foundation S3 by listing objects in a known bucket using the appropriate S3-compatible SDK or CLI.
- Ceph. Check the status of Ceph services, including Ceph monitors, OSDs, and RGWs. Validate that the Ceph cluster is healthy and operational. Verify access to Ceph object storage by listing objects in a known bucket using the appropriate Ceph object storage API or CLI.
- Azure Blob Storage. Check the Azure Status Dashboard to see the health status of the Azure Blob Storage service. Validate your access to Azure Blob Storage by listing containers or objects using the Azure CLI or Azure SDKs.
- OpenStack Swift. Check the OpenStack Status page to verify the status of the OpenStack Swift service. Ensure that the Swift services, like the proxy server, container servers, object servers, are running and accessible. Validate your access to Swift by listing containers or objects using the appropriate Swift CLI or SDK.
After checking the status of your backend storage, ensure that all Red Hat Quay instances have access to all s3 storage backends.