ethan_shen
作者ethan_shen2017-12-11 13:53
项目经理, 天玑科技

总结-kubernetes企业级容器持久化存储方案设计在线探讨

字数 7902阅读 6517评论 1赞 3

在上期活动中我们针对企业级容器持久化存储方案设计进行了在线探讨,针对商用or开源存储系统、有状态应用、容器发展等话题大家都发表了自己的意见,讨论的核心议题如下:

Q1 企业在实现容器持久化存储有那几种方案?方案之间的对比分析,分别适合在什么场景下?

ibmwangfei 系统工程师 , IBM
实现容器持久化存储的方案很多,所以这个问题比较high level,不是很容易回答。

个人感觉这些方案可以分为两类:

1)开源解决方案,比如使用Gluster、Ceph作为容器持久化存储。开源解决方案的优点是开放、免费,初期尝试成本较低;缺点是缺乏support,对用户的IT管理人员要求很高,需要能够自己解决其中的一些bug。
2)商业解决方案,各大商业公司提供,例如IBM Ubiquity + IBM GPFS 或存储设备。商业解决方案的优点是成熟,技术可靠,有完善的技术支持;缺点是花费比较高。

所以企业应该根据自己IT人员的技术能力、人力资源和资金等综合考虑采用哪一类解决方案。

Garyy 系统架构师 , 大地保险
我这边看到的有三种:

1)分布式存储
可确保数据被每个集群访问,缺点是可能会有网络延迟
2)支持数据复制的本地存储
利用应用级别的数据复制确保数据可被多个节点访问。优点是无需考虑网络延迟
3)不支持数据复制的本地存储

需要静态地为应用预留节点,无法动态创建使用

邓磊 系统运维工程师 , 游戏公司
个人感觉有3种:

1、本地存储,缺点是单点故障;
2、开源共享存储,如ceph、gfs,维护对技术要求高,但省钱,目前此方面企业使用比较多;
3、商业存储,缺点是太贵了,没钱不考虑。

Q2现在保险行业开始逐步推广容器化,容器持久化存储面临的挑战?

当今IT已经从传统集中式管理架构,逐渐转变成分布式架构;从单一的硬件管理,逐渐变成基于软件定义的硬件(主机/存储/网络)管理;从TB级的数据,到PB甚至EB级的海量数据;等等,无一不向我们揭示了一个崭新的IT时代的到来。为了应对这些日新月异的变化,容器服务随着云计算的蓬勃发展逐渐开始崭露头角。容器服务提供高性能可伸缩的容器应用管理服务,支持用Docker和Kubernetes进行容器化应用的生命周期管理,提供多种应用发布方式和持续交付能力并支持微服务架构。容器服务整合了虚拟化、存储、网络和安全能力,打造出最佳的云端的运行环境。

如何持久化保存容器的数据,这是自Docker诞生之日起就一直存在的问题。在Docker的初始设计中,数据与容器共生共灭,人们很难把容器从一台机器迁移到另一台机器。时至今日,存储的发展和变革给了容器持久化存储以多种多样的解决之道。

Q3 保险行业选择持久化存储面临的问题有哪些?

ethan_shen 项目经理 , 天玑科技
保险行业也是对持久化存储非常看重的行业,存储的稳定性,容器服务的稳定性,我想您现在应该有在用商业存储,剩下的就是容器化的稳定服务问题了.

weiliang1216 it技术咨询顾问 , IBM
这个问题有点大,我试着回答下。

我觉得大概有几个部分
1.迁移步长,过度期的数据耦合度
作为保险行业,不可能一次性迁移所有业务,必定分批,分阶段执行
那么这些阶段中业务的连续性,耦合度,拆解方式都需要考量
对于这一点,需要考虑持久化存储和原有平台的数据交互度,
例如:是否有能力在原有平台上恢复,是否统一命名空间,统一用户权限等等

2.安全性
需要持久化的apps,数据往往是最重要的,因此数据的保护方式很重要
数据能否安全存放,不同容器间能否共享数据,高可用如何实现,性能如何都需要考量

3.管理性
无状态容器出了问题大不了就是删除重来
但含有数据的容器,需要分析更多的内容,包括日志的保存(牵涉到需要哪些执行成功,哪些失败,数据是否一致等),先日志还是先数据,怎么放,放哪,容器失效会不会造成其他Pod的失效,会不会造成更大面积的失效(容器和宿主的底层代码是共享的,容器调用系统的化有可能会造成系统失效)。还有配额报警,QoS,线上故障排查,服务发现,在线扩容等等问题。

4.数据热迁移
业务在不同地方运行,必然会考虑到数据迁移问题,对于像保险行业这样重要的金融体来说,停机维护的时间自然是要尽可能短,那么在业务迁移的时候,无论上迁还是下迁,都是希望热迁移,那么热迁移也有很多注意事项,数据同步性一致性,业务延续性,切换问题,权限问题等等。

5.服务
选择稳定还是性价比始终是个问题。
花钱是愿意在人员上(开源改造,自主'可控'),还是服务上也是个问题(商用软件,有人兜底)。

Q4 对于企业级容器持久化存储方案,开源和商用应该如何选择?对比优劣如何?

邓磊 系统运维工程师 , 游戏公司
我认为有钱想省心就使用商用,有钱想折腾就使用开源;没钱就只能使用开源了。

Laozhao 存储工程师 , 中体彩
其实我个人感觉开源软件定义存储不是很便宜啊,比如一台服务器7万块(包含39TB裸空间),一般软件定义存储采用3副本;实际可用空间为13TB,平均每TB为5000元左右,非常接近中端存储价格;性能方面:软件定义是高带宽、高并发,时延较高;传统存储:低时延、高稳定性、高可靠性。假设不是云计算环境,或者海量数据存储、媒体介质;个人认为软件定义并无优势;

评论:weiliang1216
看规模,规模大到一定程度就要软件化,中小规模还是硬件实在 另外,商用软件比开源软件更加稳定,并且有人兜底。 如果不想在人员方面投入太多,商用软件更实在。

韩斐 技术经理 , 汉中供电局
传统存储:低时延、高稳定性、高可靠性。

ethan_shen 项目经理 , 天玑科技
考虑企业针对存储和容器化管理的投入,如果决定养人来做我觉得开源可行,开源的众人拾柴火焰高,使用开源最关键的是要可控,毕竟你的业务比机器软件值钱;使用商用存储可以让你更加专注业务,没必要做一部汽车,就要去研发轮胎,专业的事专业的人来做,术业有专攻,推荐后者。

Garyy 系统架构师 , 大地保险
首先,要明确商业版本和开源版本的区别:

1)成熟度,商业版本毫无疑问是最稳定最安全的
2)售后,商业版本提供完善的售后支持,开源版本只能依赖自身或者社区的力量;出了问题,商业版本可以替你“背锅”,开源只能自己想办法解决
3)成本,开源几乎免费,商业版本很贵;但是开源需要技术人员的开销

所以,综上。对于大中型企业,IT只是一个支撑系统,无需在IT上耗费技术人员,花一定的钱来满足生产的要求,也有保障;对于中小型或者创业型的企业,开源的比较好的选择。

Q5 对于容器持久化存储,是否有详细案例可进行分享?

ethan_shen 项目经理 , 天玑科技
容器持久化存储方面我们有过GFS GPFS Ceph PregData,通过Kubernetes的存储系统实现的,GFS Ceph是Kubernetes默认支持的开源存储,GPFS的话需要对接IBM提供的插件,PregData天玑的存储也针对存储插件进行了开发。

我觉得分为两部分:
1、存储,需要查看Kubernetes支持的,私网部署的商用存储基本都不支持,需要通过通用插件来实现对接,这块需要根据不同的厂商有不同的解决方案。
2、持久服务,通过kubernetes的StatefulSet来实现

注意的地方:
1、容器写入数据的数据卷的监控,以免写满。
2、读写模式的选择,一定要对应选择厂家支持的模式。
3、服务状态的监控,最好将服务做成高可用、自愈,包括你的kubernetes管理平台。

Garyy 系统架构师 , 大地保险
可以参考:
3.3.1、基于IBM Spectrum Scale with Ubiquity容器持久化存储方案

IBM Spectrum Scale本身是一个分布式文件系统,其架构设计完全支持高可用,任何一个存储IO节点down掉都不影响数据的访问。支持快照snapshot、备份以及多数据块副本技术,从而可以很好的实现各种形式灾备。

最新的IBM Spectrum Scale v5.0 主要有用的新特性包括对object对象存储的支持,实现文件、对象的统一存储管理;支持数据压缩;支持transprant cloud tier等。

(1)适用场景
开发测试云、DevOps中数据密集型容器应用

(2)方案特点
λ Ubiquity Volume Plugin提供容器与文件系统的直接交互能力
λ 大容量、高性能、易扩展的分布式文件系统
λ 多节点多副本模式提供高可靠性
λ 支持多容器并行访问,提供统一的namespace,支持有状 态容器的跨物理机在线迁移
λ 结合Spectrum Scale的功能特性(分层、基于policy的自 动迁移、AFM/Async-DR等)实现企业级数据管理功能 (数据的全生命周期管理、数据备份和灾备等)
λ 结合Spectrum Archive或Spectrum Protect对接带库或对象存储实现数据的自动化备份归档
λ 结合容器云平台的高可用能力,实现应用双活

(3)客户收益
λ 提供高性能、高可靠的容器持久化存储
λ 支持有状态容器的夸物理机在线迁移
λ 提供基于存储的企业级数据管理能力

3.3.2、基于IBM FlashSystem with SCBE and Ubiquity的容器持久化存储方案
(1)适用场景
大数据平台、容器云平台中的I/O密集型容器应用

(2)方案特点
λ Ubiquity Volume Plugin和SCBE提供容器与块存储直接交互的能力
λ 支持Spectrum Accelerate和Spectrum Virtualize家族存 储产品接入,使用FlashSystem可有效降低I/O响应延迟
λ Ubiquity Volume Plugin层提供并行访问能力,支持持久卷的在线快速迁移
λ 结合块存储的功能特性(快照、数据复制、HyperSwap等) 实现企业级功能(数据备份、数据灾备及高可用等)
λ 结合容器云平台的高可用能力,实现应用双活
λ 结合Spectrum Control和容器云平台,提供存储层的使用 监控和管理
λ 也可通过Spectrum Scale的分层功能特性实现企业级数据全生命周期管理

(3)客户收益
λ 支持大规模容器的快速启动,提供高性能、高可靠的容器持久化存储
λ 支持有状态容器的夸物理机在线迁移
λ 提供基于存储的企业级数据管理能力

Q6 容器是支持无状态的,嘉宾为什么说支持有状态的服务?

ethan_shen 项目经理 , 天玑科技
无状态容器会更加的简单,在应对高并发的时候快速扩缩非常方便,但我们不能前面中间件做了容器,到了数据方面我们就只能像烟筒似的堆队列、加缓存、做分片、加SSD集群不断的去提高读写性能来应对,现在已经有一些有状态服务的容器案例,虽不多,但这是在发展的一块内容

weiliang1216 it技术咨询顾问 , IBM
早些时候确实就是只有无状态的,就是个中间件,或者分发等作业。
现在随着app容器化的需求(方便发布,部署等原因),很多app都向着这个方向发展。
因此有状态的服务需求就来了。
既然有需求就有支持咯,所以这块就成了发展的一个方向了

Garyy 系统架构师 , 大地保险
现在有状态的/无状态的都是支持的。
无状态的,现在可以使用持久化存储来解决数据访问的问题。

韩斐 技术经理 , 汉中供电局
现在随着app容器化的需求(方便发布,部署等原因),很多app都向着这个方向发展。

非常感谢各位专家的参与和分享,总结下来商用存储在生产中还是大家的主流选择,可以有针对性的技术支持团队,可以让企业更加专注业务发展;针对开源存储大家觉得还是要有自己的技术团队,以免出现不可控的局面。在容器发展上大家都有各抒己见,有状态容器还是大家比较关注的,也非常看好容器未来的发展。

我的分享中提到的IBM GPFS大家也非常关注如何来使用它,IBM的专家也进行了非常详细的解答:

Q1 IBM Spectrum Scale with Ubiquity的工作原理是什么?

IBM Spectrum Scale本身是一个分布式文件系统,其架构设计完全支持高可用,任何一个存储IO节点down掉都不影响数据的访问。支持快照snapshot、备份以及多数据块副本技术,从而可以很好的实现各种形式灾备。

能否详细描述其工作原理,适用场景,以及相应的reference?

ethan_shen 项目经理 , 天玑科技
Ubiquity-k8s就像一个客户端和服务器端,客户端我们部署在kubernetes node上,服务器端就是Spectrum Scale,配置好了就可以使用,具体的IBM Spectrum Scale的工作原理还是要详细参考IBM官网和IBM的github

weiliang1216 it技术咨询顾问 , IBM
首先Ubiquity服务端是一个Service,工作在Spectrum Scale上或者Spectrum Control

微信图片_20171211135454.png

微信图片_20171211135454.png

用于Handle来自容器端的请求

其次Ubiquity客户端是一个Container的Plugin,工作在K8S上或者Docker,用于发起请求。
有了这层通信机制之后,容器app使用持久化系统时(文件、目录等)所发起的指令就会被框架捕获,并转移到外部文件系统或者存储的实体空间里

具体的捕获以及转发可以参考
https://github.com/IBM/ubiquity

从提问来看网络、IO方面的限制也是大家非常关心的一部分内容,下面是一些相关的议题:

Q1 docker如何对存储的使用量,IOPS,网络带宽 ,共享内核等资源进行灵活控制和隔离?

邓磊 系统运维工程师 , 游戏公司
存储方面与iops可以使用qos方面,带宽可以使用tc或ovs等限制方式,内核与内存就是cgroup和namespace。

Q2 k8s防火墙如何做?

ethan_shen 项目经理 , 天玑科技
推荐先关闭端口,部署完了看nodeport端口再打开对应的端口,默认端口是30000-32767,也可以打开防火墙后放开这些端口。

可以根据您的应用安全登记要求进行不同的设置,全关逐个端口放开,或放开默认的端口范围,或关闭防火墙,最好还是有负载均衡接内网nodeport来对外服务

Q3 动态调整pod带宽?

weiliang1216 it技术咨询顾问 , IBM
貌似现在还没有简单动态调整pod的方法,可以自己写代码实现
或者等k8s把这个功能实现出来
从几个大论坛上了解到有些团体已经在做这块功能,个别的今年7月的时候有个alpha版本了

ethan_shen 项目经理 , 天玑科技
kubernetes的调度器目前没有对Pod进行带宽限制,可以在service的上层使用istio再封装一层对带宽进行设置,如果想让使用者无感的话,这一块需要基于Kubernetes进行开发,如果使用yaml文件是无法做到的,kubernetes也在将来会对这块需求进行满足。可以参考
https://istio.io/docs/tasks/policy-enforcement/rate-limiting.html
https://github.com/kubernetes/kubernetes/issues/2856

对于容器管理系统kubernetes大家也是寄予了厚望,希望kubernetes下一步可以在网络、IO等方面进行限制。

最后收录几个容器管理和部署的一些问题,可以帮助大家更快的加入容器生产的行列,加速发展自己的业务,提出你容器持久化存储遇到的问题,大家互相交流互相进步:

Q1 容器化部署中间件相较于自动化程度非常高的传统方式部署中间件的颠覆性优势到底在哪里?

ethan_shen 项目经理 , 天玑科技
容器化的优势在于快速创建快速销毁,就像双十一这中恐怖的高并发下,容器化是必要的,秒级创建,当峰值一过就可以快速释放掉资源,可以快速的“拆东墙补西墙”、“再把东墙还回去”,自动化程度非常高物理机、虚拟机的部署都无法超越容器带来的更加便利,超越容器化的我猜可能就是serverless了,但还不够成熟,现在是拥抱容器红利非常好的时期。

Q2 假设在k8s环境中有tomcat容器 ,tomcat的pod如何访问原始数据库?

假设在k8s环境中有tomcat容器 ,tomcat的pod如何访问原始数据库,他们之间的网络一个是传统网络,一个是k8s内置集群网络,如何配置?tomcat服务暴露出去后,f5如何访问?

邓磊 系统运维工程师 , 游戏公司
得看你k8s使用什么网络,如果是host或ovs等,可以与传统网络访问的。
前端负载均衡想访问后端服务,要不是使用Nodeport方式,否则使用clusterip方式,就得让f5能接入k8s集群网络。

ethan_shen 项目经理 , 天玑科技
在kubernetes 中pod之间可以通过serviceName进行访问,也可以配置使用kube-DNS使用handLess service设置的域名访问,访问数据库有两种方式:一是直接连接数据库所在物理服务器IP,另一种方式就是借助k8s的Endpoints直接将外部服务器映射为kubernetes内部的一个服务。

Q3 能否聊一下当前制约有状态服务向容器化发展的是什么?

ethan_shen 项目经理 , 天玑科技
我觉得可能是学习成本和商业存储支持吧,存储软件可能要考虑可能应对的SSD集群,以及容器化挂载的频繁,IO控制等。
目前有状态服务容器化的案例不多,大家都在互相谦让“请你先吃螃蟹”,我觉得现在敢吃螃蟹的才是行业的领军企业,时机已经成熟。

weiliang1216 it技术咨询顾问 , IBM
首先我觉得是性价比,目前使用容器的成本还是挺高的,主要是风险与人员上的,因此让大家直接抛弃稳定的传统模式,直接上容器不太可能。(无状态~无风险,所以很容易上,有状态~风险,大家都谨慎)
其次我觉得是生态问题,vm发展了那么多年,也就最近2、3年大家都开始用vm作为发行体了,容器也有一段漫长的路要走,等吃过螃蟹的人把标准完善了以后,有状态服务自然就会快速发展。

Garyy 系统架构师 , 大地保险
构建一个容器平台是面临很多的挑战的。
第一,是所有平台化产品都会面临的问题。平台化要定标准。目前来说,容器的标准相对统一(Image、Runtime),但是容器管理平台的标准至少有三家(Kubernetes、Docker Swarm、Mesos)在做,谁能占上风,目前也没有一个绝对的,新的产品和技术可能也会冒出来。标准不统一,导致大家在使用过程当中,技术选型的时候会有挑战。

第二,容器的技术涉及到资源,涉及到应用内部结构,所以它具有一定的侵入性。不像是虚拟机,交付完成后,在虚所机内部怎么搞平台就不管了。容器要关心这个问题,否则就没有办法做模式化了,不做模式化的话,平台的很多东西都没有办法构建了。

第三,大量传统应用需要改造。运营商市场有几百,上千个应用。这些应用估计都是几百上千亿的投资,不可能这批应用都不用了,全部改成容器。而且容器也不是银弹可以解决所有的问题。传统应用的改造适合什么样的技术,怎么改变,这就是我们非常大的挑战。这些挑战在我们产品技术选型时,能多多少少都会涉及一些。

wuwenpin 软件开发工程师 , 南京南瑞
安全、可靠是关键!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论1 条评论

wuwenpinwuwenpin软件开发工程师, 南京
2017-12-12 10:07
不错的资料
Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

相关文章

相关问题

相关资料

X社区推广