企业容器云持久化存储方案设计及难点解读.docx

《企业容器云持久化存储方案设计及难点解读.docx》由会员分享，可在线阅读，更多相关《企业容器云持久化存储方案设计及难点解读.docx（17页珍藏版）》请在第一文库网上搜索。

1、企业容器云持久化存储方案设计及难点解读容器迁移过程中，同时需要对数据也进行迁移，需要一套数据扩容和管理的机制来满足有状态服务的数据存储需要。在面向有状态的容器服务时，需要考虑以下几个方面的数据持久化需求：1、容器对应的存储卷在进行故障恢复时，会带来卷的挂载和卸载。为了保证整个生产环境的高可用，卷的挂载和卸载一方面需要具有足够的稳定性，同时也需要考虑性能需求，避免应用延迟。2、存储卷快照管理需求。传统的存储卷快照策略主要从资源角度进行管理，而容器的存储卷往往动态分配而来，快照策略需要与容器应用备份需求保持一致。3、容量扩容需求：随着容器应用数据的增长，存储卷容量需要考虑扩容的能力，最大程度避免对

2、应用运行的影响。4、运维管理需求：随着容器有状态应用的增长，对传统存储运维工作也会带来挑战，整体方案需要兼顾运维敏捷和安全。5、分布式存储需求：银行创新业务的扩展能力通常都是横向扩展的，需要容器云具备横向扩展的能力，需要引入分布式存储架构部署在容器云平台上。为了能更好的解决大家在容器云持久化上的需求及方案设计下遇到的建设难点，twt社区不久前特别邀请了某大型银行的容器云专家以及SmartX的容器持久化专家在线辅导答疑。本文对交流内容进行总结，供更多同行参考。分为四个部分：容器持久化存储建设难点和关注点、容器持久化存储的建设方案重点考虑的涉及层面、容器持久化技术层面的选择、交流总结共识。一、容器

3、持久化存储建设难点和关注点1、企业容器云为支持有状态应用的容器应用部署，存储设计时需要考虑哪些因素？rechen招商银行云计算架构师：有状态应用的状态可细分指拓扑状态、存储状态。其中拓扑状态指应用的多个实例之间不是对等关系，这些应用实例，必须按照某种顺序启动。存储状态则是指应用的多个实例分别绑定了不同的存储数据，对于这些应用实例来说。当应用因为某些原因导致了宕机，重启后依旧可以正常的读取到数据。在容器云上部署的有状态应用，其部署需求有：维持稳定且唯一的网络标识，提供稳定持久的存储，提供有序和优雅的部署和伸缩能力，提供有序和自动的更新能力。因此存储设计时，要综合考虑到有状态应用的特征进行设计，譬

4、如在容器云上部署数据库这类有状态应用，和部署日志监控这类有状态应用就有不同的设计维度和优先级。存储产品的选型优先考察稳定、安全、性能和API能力。asdf-asdfc1oudstone研究学者：当前有状态应用的容器应用部署，如果有能力应修改应用。使其状态保存在缓存服务器类似Redisc1uster中，相关日志统一进入E1K,或者Kafka完成持久化。这样存储设计相对简单，只要保证E1K和Redis的存储容量和访问速度。如果无法修改应用，需要挂载一个持久化卷，来持久化数据。使数据可以在不同节点漂移，需要所有主机对存储的访问权限，这个又会出现存储访问风险。在实际业务场景，把存储分多个区域，挂载到对

5、应区域的主机，进行区别访问，避免访问风险。2、持久化存储选择集中式存储，还是分布式存储?rechen招商银行云计算架构师：容器云的持久化存储的选型，还是要根据承载的工作负载进行具体分析。譬如在容器云上部署关系型数据库，且数据库的数据是重要的业务系统数据，则选择集中式存储为宜。如果是业务应用系统的日志，或者是配置文件，则建议优先选择分布式存储，在扩展性和成本收益上更佳。nawangSmartX产品经理：集中式存储：可以在Kubernetes中使用已有的FC-SAN或NAS。然而，传统存储不可弹性扩展、依赖专有硬件、运维管理相对复杂等特点与云原生所要求的敏捷背道而驰，它们并不是K8s的首选。分布式

6、存储：分布式存储天然具有横向扩展能力，在性能和高可用方面远优于集中式存储，非常适合应对大规模虚拟化场景。不过在实际的使用过程中，大部分分布式存储的性能和稳定性都难以达到生产级别的标准，这使得很多运维团队不敢轻易地部署分布式存储产品。二、容器持久化存储的建设方案重点考虑的涉及层面1、金融行业企业级容器持久化存储方案，开源和商用应该如何选择？优劣势分析？rechen招商银行云计算架构师：金融行业企业级容器持久化存储方案，建议从稳定性、安全性维度上，选择商用产品。选择走开源路线的话，则必须要自建研发团队补齐稳定性和安全能力，以及高水平的运维团队，这样综合成本上看，是投入大、风险高且见效慢，不利于金融

7、行业提升业务核心竞争力。nawangSmartX产品经理：建议选择商用型存储方案。商用型存储方案，以IOMesh云原生存储产品为例，相较Ceph、G1usterFS类开源架构的分布式存储，优势有以下几点：1）掌握核心代码，可控性更强。开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重问题时也不能特别快速地响应，往往需要等待社区的修复。IOMesh选择自主研发的形式，充分把控产品质量和功能，可以根据众多客户的实际需求迭代产品，也能在出现问题时提供本地研发级别的快速响应，为用户业务运转提供强有力的保证。2 ）更灵活。通过元数据服务实现数据副本的精确放置，可以形成更加灵活的副本分配

8、策略，并按照资源进行调整副本分配位置，而不是简单打散；3 ）性能更高。可以实现计算与存储I/O路径的深度融合，发挥更高的性能。2、容器持久化存储方案重点考虑哪些层面设计？nawangSmartX产品经理：1云原生存储系统需要能够良好的运行在各种不同服务商提供的公有云环境或私有云环境，能够很好地和其他云原生基础设施配合，例如云原生数据库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。2.云原生存储系统需要为运维人员提供相同接口和运维方式，即运行在K8s中，使用K8s的工具进行运维和管理，具备容器化部署、自动运维、声明式接口等特征，降低运维团队的负担。3、如何选择合适的容器云

9、持久化存储方案，Rook+Ceph用于生产环境有何风险？nawangSmartX产品经理：开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重问题时也不能特别快速地响应，往往需要等待社区的修复。而商用型存储方案，尤其是厂商具备自主研发能力的，可以充分把控产品质量和功能，可以根据众多客户的实际需求迭代产品，也能在出现问题时提供本地研发级别的快速响应，为用户业务运转提供强有力的保证。4、容器数据备份有哪些好的方案？容器全备份？还是提取容器中的数据来备份？rechen招商银行云计算架构师：需对容器的数据做好分层规划，容器镜像放在镜像仓库中，不必做备份；容器实例存取的数据，如果是存储在

10、分布式文件系统中，则做好分布式文件系统的高可用和备份即可。强哥之神上汽云计算中心容器云架构师及技术经理：容器数据备份，首先是明确是哪些数据，是日志还是应用产生的数据，还是应用需要依赖的数据。如果是日志数据，就可以对接日志平台，也可通过f1uentd等日志组件收集；如果是应用产生的数据，那么最好需要通过持久化进行备份到分布式存储中;如果是应用依赖的数据，比如中间件数据库等应用，也可以持久化到分布式存储中，但这种情况更多会追求存储性能，就需要用本地卷如1oca1PV来实现，但本身需要依赖应用自身做好数据的同步，比如MySQ1的主备通过bin1og同步。ha1f_1ife上海骥步科技有限公司研发总监

11、：容器的数据备份，其实就是有状态应用在k8s的备份问题（不包括容器的镜像），个人认为实际上已经不能把容器本身以及应用的数据分开来了。备份的时候，应该把应用以及应用相关的资源，如configmap,secret,pv,pvc,service,以及pv里面的数据，一起备份下来，并且拷贝或者上传到第二存储，同主存储隔离开来。目前国外主流的产品有kasten的K1O,PortworxPXbackup,以及社区的开源项目ve1ero。这些产品的主流做法，就是把应用的资源以及数据打包，一起备份到S3对象存储，或者NFS等第二存储。其中，PV,PVC还可以抓取CSI快照，然后对快照进行备份，或者对快照进行有

12、选择的数据导出。之所以这样做，是因为在k8s容器时代，容器是一个动态变化的资源，例如正在运行在哪个node上、配置的参数、版本等等信息都可能是变化的。而最关键的数据，是靠PV,PVC这样的资源来描述的。换句话说，PV,PVC其实就记录了容器同应用数据的mapping关系。在备份的时候，如果容器跟底下使用的存储（如分布式存储）分开备份，这样可能带来几个问题：容器的备份时间跟存储的备份时间不一致，这样就造成版本的不一致。存储的备份一般是针对存储本身的vo1ume/1UN进行备份，恢复的时候，还要处理VOIUnIe/1UN同PV的关系。一个集群可能使用不止一个存储，那备份的时候还要考虑不同存储的备份

13、策略。一个分布式存储可能对多个集群供应存储，对某个集群的某个应用的细粒度的数据恢复来说，可能不好处理。总之，如果备份时候对容器和存储分开考虑，那还是基本沿用了虚机时代备份的思路，在容器时代要用的好可能有点困难。在备份的时候，把应用相关的资源一起打包备份，其实就是把资源跟数据的关系在同一个时间点一起备份下来，形成一个比较完整的可用的恢复点，将来恢复时候，也是根据应用的颗粒度来进行恢复的。笑笑财险系统工程师：备份整个容器肯定不现实。提取容器中的数据也不用。因为如果是应用需要持久化存储，那么就备份持久化存储上面的数据就好。比如你是商业存储提供持久化存储，那么可以通过存储层面去做备份。如果是用Ceph

14、这些分布式存储，那么可以利用Veritas结合分布式存储来备份。guojin_cib兴业软件架构设计师：这里暂且只讨论容器数据备份，而不涉及集群的备份和恢复。容器里面实现持久化存储的方式比较多，一方面通过hostpath挂载，隐射宿主机的目录到容器的目录，另一方便通过通过storage绑定挂载持久卷到容器的任何目录。还有通过将NFS目录作为容器的卷挂载的，当谈到备份数据时，上面的方法都存在一个相同的问题-如果容器内的数据在备份过程中发生变更，那么就出现了数据的不一致性，当然我们可以通过关闭卷的读写来获得数据的一致性，不过关闭卷来备份，会导致业务连续性的中断。这里建议在k8s集群中，把有状态服务

15、的信息存储在数据中，独立于容器的文件的系统。这样就可以按照常规的方式备份数据，比如快照。这里介绍几个开源项目一个是openebs,比较火的开源的云原生的存储。另外一个就是ve1ero项目，可对集群资源备份和恢复。ZhUqibSMcd软件开发工程师:首先，容器中如果有数据，有三种方式放置，tmp、hostpath和Storagec1asSo其次，如果要备份容器内的数据，如果使用tmp显然不可能，如果是hostpath,需要到指定的节点上去备份，但容器环境中，pod会切换，生产环境不会使用。所以，生产的容器环境数据要备份，必然容器中的数据是storagec1ass,也就是说，要么是分布式存储，要么

16、是集中存储，而这种存储，通常都是多副本的，多副本一般是无须备份的。如果，真的一定要备份，请在容器所涉及应用的逻辑层，进行备份比较合适，比如如果是E1asticsearch,可以用reindex,把索引数据拉到另一个集群。sabotageoxford研发工程师：设计上需要把容器尽可能做的无状态服务，状态保存在外部公共存储池中或云组件里，这样才能实现容器任意调度，迁移，按需扩容缩容。状态包括内存状态（保存在缓存池），数据库（保存在云数据库），文件（保存在分布式文件系统）典型如web服务的session信息，要么存储于公共的kv存储里，要么用类似jwttoken等分布式鉴权，总之需要避免在容器内部保留超过一次交互以外的数据。容器最大优势是便于迁移缩放，部署灵活，带上数据就失去了这个迁