企业级容器持久化存储方案Word下载.docx

企业级容器持久化存储方案Word下载.docx

《企业级容器持久化存储方案Word下载.docx》由会员分享，可在线阅读，更多相关《企业级容器持久化存储方案Word下载.docx（11页珍藏版）》请在冰豆网上搜索。

Q1容器是支持无状态的，为什么要探讨支持有状态的服务？

A：

◆ethan_shen

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

◆weiliang1216

早些时候确实就是只有无状态的，就是个中间件，或者分发等作业。

现在随着app容器化的需求（方便发布，部署等原因），很多app都向着这个方向发展。

因此有状态的服务需求就来了。

既然有需求就有支持咯，所以这块就成了发展的一个方向了

◆Garyy

现在有状态的/无状态的都是支持的。

无状态的，现在可以使用持久化存储来解决数据访问的问题。

Q2当前制约有状态服务向容器化发展的是什么？

◆ 

ethan_shen

我觉得可能是学习成本和商业存储支持吧，存储软件可能要考虑可能应对的SSD集群，以及容器化挂载的频繁，IO控制等。

目前有状态服务容器化的案例不多，大家都在互相谦让“请你先吃螃蟹”，我觉得现在敢吃螃蟹的才是行业的领军企业，时机已经成熟。

weiliang1216

首先我觉得是性价比，目前使用容器的成本还是挺高的，主要是风险与人员上的，因此让大家直接抛弃稳定的传统模式，直接上容器不太可能。

（无状态~无风险，所以很容易上，有状态~风险，大家都谨慎）

其次我觉得是生态问题，vm发展了那么多年，也就最近2、3年大家都开始用vm作为发行体了，容器也有一段漫长的路要走，等吃过螃蟹的人把标准完善了以后，有状态服务自然就会快速发展。

Garyy

构建一个容器平台是面临很多的挑战的。

第一，是所有平台化产品都会面临的问题。

平台化要定标准。

目前来说，容器的标准相对统一（Image、Runtime），但是容器管理平台的标准至少有三家（Kubernetes、DockerSwarm、Mesos）在做，谁能占上风，目前也没有一个绝对的，新的产品和技术可能也会冒出来。

标准不统一，导致大家在使用过程当中，技术选型的时候会有挑战。

第二，容器的技术涉及到资源，涉及到应用内部结构，所以它具有一定的侵入性。

不像是虚拟机，交付完成后，在虚所机内部怎么搞平台就不管了。

容器要关心这个问题，否则就没有办法做模式化了，不做模式化的话，平台的很多东西都没有办法构建了。

第三，大量传统应用需要改造。

运营商市场有几百，上千个应用。

这些应用估计都是几百上千亿的投资，不可能这批应用都不用了，全部改成容器。

而且容器也不是银弹可以解决所有的问题。

传统应用的改造适合什么样的技术，怎么改变，这就是我们非常大的挑战。

这些挑战在我们产品技术选型时，能多多少少都会涉及一些。

Q3以保险行业为例，如何看待企业在容器持久化存储面临的挑战？

保险行业也是对持久化存储非常看重的行业，存储的稳定性，容器服务的稳定性，我想您现在应该有在用商业存储，剩下的就是容器化的稳定服务问题了。

这个问题有点大，我试着回答下。

我觉得大概有几个部分

1.迁移步长，过度期的数据耦合度

作为保险行业，不可能一次性迁移所有业务，必定分批，分阶段执行；

那么这些阶段中业务的连续性，耦合度，拆解方式都需要考量。

对于这一点，需要考虑持久化存储和原有平台的数据交互度，例如：

是否有能力在原有平台上恢复，是否统一命名空间，统一用户权限等等

2.安全性

需要持久化的apps，数据往往是最重要的，因此数据的保护方式很重要。

数据能否安全存放，不同容器间能否共享数据，高可用如何实现，性能如何都需要考量。

3.管理性

无状态容器出了问题大不了就是删除重来。

但含有数据的容器，需要分析更多的内容，包括日志的保存（牵涉到需要哪些执行成功，哪些失败，数据是否一致等），先日志还是先数据，怎么放，放哪，容器失效会不会造成其他Pod的失效，会不会造成更大面积的失效（容器和宿主的底层代码是共享的，容器调用系统的化有可能会造成系统失效）。

还有配额报警，QoS，线上故障排查，服务发现，在线扩容等等问题。

4.数据热迁移

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

5.服务

选择稳定还是性价比始终是个问题。

花钱是愿意在人员上（开源改造，自主'

可控'

），还是服务上也是个问题（商用软件，有人兜底）。

Q4企业在实现容器持久化存储有那几种方案？

方案之间的对比分析？

分别适合在什么场景下？

◆ibmwangfei

实现容器持久化存储的方案很多，所以这个问题比较highlevel，不是很容易回答。

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

1）开源解决方案，比如使用Gluster、Ceph作为容器持久化存储。

开源解决方案的优点是开放、免费，初期尝试成本较低；

缺点是缺乏support，对用户的IT管理人员要求很高，需要能够自己解决其中的一些bug。

2）商业解决方案，各大商业公司提供，例如IBMUbiquity+IBMGPFS或存储设备。

商业解决方案的优点是成熟，技术可靠，有完善的技术支持；

缺点是花费比较高。

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

我这边看到的有三种：

1）分布式存储

可确保数据被每个集群访问，缺点是可能会有网络延迟

2）支持数据复制的本地存储

利用应用级别的数据复制确保数据可被多个节点访问。

优点是无需考虑网络延迟

3）不支持数据复制的本地存储

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

◆邓磊

1、本地存储，缺点是单点故障；

2、开源共享存储，如ceph、gfs，维护对技术要求高，但省钱，目前此方面企业使用比较多；

3、商业存储，缺点是太贵了，没钱不考虑。

Q5对于企业级容器持久化存储方案，开源和商用应该如何选择？

对比优劣如何？

我认为有钱想省心就使用商用，有钱想折腾就使用开源；

没钱就只能使用开源了。

◆Laozhao

其实我个人感觉开源软件定义存储不是很便宜啊，比如一台服务器7万块（包含39TB裸空间），一般软件定义存储采用3副本；

实际可用空间为13TB，平均每TB为5000元左右，非常接近中端存储价格；

性能方面：

软件定义是高带宽、高并发，时延较高；

传统存储：

低时延、高稳定性、高可靠性。

假设不是云计算环境，或者海量数据存储、媒体介质；

个人认为软件定义并无优势；

看规模，规模大到一定程度就要软件化，中小规模还是硬件实在另外，商用软件比开源软件更加稳定，并且有人兜底。

如果不想在人员方面投入太多，商用软件更实在。

首先，要明确商业版本和开源版本的区别：

1）成熟度，商业版本毫无疑问是最稳定最安全的

2）售后，商业版本提供完善的售后支持，开源版本只能依赖自身或者社区的力量；

出了问题，商业版本可以替你“背锅”，开源只能自己想办法解决

3）成本，开源几乎免费，商业版本很贵；

但是开源需要技术人员的开销

所以，综上。

对于大中型企业，IT只是一个支撑系统，无需在IT上耗费技术人员，花一定的钱来满足生产的要求，也有保障；

对于中小型或者创业型的企业，开源的比较好的选择。

考虑企业针对存储和容器化管理的投入，如果决定养人来做我觉得开源可行，开源的众人拾柴火焰高，使用开源最关键的是要可控，毕竟你的业务比机器软件值钱；

使用商用存储可以让你更加专注业务，没必要做一部汽车，就要去研发轮胎，专业的事专业的人来做，术业有专攻，推荐后者。

各位专家的参与和分享，总结下来商用存储在生产中还是大家的主流选择，可以有针对性的技术支持团队，可以让企业更加专注业务发展；

针对开源存储大家觉得还是要有自己的技术团队，以免出现不可控的局面。

Q6对于容器持久化存储，是否有详细案例可进行分享？

容器持久化存储方面我们有过GFSGPFSCephPregData，通过Kubernetes的存储系统实现的，GFSCeph是Kubernetes默认支持的开源存储，GPFS的话需要对接IBM提供的插件，PregData天玑的存储也针对存储插件进行了开发。

我觉得分为两部分：

1、存储，需要查看Kubernetes支持的，私网部署的商用存储基本都不支持，需要通过通用插件来实现对接，这块需要根据不同的厂商有不同的解决方案。

2、持久服务，通过kubernetes的StatefulSet来实现

注意的地方：

1、容器写入数据的数据卷的监控，以免写满。

2、读写模式的选择，一定要对应选择厂家支持的模式。

3、服务状态的监控，最好将服务做成高可用、自愈，包括你的kubernetes管理平台。

以下文档引用可以参考：

1、基于IBMSpectrumScalewithUbiquity容器持久化存储方案

IBMSpectrumScale本身是一个分布式文件系统，其架构设计完全支持高可用，任何一个存储IO节点down掉都不影响数据的访问。

支持快照snapshot、备份以及多数据块副本技术，从而可以很好的实现各种形式灾备。

最新的IBMSpectrumScalev5.0主要有用的新特性包括对object对象存储的支持，实现文件、对象的统一存储管理；

支持数据压缩；

支持transprantcloudtier等。

（1）适用场景

开发测试云、DevOps中数据密集型容器应用

（2）方案特点

oUbiquityVolumePlugin提供容器与文件系统的直接交互能力

o大容量、高性能、易扩展的分布式文件系统

o多节点多副本模式提供高可靠性

o支持多容器并行访问，提供统一的namespace，支持有状态容器的跨物理机在线迁移

o结合SpectrumScale的功能特性（分层、基于policy的自动迁移、AFM/Async-DR等）实现企业级数据管理功能（数据的全生命周期管理、数据备份和灾备等）

o结合SpectrumArchive或SpectrumProtect对接带库或对象存储实现数据的自动化备份归档

o结合容器云平台的高可用能力，实现应用双活

（3）客户收益

o提供高性能、高可靠的容器持久化存储

o支持有状态容器的夸物理机在线迁移

o提供基于存储的企业级数据管理能力

2、基于IBMFlashSystemwithSCBEandUbiquity的容器持久化存储方案

大数据平台、容器云平台中的I/O密集型容器应用

oUbiquityVolumePlugin和SCBE提供容器与块存储直接交互的能力

o支持SpectrumAccelerate和SpectrumVirtualize家族存储产品接入，使用FlashSystem可有效降低I/O响应延迟

oUbiquityVolumePlugin层提供并行访问能力，支持持久卷的在线快速迁移

o结合块存储的功能特性（快照、数据复制、HyperSwap等）实现企业级功能（数据备份、数据灾备及高可用等）

o结合SpectrumControl和容器云平台，提供存储层的使用监控和管理

o也可通过SpectrumScale的分层功能特性实现企业级数据全生命周期管理

o支持大规模容器的快速启动，提供高性能、高可靠的容器持久化存储

Q7IBMSpectrumScalewithUbiquity的工作原理是什么？

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

首先Ubiquity服务端是一个Service，工作在SpectrumScale上或者SpectrumControl，用于Handle来自容器端的请求

其次Ubiquity客户端是一个Container的Plugin，工作在K8S上或者Docker，用于发起请求。

有了这层通信机制之后，容器app使用持久化系统时（文件、目录等）所发起的指令就会被框架捕获，并转移到外部文件系统或者存储的实体空间里。