云原生存储解决方案Rook-Ceph与Rainbond结合的实践

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
对象存储 OSS,20GB 3个月
云数据库 RDS MySQL,集群版 2核4GB 100GB
推荐场景:
搭建个人博客
简介: 基础不牢,地动山摇。无论是何种体系架构,底层存储的选择都是一个值得探讨的话题。存储承载着业务的数据,其性能直接影响到业务应用的实际表现。也正因为存储和业务的数据关联紧密,其可靠性也必须得到关注,存储的失效一旦导致业务数据丢失,那将会是一场灾难级别的事故。

基础不牢,地动山摇。无论是何种体系架构,底层存储的选择都是一个值得探讨的话题。存储承载着业务的数据,其性能直接影响到业务应用的实际表现。也正因为存储和业务的数据关联紧密,其可靠性也必须得到关注,存储的失效一旦导致业务数据丢失,那将会是一场灾难级别的事故。

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 进行了适配。

rook-ceph-1.png

Rainbond 在安装部署阶段,就会引用 Cephfs 来部署默认为所有服务组件提供的共享存储。而对于有状态的服务组件而言,添加持久化存储时,可以选择当前集群中所有可用的 StorageClass,通过选择 rook-ceph-block 即可申请块设备进行挂载,全程图形化界面操作,十分方便。

如何部署 Rook-Ceph 并对接到 Rainbond 之中,请参考文档 Rook-Ceph 对接方案[1]

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-cephfs

对于任意一个部署在 Rainbond 平台上的服务组件而言,仅需要在挂载持久化存储时,选择默认的共享存储,即相当于将数据持久化的保存进了 Cephfs 文件系统中。

rook-ceph-2.png

集群中使用组件英文名可以过滤查询所生成的 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 都会生成一个块设备挂载使用。

rook-ceph-3.png

查询所生成的 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

3.3 开启dashboard

Rook-Ceph 默认部署时安装了可视化操作界面 Ceph-dashboard。在这里可以监控整个存储集群,也可以基于图形化界面操作更改各种存储类型的配置。

修改 Ceph 集群配置,禁用 dashboard 内置 ssl:

$ kubectl -n rook-ceph edit cephcluster -n rook-ceph rook-ceph
# 修改 ssl 为 false
spec:
 dashboard:
   enabled: true
   ssl: false

# 重启 operator 使配置生效
$ kubectl delete po -l app=rook-ceph-operator -n rook-ceph

$ kubectl -n rook-ceph get service rook-ceph-mgr-dashboard
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rook-ceph-mgr-dashboard ClusterIP 10.43.210.36 <none> 7000/TCP 118m

获取svc,在平台上使用第三方组件的形式代理,开启对外服务地址后,即可经过网关访问 dashboard。

rook-ceph-4.png

访问到仪表板后,默认用户为admin,在服务器执行以下命令获取密码:

kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo

rook-ceph-5.png

3.4 使用对象存储

请参考文档 Rook-Ceph 部署对接[2] ,可以在 Rook-Ceph 中部署对象存储。只需要将对象存储的 service ClusterIP 通过第三方服务代理,我们就可以得到一个可以被同个控制台纳管的多个集群同时访问的对象存储地址。Rainbond 可以基于这一特性,实现云端备份迁移功能。

获取对象存储的 svc 地址:

$ kubectl -n rook-ceph get service rook-ceph-rgw-my-store
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
rook-ceph-rgw-my-store ClusterIP 10.43.12.100 <none> 80/TCP 3h40m

rook-ceph-6.png

通过在企业设置中填写好事先在 Ceph-dashboard 中创建的对象存储 bucket、access-key、secret-key,即可对接好对象存储。

rook-ceph-7.png

4. 性能对比测试

我们利用 sysbench 工具,对使用了不同类型存储的 Mysql 进行了性能测试,除数据目录挂载了不同类型的存储,其他实验条件均一致。参与测试的存储类型包括 Glusterfs、Cephfs、Ceph-RBD 三种。

采集的数据为 sysbench 测试返回的每秒事务数(TPS)以及每秒请求数(QPS):

存储类型 Mysql 内存 QPS TPS
Glusterfs 1G 4600.22 230.01
Cephfs 1G 18095.08 904.74
Ceph-RBD 1G 24852.58 1242.62

测试结果显而易见,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

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
13天前
|
人工智能 Cloud Native Java
从云原生视角看 AI 原生应用架构的实践
本文核心观点: • 基于大模型的 AI 原生应用将越来越多,容器和微服务为代表的云原生技术将加速渗透传统业务。 • API 是 AI 原生应用的一等公民,并引入了更多流量,催生企业新的生命力和想象空间。 • AI 原生应用对网关的需求超越了传统的路由和负载均衡功能,承载了更大的 AI 工程化使命。 • AI Infra 的一致性架构至关重要,API 网关、消息队列、可观测是 AI Infra 的重要组成。
50367 10
|
4天前
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
20 2
|
7天前
|
运维 监控 Cloud Native
云原生架构的演化与实践
【6月更文挑战第29天】云原生技术,作为现代软件开发和运维的前沿阵地,其核心理念在于构建可弹性扩展、高度可靠且易于管理的系统。本文将深入探讨云原生架构的发展脉络,解析其关键技术组件,并通过实际案例展示如何将这些原则应用于日常开发和运维中。我们还将讨论在采纳云原生技术时所面临的挑战及应对策略,以期为读者提供一套全面而实用的云原生解决方案。
122 1
|
13天前
|
Kubernetes 监控 Cloud Native
云原生架构下的微服务治理实践
【6月更文挑战第23天】在云计算的浪潮中,云原生架构以其弹性、可扩展性和高效性成为企业数字化转型的重要推手。本文将深入探讨如何利用云原生技术实现微服务的治理与优化,确保系统的稳定性和高可用性。我们将从微服务的基本概念出发,通过具体案例分析,揭示云原生环境下微服务治理的关键策略,并分享实践经验,旨在为读者提供一套完整的微服务治理解决方案。
|
11天前
|
运维 Cloud Native 安全
云原生架构的演进与实践
【6月更文挑战第25天】本文将深入探讨云原生技术从概念提出到实际应用的发展过程,分析其核心价值和面临的挑战。文章将通过具体案例,展示云原生如何促进企业IT架构的现代化转型,并讨论在实施过程中的最佳实践和注意事项,旨在为读者提供一份云原生技术落地的实用指南。
35 2
|
12天前
|
运维 负载均衡 Cloud Native
云原生架构下的微服务治理实践
【6月更文挑战第24天】在云原生的浪潮下,微服务治理成为确保系统弹性、可维护性和可观测性的关键。本文通过深入分析微服务治理的核心要素与挑战,结合前沿技术和工具,提出一套实用的微服务治理策略,旨在帮助开发者和架构师构建更加稳定、高效且易于管理的分布式系统。
|
17天前
|
存储 Kubernetes 安全
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
|
17天前
|
存储 运维 监控
云原生架构下的微服务治理实践
【6月更文挑战第19天】在数字化转型的浪潮中,云原生技术以其灵活、可扩展的特性成为企业IT架构升级的首选。本文深入探讨了在云原生架构下,如何有效实施微服务治理,包括服务发现、配置管理、服务监控和故障处理等方面的最佳实践。文章旨在为读者提供一套全面的微服务治理框架,帮助团队构建更加稳定、高效的分布式系统。
13 2
|
18天前
|
监控 Cloud Native 安全
云原生架构下的微服务治理实践
【6月更文挑战第18天】本文深入探讨了在云原生架构背景下,微服务治理的实践方法与技术选型。文章首先介绍了云原生的基本概念和微服务治理的重要性,随后详细阐述了服务发现、配置管理、弹性设计等关键技术的实施细节,并结合实际案例分析如何构建高效、稳定的微服务系统。最后,文章讨论了微服务治理面临的挑战及未来发展趋势。
|
19天前
|
运维 Cloud Native 云计算
云原生架构的演变与实践
在数字化浪潮不断推进的今天,企业对于IT基础设施的要求日益增高,云原生技术因此成为推动现代软件开发的关键力量。本文将深入探讨云原生架构的概念、核心价值及其在实际业务中的应用,同时分析面临的挑战和未来的发展趋势,为读者呈现一幅云原生技术演进的全景图。