【作者】陈萍春,利安人寿系统架构师
1. 背景
某保险公司将所有业务系统进行容器化部署,容器云平台的数据存储采取了分布式持久化技术,存储场景涉及了云应用、数据存储和分析、高性能计算以及数据边界隔离。由于金融监管的要求,存储作为核心基础架构设施,需要保证高稳定性和高安全性,需要对数据一致性、灾备和恢复有严格的要求。
2. 需求分析
容器正逐渐成为云上应用的标准部署单元,容器云平台需要解决分布式持久化存储的需求。同时容器编排系统也已成为趋势,在无状态的容器中,分布式存储系统需要适配不同的存储模式和规模,具体的架构需求如下:
分布式持久化存储系统根据不通的场景具备融合架构和分离架构的能力,满足高效率的文件检索、高带宽的吞吐性能,高可靠的数据安全保障;
存储插件需要支持不同的后端存储;
分布式持久化存储系统需要结合容器云平台实现自动化功能,如弹性伸缩,隔离管理,还需要具备可视化监控。
3. 总体架构设计
3.1 方案设计原则
高可用原则
关键软硬件组件都要求高可用设计部署,全链路冗余,能应对多种故障场景。
先进性与成熟性原则
方案采用业界主流云计算技术,保持技术的先进性,同时更偏向于采用成熟的商业解决方案,以保证系统的稳定性。
可扩展性原则
采用分布式架构方案,满足弹性扩容需求,并对外提供开放标准的API接口,便于功能的扩展。
合适原则
方案适应大多数存储场景,注重成本与收益的平衡,合理利用现有计算存储资源,关注资源的使用效率。
简单原则
尽量降低方案设计的复杂性,在满足合适原则下,选用简单易行方案。
3.2 总体架构
图1.容器持久化存储架构图
如图1所示,容器云可构筑在公有云、私有云、虚拟化以及裸金属等不同的物理底座之上。不同于物理存储,容器存储是容器云的组件之一,是跨平台、更高层的逻辑概念,主要包括容器云存储和容器本地存储,容器云存储通过CSI存储插件可将云存储卷挂载到容器,从而能被容器应用访问。
在本方案中,主要采用的是以分布式云原生存储为主、容器本地存储相配合的容器持久化存储架构,并充分利用现有的物理存储系统,提高资源利用效率,也满足全业务场景的存储需求。
3.3 部署建议
物理机部署
物理底座选择裸金属,可满足最大性能需求,但不易扩展,运维简便性不足。
虚拟化部署
物理底座选择虚拟化或云平台,易扩展、运维简单,适用于大多数容器应用场景,但有一定的资源损耗。
混合部署
综合来看,最终建议采用混合部署的方式,需要根据集群性能、运维管理、资源利用率、技术成熟度、成本等因素,合理利用原有的计算存储资源,去权衡不同业务场景下的物理部署方案。
4. 详细方案说明
4.1 存储方案选型
容器云存储是建立在物理存储之上的一种逻辑概念,需建立物理存储到容器存储的映射关系。结合现有的物理存储资产,分析物理存储到容器存储的映射关系,如表1所示。
现有物理存储 | 特点 | 映射方式 | 容器访问方式 |
对象存储 | 容量扩展性强,成本低,性能一般 | 不需要映射 | HTTP/REST API接口 |
NAS存储 | 性能不高,扩展性弱 | 容器云文件存储 | NFS,挂载存储卷到容器 |
SAN存储 | 存储延时低,性能稳定,成本高,扩展性弱 | 容器本地存储 | HostPath或EmptyDir |
容器云块存储 | iscsi,挂载存储卷到容器 | ||
本地硬盘 | 成本低,适配SSD和HDD | 容器本地存储 | HostPath或EmptyDir |
分布式云原生存储 | iscsi,挂载存储卷到容器 |
表1.物理存储到容器存储的映射关系
容器一般不需要持有对象存储,容器应用可直接访问对象存储;传统NAS存储可匹配容器云平台的文件存储需求,支持在多个容器中挂载和数据共享;传统SAN存储成本较高,性能稳定,为特定的业务场景服务,但弹性扩展能力弱,运维管理相对复杂,并不适合提供大规模容器云块存储服务;服务器的本地磁盘成本低,在其上规划部署分布式云原生存储,可提供大规模容器云块存储服务功能。在合理利用现有存储资源的前提下,提供大规模容器云块存储功能的云原生存储是本方案的主要选型目标。
云原生存储是专为容器化应用构建的存储系统,和应用一起运行在容器平台之上,充分发挥容器平台的优势,满足高可用性、可扩展性、动态部署、存储服务自维护等要求,可极大地降低管理复杂度和运维成本。目前主流的云原生存储方案主要分为开源与闭源商用两种解决方案:
1)开源云原生存储
主要包括OpenEBS、Rook-Ceph等开源架构的分布式云原生存储。其特点是IO性能、吞吐、时延等方面都表现欠佳,需要有比较强的技术团队做保障,不适宜直接应用于生产环境。
2)商用云原生存储方案
商业云原生存储提供了更多企业级应用功能,性能和稳定性方面也要优于开源方案。相比于Portworx、StorageOS等国外厂商的云原生存储方案,SmartX公司的IOMesh有着国内本地研发的优势,能提供更快的用户响应,同时也具备着更高的IO性能。
综合技术先进性、成熟性、安全性、可扩展性等架构评估要素,在利用现有的物理存储的基础上,最终确定了以分布式云原生存储IOMesh方案为主、容器本地存储相配合的容器持久化存储方案。
4.2 IOMesh云原生存储架构
IOMesh可以整合当前IT基础架构中的存储系统,支持的基础架构包括公有云、私有云和裸金属,大大提高企业在多云或混合云架构中存储资源的利用率。IOMesh 将整个架构中的存储资源进行池化, 支持在线扩容,以供 Kubernetes 集群使用,如图2所示。
图2.IOMesh云原生存储架构图
IOMesh主要有三个组件:
IOMesh CSI Driver,是符合 Kubernetes CSI Driver 规范的 CSI 插件, 可以为容器调度平台提供管理存储的接口;
IOMesh Operator,提供了和应用统一的运维方式,负责存储集群的运 维,包括一键安装、一键升级、一键扩容等;
IOMesh Cluster,分布式块存储集群,基于本地存储盘构建存储资源池。
IOMesh的优势主要在于:
1)裸设备存储引擎:性能更优;
2)智能数据分层:自动分层,成本效益最大化;
3)无内核依赖:故障隔离,稳定性高;
4)自动数据恢复:高可用,易维护;
5)弹性扩展:灵活横向扩展;
6)卷级别管理:存储管理更精细的;
7)监控分析:可视化的统一监控管理。
4.3 动态Provision过程
持久化存储主要通过持久卷(PV,Persistent Volume)、持久卷声明(PVC,Persistent Volume Claim)两种方式来实现。PV是集群存储资源,PVC则是用户对存储资源的请求,通过 PV满足请求。
PV的Provision分为静态和动态两种方式,其中静态供应需要管理员手动创建PV,但会大大增加存储运维工作;而动态供应可以不需要集群管理员的任何手动干预,主要通过定义存储类(Storage Class),并在PVC时对存储类进行声明的方式。存储类抽象了存储供应的细节,而依赖于制定的供应程序来处理供应逻辑。整个自动供应过程如图3所示:
图3. 动态Provision过程
本方案中使用的存储及对应的存储类配置信息如下表所示:
存储 | CSI-Provisioner | 存储接口 | Acess Modes | 用途 |
NetApp | netapp.io/trident | Nfs | ReadWriteOnce, ReadWriteMany | 共享文件存储 |
IOMesh | com.iomesh.csi-driver | Iscsi | ReadWriteOnce | 高性能块存储 |

在完成存储类定义后,用户可使用已定义的存储类iomesh–sc1来创建声明PVC,指定的PV支持单节点读写,大小为10G,定义的yaml文件参考如下:
4.4 应用场景分类
在容器云平台中,典型的有状态应用场景主要包括云应用、云数据库、NOSQL、大数据分析和高性能计算等类型,本节将分别介绍这几类应用场景下的存储应用。
4.4.1 云应用场景
一般是轻量级应用,应用之间不挂载共享存储,容器部署在云VM主机上,应用间可通过容器直接访问对象存储的方式实现数据共享。在云原生存储池中创建不同业务应用的StorageClass,单个应用容器对应于一个或多个StorageClass,应用通过申请指定的StorageClass的存储资源PVC,存储集群会创建和分配PV,PV会再被动态绑定到应用容器,从而实现存储资源的动态供应,如图4所示。
图4.云应用的容器存储部署
对于部分需要挂载共享存储的应用,则使用NAS存储对应的StorageClass,通过PVC绑定PV,最终实现应用容器通过NFS方式共享文件存储。
4.4.2 数据库场景
数据库场景主要是MySQL、PostgreSQL等关系型数据库以及MongoDB、Cassandra、Hbase等NoSQL数据库,具体可根据存储IO性能需求选择部署在云VM主机或物理服务器上。对于数据库场景来说,存储IO性能至关重要。在同等硬件条件和测试参数下,IOMesh的性能远超业界同类产品。
图5. 存储性能测试对比
MySQL部署:
以单节点MySQL容器化部署为例,在 Kubernetes中使用Service和Deployment部署 MySQL,通过PVC声明了一个存储卷,并在Deployment中引用这个PVC,IOMesh再通过动态供应卷的机制为MySQL提供PV。当MySQL容器所在的节点发生故障时,Kubernetes集群会立即检测到节点故障,并自动在集群内的一个可用节点上创建新的Pod,并重新绑定原有的PV,一定程度上保证了数据库服务的高可用。
Cassandra部署:
Cassandra是一种Key—Value键值对数据库,采用一致性hash算法对存储在节点上的数据进行分片,每个节点上均保存有数据分片。以三节点的Cassandra集群部署为例,在 Kubernetes中使用headless Service和StatefulSet部署Cassandra集群,replicas设置为3。每个Cassandra集群节点各申请一个PVC,IOMesh再将通过动态供应卷的机制提供PV。每一个Cassandra集群节点均有为稳定、唯一的网络标识和持久化存储,应用可以按照顺序、优雅的启停。
对于关系数据库和NOSQL来说,云原生存储提供了数据多副本机制保障数据安全,可根据具体的技术架构和实际业务需要决定是否部署数据库层的高可用架构或数据多副本,避免存储资源的浪费。
4.4.3 大数据场景
大数据分析、高性能计算场景是一种大规模、高并发的数据密集型应用。相比于传统业务应用,存储方面需要满足更大的内存、存储级内存、固态硬盘、NVMe、更大的存储容量等基础设施要求,容器化后也一般是部署在物理主机上,可充分使用服务器的内存和本地NVMe SSD。
传统的大数据分析和高性能计算场景存在着资源利用率低、资源隔离性差等问题,而容器化改造能很好地解决这个问题。一般来说,数据分析类应用是一种夜间离线业务,而在线业务高峰主要出现在日间,容器云平台混合部署后,容器的弹性伸缩可以有效提升资源利用率;大数据分析和高性能计算的各组件容器化后,可以做到容器间对于CPU、内存等资源的隔离。
以大数据分析应用为例,包括分布式文件系统HDFS、列数据库HBase等组件,容器化部署如下表所示。
大数据组件 | 用途 | 容器部署方式 | 数据存储 |
HDFS | 文件存储, Hadoop基础组件 | StatefulSet+DaemonSet | 本地磁盘,根目录; IOMesh块存储 |
HBase | 列数据库 | StatefulSet | HDFS |
MySQL | 关系数据库 | Deployment | IOMesh块存储 |
Hive | 数据查询分析 | StatefulSet | HDFS,MySQL |
4.5 异常场景应对
高可用部署
高可用部署需要满足软硬件层面的全冗余,需要考虑软件层的组件配置、组件的主机部署、机柜位置分布、网络拓扑等因素。对于云原生存储IOMesh来说,采用了先进的全分布式架构,其充分利用了容器云平台的高可用特性,安装部署简单,可根据实际需求,配置3~5 Meta Servers和Chunk Server。
存储插件
IOMesh采用IOMesh CSI Driver,是符合Kubernetes CSI Driver规范的CSI插件,与容器编排系统松耦合,可以为容器调度平台提供管理存储的接口,丰富了插件功能,提升了容器存储管理的稳定性。
数据副本
多个数据副本可提供节点级可靠性保障和自动数据恢复功能,防止节点故障引起的数据损坏。IOMesh可根据业务数据重要性级别选择两副本和三副本机制,同时还能根据业务负载智能条件数据恢复的速率,充分保证业务性能。
性能规划
存储性能规划也至关重要,需要充分考虑异常场景下的性能损失情况,可适当通过选择更好的存储介质,通过IOMesh的智能数据分层,保障重要业务系统拥有更高的性能。
监控分析
IOMesh可以和云原生的运维生态很好地结合支持与通用的第三方监控软件Prometheus 和 Grafana 集成,实现对存储集群中集群、节点、卷等多个级别资源对象的指标数据的采集和可视化监控,可及时发现、定位故障。
备份恢复
对于有状态应用的容器,为保证数据的安全,还需要对持久化存储卷PV做克隆、快照,以便进行回滚、重建。另外需要考虑IOMesh的多集群部署方案,以应对容器集群级的故障恢复需求。
5. 总结
(来源:twt企业IT社区)
发表评论