基于云原生存储的容器持久化存储方案

基于云原生存储的容器持久化存储方案

【摘要】容器正逐渐成为云上应用的标准部署单元，某保险公司将所有业务系统进行容器化部署，在综合了技术先进性、成熟性、安全性、可扩展性等架构评估要素，并利用现有的物理存储的基础上，最终确认采用以分布式云原生存储IOMesh方案为主、容器本地存储相配合的容器持久化存储架构方案。该方案可以整合当前IT基础架构中的存储系统，支持的基础架构包括公有云、私有云和裸金属，大大提高企业在多云或混合云架构中存储资源的利用率，也满足了云应用、数据库以及大数据等不同业务场景的存储需求。1.背景某保险公司将所有业务系统进行容器化部署，容器云平台的数据存储采取了分布式持久化技术，存储场景涉及了云应用、数据存储和分析、高性能计算以及数据边界隔离。由于金融监管的要求，存储作为核心基础架构设施，需要保证高稳定性和高安全性，需要对数据一致性、灾备和恢复有严格的要求。2.需求分析容器正逐渐成为云上应用的标准部署单元，容器云平台需要解决分布式持久化存储的需求。同时容器编排系统也已成为趋势，在无状态的容器中，分布式存储系统需要适配不同的存储模式和规模，具体的架构需求如下：分布式持久化存储系统根据不通的场景具备融合架构和分离架构的能力，满足高效率的文件检索、高带宽的吞吐性能，高可靠的数据安全保障；存储插件需要支持不同的后端存储；分布式持久化存储系统需要结合容器云平台实现自动化功能，如弹性伸缩，隔离管理，还需要具备可视化监控。3.总体架构设计3.1方案设计原则高可用原则关键软硬件组件都要求高可用设计部署，全链路冗余，能应对多种故障场景。先进性与成熟性原则方案采用业界主流云计算技术，保持技术的先进性，同时更偏向于采用成熟的商业解决方案，以保证系统的稳定性。可扩展性原则采用分布式架构方案，满足弹性扩容需求，并对外提供开放标准的API接口，便于功能的扩展。合适原则方案适应大多数存储场景，注重成本与收益的平衡，合理利用现有计算存储资源，关注资源的使用效率。简单原则尽量降低方案设计的复杂性，在满足合适原则下，选用简单易行方案。3.2总体架构图1.容器持久化存储架构图如图1所示，容器云可构筑在公有云、私有云、虚拟化以及裸金属等不同的物理底座之上。不同于物理存储，容器存储是容器云的组件之一，是跨平台、更高层的逻辑概念，主要包括容器云存储和容器本地存储，容器云存储通过CSI存储插件可将云存储卷挂载到容器，从而能被容器应用访问。在本方案中，主要采用的是以分布式云原生存储为主、容器本地存储相配合的容器持久化存储架构，并充分利用现有的物理存储系统，提高资源利用效率，也满足全业务场景的存储需求。3.3部署建议物理机部署物理底座选择裸金属，可满足最大性能需求，但不易扩展，运维简便性不足。虚拟化部署物理底座选择虚拟化或云平台，易扩展、运维简单，适用于大多数容器应用场景，但有一定的资源损耗。混合部署综合来看，最终建议采用混合部署的方式，需要根据集群性能、运维管理、资源利用率、技术成熟度、成本等因素，合理利用原有的计算存储资源，去权衡不同业务场景下的物理部署方案。4.详细方案说明4.1存储方案选型容器云存储是建立在物理存储之上的一种逻辑概念，需建立物理存储到容器存储的映射关系。结合现有的物理存储资产，分析物理存储到容器存储的映射关系，如表1所示。现有物理存储特点映射方式容器访问方式对象存储容量扩展性强，成本低，性能一般不需要映射HTTP/RESTAPI接口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.2IOMesh云原生存储架构IOMesh可以整合当前IT基础架构中的存储系统，支持的基础架构包括公有云、私有云和裸金属，大大提高企业在多云或混合云架构中存储资源的利用率。IOMesh将整个架构中的存储资源进行池化,支持在线扩容，以供Kubernetes集群使用，如图2所示。图2.IOMesh云原生存储架构图IOMesh主要有三个组件：IOMeshCSIDriver，是符合KubernetesCSIDriver规范的CSI插件，可以为容器调度平台提供管理存储的接口；IOMeshOperator，提供了和应用统一的运维方式，负责存储集群的运维，包括一键安装、一键升级、一键扩容等；IOMeshCluster，分布式块存储集群，基于本地存储盘构建存储资源池。IOMesh的优势主要在于：1)裸设备存储引擎：性能更优；2)智能数据分层：自动分层，成本效益最大化；3)无内核依赖：故障隔离，稳定性高；4)自动数据恢复：高可用，易维护；5)弹性扩展：灵活横向扩展；6)卷级别管理：存储管理更精细的；7)监控分析：可视化的统一监控管理。4.3动态Provision过程持久化存储主要通过持久卷(PV，PersistentVolume)、持久卷声明(PVC，PersistentVolumeClaim)两种方式来实现。PV是集群存储资源，PVC则是用户对存储资源的请求，通过PV满足请求。PV的Provision分为静态和动态两种方式，其中静态供应需要管理员手动创建PV，但会大大增加存储运维工作；而动态供应可以不需要集群管理员的任何手动干预，主要通过定义存储类(StorageClass),并在PVC时对存储类进行声明的方式。存储类抽象了存储供应的细节，而依赖于制定的供应程序来处理供应逻辑。整个自动供应过程如图3所示：图3.动态Provision过程本方案中使用的存储及对应的存储类配置信息如下表所示：存储CSI-Provisioner存储接口AcessModes用途NetAppnetapp.io/tridentNfsReadWriteOnce，ReadWriteMany共享文件存储IOMeshcom.iomesh.csi-driverIscsiReadWriteOnce高性能块存储存储类是管理员需要提前规划定义的，对于IOMesh来说，其存储类定义可参考如下：在完成存储类定义后，用户可使用已定义的存储类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中使用headlessService和StatefulSet部署Cassandra集群，replicas设置为3。每个Cassandra集群节点各申请一个PVC，IOMesh再将通过动态供应卷的机制提供PV。每一个Cassandra集群节点均有为稳定、唯一的网络标识和持久化存储，应用可以按照顺序、优雅的启停。对于关系数据库和NOSQL来说，云原生存储提供了数据多副本机制保障数据安全，可根据具体的技术架构和实际业务需要决定是否部署数据库层的高可用架构或数据多副本，避免存储资源的浪费。4.4.3大数据场景大数据分析、高性能计算场景是一种大规模、高并发的数据密集型应用。相比于传统业务应用，存储方面需要满足更大的内存、存储级内存、固态硬盘、NVMe、更大的存储容量等基础设施要求，容器化后也一般是部署在物理主机上，可充分使用服务器的内存和本地NVMeSSD。传统的大数据分析和高性能计算场景存在着资源利用率低、资源隔离性差等问题，而容器化改造能很好地解决这个问题。一般来说，数据分析类应用是一种夜间离线业务，而在线业务高峰主要出现在日间，容器云平台混合部署后，容器的弹性伸缩可以有效提升资源利用率；大数据分析和高性能计算的各组件容器化后，可以做到容器间对于CPU、内存等资源的隔离。以大数据分析应用为例，包括分布式文件系统HDFS、列数据库HBase等组件，容器化部署如下表所示。大数据组件用途容器部署方式数据存储HDFS文件存储，Hadoop基础组件StatefulSet+DaemonSet本地磁盘，根目录；IOMesh块存储HBase列数据库StatefulSetHDFSMySQL关系数据库DeploymentIOMesh块存储Hive数据查询分析StatefulSetHDFS，MySQLHbase架构在HDFS之上，HDFS的存储架构需重点设计。如图6所示，HDFS一般包括Namenode和多个Datanode，Namenode容器管理着HDFS的元数据MetaData，存放在IOMesh云原生存储池中；每个节点主机通过DaemonSet方式固定部署某个Datanode容器，Datanode容器管理着实际的数据块，存储在节点主机的本地磁盘。HDFS的数据量较大，本身就支持多数据副本机制，有着一套完整的存储管理机制，数据块部署在本地磁盘可以很好地契合场景。图6.HDFS的容器存储部署

4.5异常场景应对对于分布式持久化存储系统来说，异常场景主要受以下三类因素影响：1)自身的可用性存储的软硬件组件层面的冗余设计存在缺陷，在部分组件故障失效时，会导致部分或全部服务不可用，甚至会出现数据丢失的极端情况。2)自身的稳定性在部分软硬件故障或故障恢复时，存储性能出现较大下降，响应延迟增加，从而可能会导致应用访问队列堵塞，严重影响到用户体验。3)外在的容器云环境云原生存储运行在容器云平台上，会受到容器云平台的故障影响，比如节点主机故障、容器云平台故障等，从而严重影响到云原生存储，用户体验下降或无法对外提供服务。针对上述因素引起的异常场景，在存储方案设计和部署时，需要关注以下几点：高可用部署高可用部署需要满足软硬件层面的全冗余，需要考虑软件层的组件配置、组件的主机部署、机柜位置分布、网络拓扑等因素。对于云原生存储IOMesh来说，采用了先进的全分布式架构，其充分利用了容器云平台的高可用特性，安装部署简单，可根据实际需求，配置3~5MetaServers和ChunkServer。存储插件IOMesh采用IO