在本系列文章中,我们将通过详细的实践案例,指导大家如何配置和优化Ceph对象存储解决方案中最核心的复制功能。我们将重点介绍Reef版本中新增的多站点复制增强特性,帮助用户构建更强大、更可靠的分布式存储系统。
本系列文章将涵盖以下核心主题:
- Ceph对象存储多站点复制入门——深入解析多站点复制的基本概念和核心价值
- Ceph对象多站点架构与配置指南——详细讲解系统架构设计原理与最佳实践配置方案
- Reef版本性能优化:复制同步公平性——重点介绍新版本在复制性能方面的突破性改进
- RGW服务负载均衡:Ceph Ingress服务部署——手把手指导如何实现高可用、高性能的服务部署
- Ceph对象多站点同步策略——深入探讨灵活高效的同步策略配置方案
- Ceph对象存储归档区域——全面解析归档存储的最佳实践与实施方法
在数据保护领域,复制、灾难恢复、备份和恢复策略的选择直接影响着业务连续性。不同的策略对应着不同的服务级别协议(SLA),特别是在恢复时间目标(RTO)和恢复点目标(RPO)方面表现出显著差异。
以复制策略为例,同步复制能够实现最低的RPO,理论上可以达到零数据丢失。Ceph通过跨数据中心的集群扩展能力,能够实现高效的站点间同步复制。相比之下,异步复制虽然接受非零RPO,但在大规模分布式场景下展现出更好的扩展性和成本效益。
Ceph为每种存储模式(对象、块和文件)都提供了专门的异步复制机制。其中,对象存储的异步多站点复制通过将数据跨集群复制,为地理分布式部署提供了强大的支持。本系列文章将重点探讨对象存储的多站点异步复制方案,解析其在分布式环境下的最佳实践。
一、Ceph 对象存储多站点复制
在深入技术细节之前,让我们先概览Ceph对象存储(RGW)的核心能力:它提供了一套成熟完善的企业级地理复制解决方案。RGW的多站点复制机制支持跨区域部署,无论是单一区域还是多区域架构,都能实现高效的异步对象复制。得益于异步复制和最终一致性模型的设计,Ceph对象存储能够在广域网(WAN)环境下保持卓越的性能表现。
Ceph 对象存储多站点复制为企业带来了显著优势,尤其是那些需要跨多个地理位置存储和管理海量数据的企业。以下是其主要优势:
提高数据可用性,多区域支持
Ceph对象存储支持地理分布式集群部署,显著提升数据可用性。通过最终一致性模型的异步复制机制,有效规避硬件故障、自然灾害等风险,同时无需严格网络延迟要求,确保业务连续性。
Active/Active复制架构
采用Active/Active复制架构,支持多终端用户就近访问。用户可通过最近的RGW(S3)端点进行并发读写操作,实现数据双向同步。这种设计不仅提升了数据访问速度,还大幅降低了系统停机风险。
值得注意的是,只有区域组中指定的主区域接受元数据更新。例如,在创建用户和存储桶时,非主区域上的所有元数据修改都将转发到配置的主区域。如果主节点发生故障,则必须触发手动主区域故障转移。
弹性扩展能力
多站点复制架构赋予系统卓越的扩展性。企业可根据业务需求灵活添加新站点或集群,实现存储基础设施的无缝扩展,完全规避容量瓶颈和性能限制。
Realm, Zonegroups 以及 Zones
Ceph 对象存储多站点集群由领域(Realm), 区域组(Zonegroup) 以及 区域(Zone) 组成:
- Realm定义了跨多个Ceph存储集群的全局命名空间,确保在整个分布式系统中的对象标识唯一性。
- 每个Zonegroup可以包含一个或多个zone,作为逻辑分组单元,管理特定地理范围内的存储资源。
- zones是Ceph多站点配置的最小单元,由单个Ceph集群内的一个或多个对象网关(RGW)组成,负责具体的存储操作和数据服务。
如下图所示,Ceph对象存储的多站点复制发生在Zone级别。在一个典型的配置中,我们拥有一个全局Realm和多个Zonegroup。Realm级别的全局对象命名空间确保了跨Zonegroup和Zone的对象ID唯一性。
每个存储桶由其创建时所在的Zonegroup拥有,其对象数据仅会复制到该Zonegroup的其他区域。当其他Zonegroup接收到该存储桶的数据请求时,系统会自动将请求重定向到存储桶所在的Zonegroup进行处理。
在Ceph对象存储集群中,您可以配置一个或多个独立的领域(Realm)。每个领域都是一个自包含的全局对象命名空间,这意味着:
- 每个领域都维护着独立的用户、存储桶和对象集合
- 同一领域内不允许存在同名存储桶
- 领域之间完全隔离,互不影响
Ceph对象存储还提供了租户(Tenant)概念,用于实现S3命名空间的进一步隔离。虽然租户机制不在本系列讨论范围内,但可以通过官方文档深入了解这一特性。
如图所示,我们展示了一个典型的多领域配置场景。两个独立的领域分别拥有自己的区域组和复制区域,形成了完全隔离的命名空间体系。这种架构设计为不同业务单元或客户群体提供了安全的数据隔离方案。
每个区域代表一个 Ceph 集群,一个区域组中可以有一个或多个区域。配置后,多站点复制将在区域之间进行。在本系列博客中,我们将仅在一个区域组中配置两个区域,但可以在单个区域组中配置更多数量的复制区域。
Ceph 多站点复制策略
Ceph对象存储新版本引入了革命性的"多站点同步策略",实现了细粒度的存储桶级别复制控制。这一创新特性为用户带来了前所未有的灵活性和成本优化空间,同时解锁了多项关键复制功能:
核心功能亮点
- 存储桶级复制控制
用户可针对单个存储桶独立启用或禁用同步功能,实现对复制工作流的精确控制。 - 选择性复制机制
支持全区域复制的同时,可灵活排除特定存储桶,实现更精细的资源管理。 - 多目标复制架构
单个源存储桶可同时向多个目标存储桶进行数据复制,满足复杂业务场景需求。 - 灵活数据流配置
支持按存储桶配置对称或定向数据流,实现最优化的数据同步方案。
下图展示了同步策略功能在实际应用中的典型场景。
二、Ceph 多站点配置
自Quincy版本起,Ceph引入了一个全新的rgw管理器模块,集成在cephadm编排器中。该模块显著简化了多站点复制的配置流程。本节将指导您如何使用rgw管理器模块,通过命令行界面(CLI)在两个独立Ceph集群(每个集群作为一个区域)之间配置对象存储多站点复制。
注意:从Reef版本开始,多站点配置也可通过Ceph UI/仪表板完成。虽然本指南主要使用CLI方式,但可以在官方文档中找到图形化配置的相关信息。
在我们的示例配置中,采用以下逻辑架构:
- 领域(Realm):命名为multisite
- 区域组(Zonegroup):命名为multizg
- 区域(Zone):包含zone1和zone2两个区域
每个区域代表一个地理分布的数据中心内的独立Ceph集群。下图展示了该多站点配置的逻辑架构示意图:
集群配置说明(作为实验环境部署,我们采用了一个精简的配置方案):
- 节点配置:每个Ceph集群包含4个节点
- 存储配置:每个节点配置6个OSD
- 服务部署:每个集群部署4个RGW服务(每个节点1个)
服务角色分配:
- 客户端服务:2个RGW专门处理S3客户端请求
- 复制服务:其余RGW负责多站点复制操作
网络通信机制:
Ceph对象存储的多站点复制数据通过RGW服务使用HTTP协议在集群间传输。这种设计带来了显著的网络优势:我们只需在需要配置多站点的Ceph集群(区域)之间启用HTTP通信即可。
下图展示了我们将逐步配置的最终架构示意图。
在我们的示例配置中,客户端SSL连接将在每个站点的负载均衡器层终止。RGW服务之间的所有通信将使用纯HTTP协议。
在配置TLS/SSL时,我们可以选择在负载均衡器层或RGW服务层终止客户端到S3端点的加密连接。虽然理论上可以同时采用两种方式(即在负载均衡器和RGW之间重新加密),但目前Ceph ingress服务尚不支持这种配置方案。
在接下来的第二篇文章中,我们将详细介绍如何在Ceph集群之间建立多站点复制,具体步骤将基于下图所示的架构展开。
但在开始配置 Ceph 对象存储多站点复制之前,我们需要提供更多有关初始状态的上下文。我们部署了两个 Ceph 集群,第一个集群的节点为ceph-node-00到ceph-node-03 ,第二个集群的节点为ceph-node-04到ceph-node-07 。
[root@ceph-node-00 ~]# ceph orch host ls
HOST ADDR LABELS STATUS
ceph-node-00.cephlab.com 192.168.122.12 _admin,osd,mon,mgr
ceph-node-01.cephlab.com 192.168.122.179 osd,mon,mgr
ceph-node-02.cephlab.com 192.168.122.94 osd,mon,mgr
ceph-node-03.cephlab.com 192.168.122.180 osd
4 hosts in cluster
[root@ceph-node-04 ~]# ceph orch host ls
HOST ADDR LABELS STATUS
ceph-node-04.cephlab.com 192.168.122.138 _admin,osd,mon,mgr
ceph-node-05.cephlab.com 192.168.122.175 osd,mon,mgr
ceph-node-06.cephlab.com 192.168.122.214 osd,mon,mgr
ceph-node-07.cephlab.com 192.168.122.164 osd
4 hosts in cluster
核心Ceph服务已完成部署,包括Ceph的可观测性组件栈,但目前尚未部署RGW服务。所有Ceph服务均以容器化方式运行在RHEL系统上,通过Podman进行管理。
[root@ceph-node-00 ~]# ceph orch ls
NAME PORTS RUNNING REFRESHED AGE PLACEMENT
alertmanager ?:9093,9094 1/1 6m ago 3w count:1
ceph-exporter 4/4 6m ago 3w *
crash 4/4 6m ago 3w *
grafana ?:3000 1/1 6m ago 3w count:1
mgr 3/3 6m ago 3w label:mgr
mon 3/3 6m ago 3w label:mon
node-exporter ?:9100 4/4 6m ago 3w *
osd.all-available-devices 4 6m ago 3w label:osd
prometheus ?:9095 1/1 6m ago 3w count:1
[root@ceph-node-00 ~]# ceph version
ceph version 18.2.0-131.el9cp (d2f32f94f1c60fec91b161c8a1f200fca2bb8858) reef (stable)
[root@ceph-node-00 ~]# podman inspect cp.icr.io/cp/ibm-ceph/ceph-7-rhel9 | jq .[].Labels.summary
"Provides the latest IBM Storage Ceph 7 in a fully featured and supported base image."
# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.2 (Plow)
总结
在本系列的第一部分中,我们全面探讨了Ceph对象存储多站点复制的核心特性和架构设计。通过深入解析多站点复制的工作原理、配置要素和最佳实践,为后续的实际配置奠定了坚实基础。