![screenshot]( "screenshot")
本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周一、三、五 与您不见不散！
前情回顾
此参考架构将帮助您规划大规模 Docker 企业版部署。它涉及核心 Docker EE 平台、Universal Control Plane 以及 Docker Trusted Registry。请使用本指南来帮助确定 Docker EE 部署的硬件和基础架构规模，并确定针对您的具体工作负载的最佳配置。点击以下标题，回顾第一部分内容：
Docker Trusted Registry
本节论述用于实现扩展和性能的 Docker Trusted Registry 配置。
----
存储驱动
Docker Trusted Registry 支持种类繁多的存储后端。就扩展而言，后端类型可以分为基于文件系统（NFS、绑定式挂载、存储卷）和基于云/blob（AWS S3、Swift、Azure Blob Storage、Google Cloud Storage）。
对于某些用途而言，基于云/blob 的存储比基于文件系统的存储更有利于提高性能。这是因为 DTR 可以将层 GET 请求从客户端直接重定向到后备存储。通过这一操作，由 Docker 客户端拉取的实际镜像内容就不必通过 DTR 传输，而是可由 Docker 客户端从后备存储直接获取（只要 DTR 已经获取元数据并检查凭证）。
在使用基于文件系统的存储（例如 NFS）时，要确保 DTR 性能不受基础架构约束。常见的瓶颈包括主机网络接口卡、随 DTR 部署的负载均衡器、后端存储系统的吞吐量 (IOPS) 和延迟，以及 DTR 从节点主机的 CPU/内存。
Docker 已经测试过 DTR 性能，确定它可以使用带有 3 个从节点的 NFS 后备存储，处理 1 GB 容器镜像的 1400 多个并发拉取。
总计存储
了解未来镜像存储总计要求的最佳办法是收集和分析下列数据：
- 镜像平均大小
- 镜像更新/推送的频率
- 镜像更新大小的平均大小（要考虑许多镜像可能共享通用基础层）
- 存储旧镜像工件的保留策略和要求
使用 Docker Trusted Registry 垃圾回收结合（使用 DTR API）删除旧镜像的脚本或其他自动化工具，保持对存储使用的控制。
存储性能
当许多开发人员或构建机器同时向 Docker Trusted Registry 推送镜像时，DTR 写负载很可能会高涨。
当新的镜像版本推送到 DTR，然后部署到有许多拉取更新镜像的实例的大型 Docker EE 集群，读负载很可能会高涨。
如果同样的 DTR 集群实例既用于开发人员/构建服务器工件存储，也用于大型生产 Docker EE UCP 集群的生产镜像工件存储，那么 DTR 集群实例就将同时遇到高涨的写负载和读负载。对于规模非常大的部署，请考虑使用两个（或更多）DTR 集群 - 一个专门用于支持写入镜像的开发人员和构建服务器，另一个可以处理由生产部署造成的非常高的瞬时读负载。
在估算 DTR 性能要求，请考虑平均镜像大小和镜像更新大小，将对 DTR 设置进行推送和拉取的开发人员和构建服务器数量，以及将在部署期间并发拉取更新镜像的生产节点数量。确保您有足够的 DTR 实例，而且您的后备存储有足以处理峰值负载的读写吞吐量。
要增加镜像拉取吞吐量，请考虑使用 DTR 缓存作为添加更多从节点的替代方法。
从节点数量
Docker Trusted Registry 维持法定多数的从节点，它们存储关于镜像仓库、镜像、标签和其他 DTR 对象的元数据。3 个从节点是实现高可用性部署的最低从节点数。1 个从节点的部署应该仅用于测试和试验。
当使用多个 DTR 从节点时，要配置负载均衡器，使请求能够分布到所有 DTR 从节点。
如果一个 DTR 集群有 5 个或 7 个从节点，它提交元数据更新（例如镜像推送或标签更新）所花的时间可能长于有 3 个从节点的集群，因为它要花更多时间使更新传播到更大的法定多数。
如果使用 DTR 安全扫描，请注意 DTR 将对每个 DTR 从节点最多运行一个并发扫描。添加更多 DTR 从节点（或更改到配有速度更快的硬件的从节点）将增加 DTR 扫描吞吐量。请注意，当前在更新漏洞数据库之后，DTR 不会重新扫描存储的镜像。如果更新大量镜像，极有可能导致队列中积压众多扫描。
总的来说，您可能需要考虑使用 3 个以上 DTR 从节点以实现：
- 在基于 NFS 的设置上超过 3 个从节点处理能力的峰值镜像推送/拉取吞吐量
- 超过 3 个并发镜像漏洞扫描
- 发生 1 个以上瞬时 DTR 从节点故障时的耐用性
元数据大小和集群操作
Docker Trusted Registry 将关于镜像仓库、镜像、标签和其他对象的元数据存储在数据库中（用户数据由 Universal Control Plane 维护）。您可以通过检查 dtr-rethink 容器中 /data 目录的大小来确定 DTR 数据库的大小。
完成从节点连接、备份和还原等 DTR 集群操作所需的时间由 DTR 保存的元数据数量决定。
集群大小
如果您正在规划将由多个团体或业务单位使用的大型 Docker EE 部署，应该考虑是运行单个集群还是多个集群（例如每个业务单位一个集群）。两种选项都是可行的，但是通常来说，使用一个或少数几个集群可以让您获得更大的整合效益。
Docker 企业版拥有强大的基于团队的多租户控制功能，包括指定工作节点仅运行由特定团队创建的任务和服务。如果使用这些功能配合单个或少数几个集群，就可以让多个业务单位或团体使用 Docker 企业版，而不必承担配置和运行多个集群的开销。
即便如此，使用多个集群仍有很好的理由：
- 存储：即使对规模较小的部署而言，将非生产集群与生产集群分隔也是个好主意。这样就可以先对关键更改和更新进行隔离测试，然后再部署到生产中。如果存在许多阶段（测试、QA、数据移动、生产等），还可以进行更细的划分。
- 团队或应用分隔：Docker EE 基于团队的多租户控制允许多个应用安全地在同一个集群中运行，但如果安全要求较为严格，可能就必须分隔集群。
- 区域：区域冗余性、合规法律或延迟都可以成为将工作负载分到多个集群中的理由。
同样的考虑也适用于规划要使用的 DTR 集群数量。请注意，含有 Universal Control Plane 和 DTR 的 Docker EE 当前仅限于在 UCP 和 DTR 集群实例之间进行一对一映射，但多个 UCP 集群可以共享一个 DTR 集群，只是有一些功能限制。
总 结
在规划 Docker EE 部署时考虑扩展需求，将有助于在工作负载增长时维持最佳性能、充足的磁盘空间，等等。而且您还能够以零或极少的停机时间执行更新。使用本指南进行大规模 Docker 企业版部署的规划和架构设计时，还应考虑 Docker EE 最佳实践与设计注意事项中的建议。
