出品丨Docker公司（ID：docker-cn）
编译丨小东
每周一、三、五晚6点10分 与您不见不散
前情回顾
此参考架构将帮助您规划大规模 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 最佳实践与设计注意事项中的建议。
点击下列标题，阅读更多干货
如果本文对你有帮助，欢迎分享到朋友圈！获取更多Docker实用技巧，扫描下图二维码！