云原生存储解决方案 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 容器存储接口的支持。我部基于这一新特性也开始针对 Rook-Ceph 进行了适配。
Rainbond 在安装部署阶段，就会引用 Cephfs 来部署默认为所有服务组件提供的共享存储。而对于有状态的服务组件而言，添加持久化存储时，可以选择当前集群中所有可用的 StorageClass，通过选择 rook-ceph-block 即可申请块设备进行挂载，全程图形化界面操作，十分方便。
如何部署 Rook-Ceph 并对接到 Rainbond 之中，请参考文档 Rook-Ceph 对接方案[1] 。
3. 使用体验
这个章节，我会以直观的方式，描述在 Rainbond 对接了 Rook-Ceph 存储之后的各种使用体验。
3.1 使用共享存储
Rainbond 在安装阶段通过指定参数来对接 Cephfs 作为集群共享存储。在使用 Helm 安装 Rainbond 的过程中，关键的对接参数如下：
对于任意一个部署在 Rainbond 平台上的服务组件而言，仅需要在挂载持久化存储时，选择默认的共享存储，即相当于将数据持久化的保存进了 Cephfs 文件系统中。
集群中使用组件英文名可以过滤查询所生成的 PV 资源：
3.2 挂载块设备
除了默认的共享存储之外，其他所有集群中的 StorageClass 都面向有状态服务开放。手动选择 rook-ceph-block 即可创建块设备类型存储，并挂载给 Pod 使用。当服务组件拥有多个实例时，每个 Pod 都会生成一个块设备挂载使用。
查询所生成的 PV 资源：
3.3 开启 dashboard
Rook-Ceph 默认部署时安装了可视化操作界面 Ceph-dashboard。在这里可以监控整个存储集群，也可以基于图形化界面操作更改各种存储类型的配置。
修改 Ceph 集群配置，禁用 dashboard 内置 ssl：
获取 svc，在平台上使用第三方组件的形式代理，开启对外服务地址后，即可经过网关访问 dashboard。
访问到仪表板后，默认用户为admin，在服务器执行以下命令获取密码：
3.4 使用对象存储
请参考文档 Rook-Ceph 部署对接[2] ，可以在 Rook-Ceph 中部署对象存储。只需要将对象存储的 service ClusterIP 通过第三方服务代理，我们就可以得到一个可以被同个控制台纳管的多个集群同时访问的对象存储地址。Rainbond 可以基于这一特性，实现云端备份迁移功能。
获取对象存储的 svc 地址：
通过在企业设置中填写好事先在 Ceph-dashboard 中创建的对象存储 bucket、access-key、secret-key，即可对接好对象存储。
4. 性能对比测试
我们利用 sysbench 工具，对使用了不同类型存储的 Mysql 进行了性能测试，除数据目录挂载了不同类型的存储，其他实验条件均一致。参与测试的存储类型包括 Glusterfs、Cephfs、Ceph-RBD 三种。
采集的数据为 sysbench 测试返回的每秒事务数（TPS）以及每秒请求数（QPS）：
测试结果显而易见，Ceph 块设备性能最高，Cephfs 相对 Glusterfs 也有较明显的性能优势。
5. 写在最后
适配 Kubernetes CSI 容器存储接口是 Rainbond v5.7.0-release 版本的一大特性，这个特性让我们可以轻松对接 Rook-Ceph 这一优秀的存储解决方案。通过对 Rook-Ceph 的使用体验的描述以及最后的性能测试对比，不得不说，Rook-Ceph 即将成为我们在云原生存储领域探索的一个主攻方向。
参考资料
[1]
Rook-Ceph 对接方案: https://www.rainbond.com/docs/ops-guide/storage/ceph-rbd
[2]
Rook-Ceph 对接方案: https://www.rainbond.com/docs/ops-guide/storage/ceph-rbd
版权声明: 本文为 InfoQ 作者【北京好雨科技有限公司】的原创文章。
原文链接:【http://xie.infoq.cn/article/f75c87eee83915138ce08730f】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2018.11.08 加入
还未添加个人简介
评论