规划部署

本主题提供了在 Alauda Container Platform (ACP) 上部署 Ceph 分布式存储的规划检查清单。其中总结了架构选择、安全选项、基础设施规模、网络限制和灾难恢复注意事项,帮助您在实际安装前确定部署模型。

有关产品背景,请参阅简介和架构。有关部署步骤,请参阅安装和操作指南下的文档。

如果集群运行在 Immutable Infrastructure 上,请先查看 关于不可变基础设施,然后在安装前阅读在不可变基础设施上部署的先决条件,并使用该页面中的提供商链接规划磁盘和节点替换。

部署架构

ACP 分布式存储基于 Ceph 和 Rook。在较高层次上,该平台结合了以下层:

  • Ceph 守护进程,例如 MON、MGR、OSD、MDS 和 RGW,用于提供块、文件和对象存储功能
  • Rook 和 CSI 组件,用于自动执行部署、置备、扩展和生命周期管理
  • ACP 平台集成,用于提供存储池、可观测性和运维入口

在部署之前,请确定您的环境应使用本地集群中的存储服务,还是使用外部 Ceph 环境中的存储服务。

内部和外部部署模型

您可以通过以下任一方式规划 ACP 分布式存储:

部署模式存储服务运行位置存储集群管理者最适用场景主要权衡
内部,共享节点Ceph 组件运行在同时承载业务工作负载的 ACP 工作节点上ACP 平台团队或集群管理员早期阶段的环境、裸金属集群,或尚未完全明确存储需求的场景推出更简单,但应用与存储之间更可能发生资源争用
内部,专用节点Ceph 组件运行在同一 ACP 集群内的专用存储或基础设施节点上ACP 平台团队或集群管理员存储需求可预测且隔离要求更严格的生产环境运维隔离和规模控制更佳,但需要预留更多节点并进行容量规划
外部ACP 使用外部 Ceph 环境中的存储类独立的存储团队、SRE 团队或现有外部存储所有者大规模环境、多个使用者集群,或已运行独立 Ceph 集群的组织所有权边界清晰,但需要进行更多跨集群网络、身份验证和依赖关系管理

内部部署更易于推出和管理,因为存储服务与使用这些服务的工作负载都在同一 ACP 环境中进行规划。在内部部署中,首要的设计选择是存储是否应与业务工作负载共享节点,还是使用专用节点。当您需要在存储集群与应用集群之间实现更强的隔离,或者多个业务集群需要共享同一存储后端时,外部部署更为合适。

主要规划决策点如下:

  • 如果希望更快推出,并且能够接受存储工作负载与应用工作负载共享同一工作节点池,请选择共享节点部署。
  • 如果存储需求已知,并且希望实现更清晰的容量控制、故障隔离和维护边界,请选择专用节点部署。
  • 如果存储已在其他位置进行管理,或者单个外部集群必须为多个 ACP 集群提供服务,请选择外部部署。

节点角色

规划节点放置时,请分离控制平面节点、基础设施节点和工作节点的职责:

  • 控制平面节点负责维护集群管理功能,除非部署模型明确支持,否则不应将其视为通用存储节点。
  • 如果希望将存储平台组件与业务工作负载隔离,基础设施节点是合适的选择。
  • 工作节点可以在共享节点部署中承载存储服务,但这会增加应用与存储守护进程之间的资源争用。

对于生产环境,为实现高可用存储服务,请至少规划三个故障域。应尽可能将存储节点分布在不同机架、区域或主机组中。

安全注意事项

在部署之前,请确认存储设计是否需要传输加密,并在启用之前评估其运维影响。

存储类加密

您可以使用存储类加密对持久卷(仅限块存储)进行加密,并使用外部密钥管理系统(KMS)存储设备加密密钥。持久卷加密仅适用于 RADOS Block Device(RBD)持久卷。请参阅如何创建启用持久卷加密的存储类。

Alauda Build of Rook-Ceph 同时支持 HashiCorp Vault KMS 和 Thales CipherTrust Manager KMS 的存储类加密。

传输加密

ACP 当前支持对 Ceph 分布式存储进行传输加密。此功能可保护 Ceph 组件与客户端之间的流量,通常围绕 Ceph msgr2 和集群网络模型进行规划。

在启用传输加密之前,请验证:

  • 存储节点和客户端节点上的内核及操作系统支持情况
  • 繁忙存储节点的预期 CPU 开销
  • 对目标硬件的吞吐量和延迟影响

有关实施详情,请参阅配置传输加密。

基础设施要求

最低和推荐配置

在创建集群之前,请规划节点数量、存储设备和可用资源。

项目最低配置推荐配置
存储节点3 个节点4 个或更多节点,分布在不同故障域中
存储设备每个节点 1 个可用存储设备每个节点配备多个专用设备,且类型和大小保持一致
节点分布3 个可用于承载 Ceph 服务的节点3 个故障域,例如机架或区域
设备使用系统磁盘与存储磁盘分离为 Ceph 数据使用专用裸磁盘,并为未来扩展预留空间

集群至少应包含三个节点,并且每个节点上都有一个可用的存储设备。对于生产环境,应将集群部署在至少三个故障域中,并预留足够的可用资源,以应对重新平衡、修复和未来增长。

资源规划

Ceph 存储服务会持续消耗 CPU、内存和设备容量。请首先为存储守护进程规划资源,然后为恢复、重新平衡、升级和后台任务预留额外空间。

作为基准:

  • 高可用集群至少从三个存储节点开始
  • 为 MON、MGR、OSD 以及任何已启用的 MDS 或 RGW 服务预留足够的 CPU 和内存
  • 为新存储池、额外设备和集群恢复事件预留增长空间
  • 避免规划在初始阶段就接近饱和的集群

如果设计使用专用存储节点,资源规划会更加可预测。如果存储与业务工作负载共同运行,请预留额外空间,以应对峰值负载和节点故障期间的资源争用。

集群总体规划预算

在早期规划阶段,应从集群总体预算入手,而不是仅依据各组件的单独数值。下表用于为四节点高可用集群提供工作负载特定调优之前的规划参考:

部署模式为存储预留的总 CPU为存储预留的总内存说明
内部,最低基线32 个逻辑 CPU96 GiB仅满足最低部署目标时,四节点规划的入门级基线
内部,标准基线40 个逻辑 CPU96 GiB更适合作为常规生产规划和未来扩展的起点
内部,面向性能的基线60 个逻辑 CPU128 GiB适用于从一开始就需要更高吞吐量或更低延迟的场景
外部使用者集群仅根据连接性和客户端访问进行规划仅根据连接性和客户端访问进行规划存储守护进程在 ACP 集群外运行,因此 ACP 集群主要需要网络可达性、凭据和客户端侧容量

这些数值应视为集群级规划目标,而不是精确的调度器预留值。若要估算四节点集群的每节点预算,请将总体数值平均分配到参与其中的存储节点。

以下建议适用于早期规划:

组件推荐 CPU推荐内存
MON2 个核心3 GiB
MGR3 个核心4 GiB
MDS3 个核心8 GiB
RGW2 个核心4 GiB
OSD4 个核心8 GiB

这些数值是规划参考,而不是严格的调度保证。实际需求取决于设备数量、已启用的服务和工作负载强度。

如何估算集群大小

调整集群规模时,请按以下顺序进行:

  1. 选择部署模式:共置、专用节点或外部部署。
  2. 确定最小节点数量和故障域布局。
  3. 确定是否需要块、文件、对象或混合存储服务。
  4. 从集群总体规划预算开始。
  5. 为额外设备集、恢复、监控和预期增长增加预留空间。

如果同时需要文件和对象服务,或者集群将同时承载繁重的业务工作负载,请将规模设置在最低基线之上,而不是直接采用最低基线。

Pod 放置

Pod 放置规则会直接影响韧性。请按以下方式规划集群:

  • 将高可用组件分散到不同故障域中
  • 确保每个故障域都有可访问的存储设备和足够的可分配资源
  • 确保新增设备集或未来扩展仍可遵循相同的放置模式

实际上,仅拥有三个节点并不足够。节点还需要以避免单个机架、主机组或区域成为单点故障的方式进行分布。

存储设备规划

选择存储设备时,应尽可能统一设备大小和类别。混合设备会增加性能调优和容量规划的复杂性。

请遵循以下原则:

  • 为操作系统预留一个系统磁盘,并为 Ceph 数据单独配置存储设备
  • 优先使用裸磁盘或专用设备,而不是对共享磁盘进行分区
  • 将每个节点上的设备数量控制在易于管理的范围内,以便恢复和维护保持可行
  • 跟踪可用容量而不是原始容量,因为副本会降低有效存储空间

容量规划还应包括告警阈值和扩展策略。请在集群接近满容量之前规划扩展。接近满容量运行会增加重新平衡压力,并使恢复更加困难。

有关相关运维指南,请参阅管理存储池和添加设备/设备类别。

容量规划

规划集群容量时,请计算可用容量而不是原始磁盘容量。在副本 Ceph 部署中,部分原始存储始终会用于数据保护。

请遵循以下规划原则:

  • 让可用容量领先于预期业务增长,而不是等到集群几乎已满后再扩展
  • 为恢复、重新平衡、快照和数据使用量的临时突增预留额外空间
  • 在节点和故障域之间以均衡的方式扩展存储,避免新增容量导致利用率不均
  • 在向集群添加新工作负载之前,同时检查当前利用率和预计增长

以下示例可作为早期规划参考,适用于三个节点、每个节点一个设备且采用 3 副本数据保护策略的集群:

每个节点的设备大小集群原始容量采用 3 个副本时的大致可用容量
0.5 TiB1.5 TiB0.5 TiB
2 TiB6 TiB2 TiB
4 TiB12 TiB4 TiB

这些数值仅为示例。可用容量会因实际数据保护策略而异,不应将其视为适用于每种集群设计的一般规则。

在日常运维中,应在集群达到警告级别之前检查容量。如果增长可预测,请提前扩展,而不要等到接近满容量或已满时再进行扩展。

网络要求

Ceph 对网络质量较为敏感。在部署之前,请验证以下内容:

  • 集群网络能够为复制和恢复流量提供稳定的吞吐量
  • 故障域之间的延迟处于所选部署模型支持的范围内
  • 存储节点与使用存储的集群之间已开放所需端口
  • 任何专用网络设计(例如基于 Multus 的网络隔离)都已提前确定

如果计划将存储流量与常规原生应用流量隔离,请在部署之前确认网络接口、路由策略和运维归属。网络隔离可以提升安全性和性能,但也会增加设计复杂性。

IPv6 支持

ACP 分布式存储规划必须遵循为平台选择的集群网络协议栈。

  • 单栈 IPv6 环境支持 IPv6。
  • 在部署存储之前,必须根据 ACP 集群网络设计验证双栈规划。
  • 存储节点和客户端节点应采用相同的地址族策略,以避免连接和服务发现问题。

如果环境使用 IPv6,请在安装之前确认以下内容:

  • ACP 集群网络已配置为支持 IPv6
  • 所有存储节点都可以通过所需的 IPv6 路由进行通信
  • 访问存储端点的监控、告警和外部集成也支持 IPv6

IPv6 应被视为安装时的架构决策。不要假设现有的面向 IPv4 的存储设计可以在之后转换,而无需重新验证。

灾难恢复规划

ACP 分布式存储可以根据不同的恢复目标进行规划。请根据恢复点目标(RPO)、恢复时间目标(RTO)和站点拓扑选择模型。

Regional-DR

ACP 支持 Regional-DR,适用于跨地域或跨站点灾难恢复场景,其中异步复制和少量潜在数据丢失是可接受的。

规划 Regional-DR 时,请提前确认以下事项:

  • 源集群和目标集群具有兼容的存储和网络设计
  • 复制延迟和故障转移预期符合业务恢复目标
  • 受保护的工作负载类型明确,例如块数据、文件系统或对象数据

有关实施详情,请参阅灾难恢复。

Stretch Cluster

仅当站点之间的延迟受到严格控制,且拓扑专门针对这种模式进行设计时,Stretch Cluster 才适用。通常应规划以下内容:

  • 两个数据站点和一个仲裁或仲裁器站点
  • 跨三个区域至少五个节点
  • 在创建集群之前手动设置明确的故障域标签
  • 每个数据站点具有足够的节点,以维持存储服务的可用性
  • 区域间延迟保持在低延迟设计范围内,通常数据站点之间的 RTT 不超过 10 ms
WARNING

不要将 Stretch Cluster 视为适用于长距离、高延迟、多数据中心部署的通用解决方案。如果站点间延迟未受到严格控制,请改用专用的灾难恢复架构。

有关 ACP 特定的 Stretch Cluster 部署指南,请参阅创建 Stretch 类型集群。

性能规划

性能规划应基于工作负载特征,而不仅仅是原始设备数量。在部署之前,请确定:

  • 主要工作负载属于块、文件还是对象类型
  • 工作负载是对延迟敏感、对吞吐量敏感,还是容量需求较大
  • 热数据、备份流量或分析作业是否会占据集群的主要资源

此外,请确认是否需要进行特殊调优或针对特定功能进行设计。例如,对象工作负载可能需要单独规划网关容量,而某些环境可能需要面向缓存或专用集群的设计。

后续步骤

完成规划后,请继续参阅与所选部署模型匹配的部署指南:

内部部署

外部部署

相关后续配置