6.2. geo-replication


地理复制允许多个地理分散的 Red Hat Quay 部署,从客户端或用户的角度来看,作为单个 registry 工作。它显著提高了全局分布式 Red Hat Quay 设置中的推送和拉取性能。镜像数据会在后台异步复制,为客户端进行透明故障转移和重定向。

在独立和 Operator 部署中支持部署带有异地复制的 Red Hat Quay。

6.2.1. 异地复制功能

  • 配置异地复制后,容器镜像推送将写入该 Red Hat Quay 实例的首选存储引擎。这通常是区域内最接近的存储后端。
  • 在初始推送后,镜像数据将在后台复制到其他存储引擎。
  • 复制位置列表可以配置,它们可以是不同的存储后端。
  • 镜像拉取将始终使用最接近的可用存储引擎,以最大化拉取性能。
  • 如果复制尚未完成,拉取将使用源存储后端。

6.2.2. 地理复制要求和约束

  • 在地理复制设置中,Red Hat Quay 要求所有区域都可以读取和写入所有其他区域的对象存储。对象存储必须可以被所有其他区域访问。
  • 如果一个地理复制站点的对象存储系统失败,该站点的 Red Hat Quay 部署必须被关闭,以便客户端由全局负载均衡器重定向到具有完整存储系统的剩余站点。否则,客户端将遇到拉取和推送失败。
  • Red Hat Quay 没有内部感知连接的对象存储系统的健康状态或可用性。用户必须配置全局负载均衡器(LB)来监控分布式系统的健康状况,并根据存储状态将流量路由到不同的站点。
  • 要检查 geo-replication 部署的状态,您必须使用 /health/endtoend 检查点,该检查点用于全局健康监控。您必须使用 /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 证书和密钥。如需更多信息,请参阅 * Geo-Replication 需要 SSL/TLS 证书和密钥。如需更多信息,请参阅使用 SSL/TLS 证书部署概念验证

如果无法满足上述要求,您应该使用两个或多个 Red Hat Quay 部署,并利用存储库镜像功能。

6.2.3. 使用独立 Red Hat Quay 进行地域复制

在以下镜像中,Red Hat Quay 在两个独立的区域独立运行,具有通用数据库和一个通用的 Redis 实例。本地化镜像存储在每个地区提供,镜像拉取(pull)是从最接近的可用存储引擎中提供的。容器镜像推送将写入 Red Hat Quay 实例的首选存储引擎,然后在后台复制到其他存储引擎。

注意

如果 Clair 在一个集群中失败,例如 US 集群,US 用户在 Red Hat Quay for the第二个集群(EU)中不会看到漏洞报告。这是因为所有 Clair 实例都具有相同的状态。当 Clair 失败时,这通常是因为集群中的一个问题。

地理复制架构

Geo-replication

6.2.4. 使用 Red Hat Quay Operator 进行地域复制

Geo-replication architecture

在上例中,Red Hat Quay Operator 部署到两个独立的区域,具有通用数据库和一个通用的 Redis 实例。本地化镜像存储在每个地区提供,镜像拉取(pull)是从最接近的可用存储引擎中提供的。容器镜像推送将写入 Quay 实例的首选存储引擎,然后在后台复制到其他存储引擎。

因为 Operator 现在单独管理 Clair 安全扫描程序及其数据库,所以可以使用 geo-replication setup,以便不管理 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,并使用存储库镜像作为异地复制的替代选择。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.