云原生存储解决方案Rook-Ceph与Rainbond结合的实践
基础不牢,地动山摇。无论是何种体系架构,底层存储的选择都是一个值得探讨的话题。存储承载着业务的数据,其性能直接影响到业务应用的实际表现。也正因为存储和业务的数据关联紧密,其可靠性也必须得到关注,存储的失效一旦导致业务数据丢失,那将会是一场灾难级别的事故。
1. 云原生时代的存储选择之路
最近几年,我的工作内容始终围绕着客户 Kubernetes 集群的建设。如何为客户的 Kubernetes 集群选择一款稳定可靠、性能表现优异的存储解决方案,这样的问题一直困扰着我。
存储卷可以在 Pod 漂移到其他节点后重新挂载这一最基础的功能性要求,让我一开始就把 目光放在了共享文件系统这一存储类型上。最开始选择了 Nfs,到后来又投入了 Glusterfs 的怀抱,直到最近开始努力探索其他更好的云原生存储解决方案,这一路走来也让我对各种存储有了一定的了解。它们各自有着自己的特点:
-
Nfs:Nfs 是一种老牌的基于网络共享文件的存储解决方案。它的优点是简单高效。它的缺点也比较明显,服务端单点故障,数据没有复制机制。在某些对可靠性要求不高的场景下,Nfs依然是不二之选。
-
Glusterfs:这是一种开源的分布式共享存储解决方案。相对于 Nfs 而言,Gfs 通过多副本复制集提升了数据的可靠性,添加 Brick 的机制也让存储集群的扩展不再受限于一台服务器。Gfs 一度是我部在生产环境下的首选,通过将复制因子设置为 3 ,保障了数据的可靠性的同时,又能够避免分布式系统下的数据脑裂的问题。伴随 Gfs 一起前进了很久之后,我们也发现了它在密集小文件读写场景下的性能短板。而且单一的共享文件系统类型的存储,也渐渐不再满足我们的使用场景需要。
我们在寻找更合适的存储这一道路上一直没有停止探索。这两年云原生概念炙手可热,社区中不断涌现出来各种云原生领域项目,其中也不乏存储相关的项目。最开始,我们将目光放在 Ceph 身上,它最吸引我们的是可以提供高性能的块设备类型存储。然而被其复杂的部署方式、较高的运维门槛一度劝退。而 CNCF 毕业项目 Rook 的出现,终于铲平了接触 Ceph 的最后一道门槛。
Rook 项目提供了一种云原生存储编排工具,为各种类型的存储提供平台级、框架级的支持,统管了存储软件的安装、运维。Rook 在 2018 年发布的 0.9 版本中,正式将 Ceph Operator 作为稳定支持的特性,迄今已经数年。使用 Rook 部署 和管理生产级别的 Ceph 集群还是非常稳健的。
相对于 Gfs ,Rook-Ceph 提供了性能极高的块设备类型存储,这相当于为 Pod 挂载了一块硬盘,应对密集小文件读写场景并非难事。Rook-Ceph 除了能够提供块设备类型存储之外,也可以基于 Cephfs 提供分布式共享存储,以及基于 S3 协议的对象存储。多种存储类型统一管理,并提供了可视化管理界面,对于运维人员非常友好。
作为 CNCF 毕业项目,Rook-Ceph 对云原生场景的支持毋庸置疑。部署完成的 Rook-Ceph 集群提供了 CSI 插件,以 StorageClass 的形式面向 Kubernetes 供应数据卷,对于兼容 CSI 规范的各类云原生 PaaS 平台也非常友好。
2. Rainbond与Rook的对接
在 Rainbond V5.7.0-release 版本中,添加了对 Kubernetes CSI 容器存储接口的支持。
Rainbond 在安装部署阶段,就会引用 Cephfs 来部署默认为所有服务组件提供的共享存储。而对于有状态的服务组件而言,添加持久化存储时,可以选择当前集群中所有可用的 StorageClass,通过选择 rook-ceph-block
即可申请块设备进行挂载,全程图形化界面操作,十分方便。
如何部署 Rook-Ceph 并对接到 Rainbond 之中,请参考文档 Rook-Ceph 对接方案 。
3. 使用体验
这个章节,我会以直观的方式,描述在 Rainbond 对接了 Rook-Ceph 存储之后的各种使用体验。
3.1 使用共享存储
Rainbond 在安装阶段通过指定参数来对接 Cephfs 作为集群共享存储。在使用 Helm 安装 Rainbond 的过程中,关键的对接参数如下:
--set Cluster.RWX.enable=true \
--set Cluster.RWX.config.storageClassName=rook-cephfs \
--set Cluster.RWO.enable=true \
--set Cluster.RWO.storageClassName=rook-ceph-block
对于任意一个部署在 Rainbond 平台上的服务组件而言,仅需要在挂载持久化存储时,选择默认的共享存储,即相当于将数据持久化的保存进了 Cephfs 文件系统中。
集群中使用组件英文名可以过滤查询所生成的 PV 资源:
$ kubectl get pv | grep mysqlcephfs
pvc-faa3e796-44cd-4aa0-b9c9-62fa0fbc8417 500Gi RWX Retain Bound guox-system/manual7-volume-mysqlcephfs-0 rainbondsssc 2m7s
3.2 挂载块设备
除了默认的共享存储之外,其他所有集群中的 StorageClass 都面向有状态服务开放。手动选择 rook-ceph-block
即可创建块设备类型存储,并挂载给 Pod 使用。当服务组件拥有多个实例时,每个 Pod 都会生成一个块设备挂载使用。
查询所生成的 PV 资源:
$ kubectl get pv | grep mysql6-0
pvc-5172cb7a-cf5b-4770-afff-153c981ab09b 50Gi RWO Delete Bound guox-system/manual6-app-a710316d-mysql6-0 rook-ceph-block 5h15m