6.2. geo-replication
目前,IBM Power 不支持 geo-replication 功能。
地理复制允许多个地理分布的 Red Hat Quay 部署从客户端或用户的角度来看作为单个 registry 工作。它显著提高了在全局分布式 Red Hat Quay 设置中的推送和拉取性能。镜像数据在后台异步复制,并带有透明故障转移,并为客户端重定向。
在独立和 Operator 部署中支持部署带有 geo-replication 的 Red Hat Quay。
6.2.1. 地域复制功能
- 配置 geo-replication 后,容器镜像推送将写入该 Red Hat Quay 实例的首选存储引擎。这通常是区域内最接近的存储后端。
- 在初始推送后,镜像数据将在后台复制到其他存储引擎。
- 复制位置列表可以配置,它们可以是不同的存储后端。
- 镜像拉取(pull)将始终使用最接近的可用存储引擎来最大化拉取性能。
- 如果复制还没有完成,则拉取将使用源存储后端。
6.2.2. 地域复制要求和限制
- 在地理复制设置中,Red Hat Quay 要求所有区域都可以读取和写入所有其他区域的对象存储。对象存储必须可以被所有其他区域访问。
- 如果一个地理复制站点的对象存储系统失败,该站点的 Red Hat Quay 部署必须被关闭,以便客户端由全局负载均衡器重定向到具有完整存储系统的剩余站点。否则,客户端将遇到拉取和推送失败。
- Red Hat Quay 没有内部感知连接的对象存储系统的健康状态或可用性。用户必须配置一个全局负载均衡器(LB),以监控分布式系统的健康状况,并根据存储状态将流量路由到不同的站点。
-
要检查 geo-replication 部署的状态,您必须使用
/health/endtoend
checkpoint,该检查点用于全局健康监控。您必须使用/health/endtoend
端点手动配置重定向。/health/instance
端点仅检查本地实例健康状况。 - 如果一个站点的对象存储系统不可用,则其余站点或站点没有自动重定向到剩余的存储系统或系统。
- 地理复制(geo-replication)是异步的。如果一个站点永久丢失,则已存储在该站点的对象存储系统中,但在失败时还没有复制到剩余的站点的数据会丢失。
单个数据库(因此所有元数据和 Red Hat Quay 配置)在所有区域之间共享。
地理复制不会复制数据库。如果出现停机,启用了地理复制功能的 Red Hat Quay 不会切换到另一个数据库。
- 单个 Redis 缓存在整个 Red Hat Quay 设置间共享,需要可以被所有 Red Hat Quay pod 访问。
-
完全相同的配置应该在所有区域间使用,但存储后端除外,该配置也可以使用
QUAY_DISTRIBUTED_STORAGE_PREFERENCE
环境变量明确配置。 - 地理复制需要每个区域中的对象存储。它不适用于本地存储。
- 每个区域必须能够访问每个区域中的每个存储引擎,这需要一个网络路径。
- 或者,可以使用存储代理选项。
- 整个存储后端(如所有 blob)都会被复制。相反,存储库镜像可以限制为存储库或镜像。
- 所有 Red Hat Quay 实例都必须共享相同的入口点,通常通过负载均衡器。
- 所有 Red Hat Quay 实例都必须具有相同的超级用户集合,因为它们在通用配置文件中定义。
-
地理复制要求您的 Clair 配置设置为
unmanaged
。非受管 Clair 数据库允许 Red Hat Quay Operator 在地理复制环境中工作,其中多个 Red Hat Quay Operator 实例必须与同一数据库通信。如需更多信息,请参阅高级 Clair 配置。 - geo-Replication 需要 SSL/TLS 证书和密钥。如需更多信息,请参阅使用 SSL/TLS 保护到 Red Hat Quay 的连接。
如果无法满足上述要求,您应该使用两个不同的 Red Hat Quay 部署,并利用存储库镜像功能。
6.2.3. 使用独立 Red Hat Quay 的 geo-replication
在以下镜像中,Red Hat Quay 在两个不同的区域(带有通用数据库和一个通用的 Redis 实例)中运行独立运行。本地化镜像存储在每个地区提供,镜像拉取则从最接近的可用存储引擎提供。容器镜像推送将写入 Red Hat Quay 实例的首选存储引擎,然后在后台将复制到其他存储引擎。
如果 Clair 在一个集群中失败,例如 US 集群,则 US 用户不会在 Red Hat Quay 中为第二个集群(EU)看到漏洞报告。这是因为所有 Clair 实例都有相同的状态。当 Clair 失败时,这通常是由于集群中的问题。
地域复制架构
6.2.4. 使用 Red Hat Quay Operator 的 geo-replication
在上例中,Red Hat Quay Operator 部署到两个单独的区域,它们有一个通用数据库和一个通用的 Redis 实例。本地化镜像存储在每个地区提供,镜像拉取则从最接近的可用存储引擎提供。容器镜像推送将写入 Quay 实例的首选存储引擎,然后在后台将复制到其他存储引擎。
由于 Operator 现在单独管理 Clair 安全扫描程序及其数据库,因此可以利用异地复制设置,使其不管理 Clair 数据库。取而代之,需要使用外部共享数据库。Red Hat Quay 和 Clair 支持多个 PostgreSQL 供应商和供应商,它们可在 Red Hat Quay 3.x 测试列表中找到。另外,Operator 还支持可注入部署的自定义 Clair 配置,允许用户使用外部数据库的连接凭证配置 Clair。
6.2.5. 地域复制的混合存储
Red Hat Quay geo-replication 支持使用不同和多个复制目标,例如,在公共云中使用 AWS S3 存储并在内部使用 Ceph 存储。这与授予对所有 Red Hat Quay Pod 和集群节点中所有存储后端的访问权限的关键要求。因此,建议您使用以下内容:
- VPN 以防止内部存储可见性,或者
- 允许访问 Red Hat Quay 使用的指定存储桶的令牌对
这会导致 Red Hat Quay 的公共云实例可以访问内部存储,但网络会被加密、保护并将使用 ACL,从而满足安全要求。
如果您无法实现这些安全措施,则最好部署两个不同的 Red Hat Quay registry,并使用存储库镜像作为地理复制的替代选择。