Garyy
作者Garyy2017-11-30 15:06
系统工程师, 某保险

容器持久化存储必要性分享总结

字数 11584阅读 2929评论 1赞 9

1、问题:基本概念的区别:对象存储,云对象存储,分布式对象存储,分布式存储,云存储?
一、在互联网技术推动下,当前存储技术迅猛发展,这样也造就了很多概念,那么如下概念的区别是什么:对象存储、云对象存储、分布式对象存储、分布式存储、云存储等?

二、是不是可以从以下几个方面来梳理:
1)块存储(传统)、文件存储(传统)、对象存储(现代)?
2)集中式存储(传统)、分布式存储(现代)?
3)非云存储、云存储?
......

1)数据结构上
a。 块存储,数据保存格式是010101(两进制),速度快(扩展能力弱一些)
b。 文件存储,数据保存格式是文件,基于文件系统,速度中等(随着文件变多速度下降),一般是树状结构
c。 对象存储,数据保存格式是Key/Value,速度中下(随着文件变多,速度变化不明显)
2)物理结构上
Scale up和Scale out其实起源都挺早,所以也不能说分布式就是现代的。
只是随着大数据的兴起,传统存储在容量上了PB以后后劲不足(磁盘容量限制),开始考虑分布式补充。
本质上都是堆硬件,只是保障体系不同,分布式通过软件保证一致性和可用可靠性。
垂直存储的有通过硬件+软件的方式保证一致性和可用可靠性。
选择上还是看瓶颈问题
3)云和非云就仁者见仁了
数据需要灵活性,需要成本低,保密度不高,可靠度要求不高都可以用云存储,说白了就是别人搭好环境你去租,好处就是规模效应带来的成本下降,反过来个性化(特殊需求),排错性(问题定位),可控性(故障修复时间)等就差一点。

2、问题:对象数据适合放在云中、容器云中存储,那么块数据、文件数据是否也适合放在云中、容器云中存储?
这个问题其实在于:云储存的应用场景?块?对象?还是文件?
其实,从技术上来讲,这三块都是支持的。
目前,块存储/对象存储使用更加广泛。
从金融保险行业看来,传统存储在其关键业务上的地位还是不可动摇;在备份、归档这类冷数据,对象存储已经占据很大的份额;文件存储目前,不管是GPFS/GFS/CephFS都没有能够撼动 NFS的地位。

3、问题:对象数据放在物理机、VM、docker上持久化存储的差异在哪?
放物理机等同于直接放磁盘(内部或者外部)
放VM,有两种,看你是用穿透的放法还是统一管理的,第一种类似与放磁盘,但失去很多VM的功能,第二种实际上是嵌入到了一个文件中。
docker的持久化存储,数据是通过volume plugin落在磁盘上的,是API提供了一个通道,让数据可以写磁盘

4、 问题:什么是容器持久化存储?容器持久化存储的趋势?会带来哪些优势,以及会带来哪些潜在的风险点?
容器持久化数据卷:在容器中运行的应用,应用真正需要保存的数据,可以写入持久化的Volume数据卷。在这个方案中,持久层产生价值,不是通过弹性,而是通过灵活可编程,例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。
Docker发布了容器卷插件规范,允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准,就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装,从而实现和Docker容器的对接。可以说,驱动程序实现了和容器引擎的北向接口,底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中,后端存储包括常见的NFS,GlusterFS和块设备等。
趋势上,随着有状态容器的使用率变高,持久化就会会变成一项必须的内容。
这个技术本身谈不上优势,只能说是一种需要。
至于风险,从设计原理上应该是几乎没有风险的,但程序的事情没人敢保证100%,因此增加的一个和硬件沟通的间接渠道相当于打开了一扇门,是不是有什么潜在的Bug就不好说了

5、问题:文件系统存储、块存储和对象存储,三种存储系统实现容器持久存储对比?
这个和标准的文件系统,块,对象在使用上的差别是类似的。
块比较快,扩展弱,价格贵
文件系统性能中等,扩展强,价格中等,分布式环境可用
对象性能弱,扩展极强,价格低,一般都是分布式环境的,或者云的。
所以从实现上是没多大区别的,只要Driver支持。
目前看来,块存储的应用最为广泛,主要是块存储的技术储备最多,并且广泛使用
对象存储次之,现在object存储基于S3 / swift/ OSS接口,随着公有云的普及,被广泛使用。
文件存储,目前还是NAS传统存储的天下,性能和可靠性最为稳定。cephFS目前还是不足以满足生产环境的使用

6、问题:如何解决Docker的持久化存储问题?如何连接数据与Docker容器?
容器持久化数据卷:在容器中运行的应用,应用真正需要保存的数据,可以写入持久化的Volume数据卷。在这个方案中,持久层产生价值,不是通过弹性,而是通过灵活可编程,例如通过设计的API来扩展存储。这个方案结合了持久层和或纯云原生设计模式。
Docker发布了容器卷插件规范,允许第三方厂商的数据卷在Docker引擎中提供数据服务。这种机制意味着外置存储可以超过容器的生命周期而独立存在。而且各种存储设备只要满足接口API标准,就可接入Docker容器的运行平台中。现有的各种存储可以通过简单的驱动程序封装,从而实现和Docker容器的对接。可以说,驱动程序实现了和容器引擎的北向接口,底层则调用后端存储的功能完成数据存取等任务。目前已经实现的Docker Volume Plugin中,后端存储包括常见的NFS,GlusterFS和块设备等。

7、问题:Docker与Hypervisor有哪些不同?
过去容器和hypervisor经常被放在一起进行对比,但是现在开发人员正在尝试改变这种现状,希望找到一种方法将两种技术的特点相互融合。
大多数人喜欢将虚拟化技术的两种主要实现方式——容器和hypervisor——以对比的方式进行讨论。这种思路将容器和hypervisor放在对立面上,选择容器或是在实际环境中,容器和hypervisor不仅仅是竞争关系,不应该简单地将其拿来对比。事实上,容器和hypervisor能够共存,甚至相互促进对方发展。
容器技术的最大意义在于其不需要同时使用多个操作系统,而在hypervisor虚拟化环境当中每台虚拟机都需要使用独立的操作系统。显而易见,这种方式能够大幅度降低系统开销所占用的内存,能够为应用及其数据预留更多的空间。
使用容器技术能够节约大量操作系统所占用的内存空间。通常相比于hypervisor,使用容器能够在同一台服务器当中创建三倍的实例数量。在某些情况当中,比如完全一样的虚拟桌面,实例数量能够达到之前的十倍。从另外一个角度来说,特定负载所需的服务器数量也就大幅降低了。授权部分也会受到影响,企业只需要为每台服务器购买一个授权。由于应用成为共享镜像的一部分,因此也能够从中获益。
容器提升性能和安全性
容器技术还能够带来其他好处。相比于hypervisor,其启动速度更快,主要是因为镜像不需要从头进行加载。镜像具有更好的可移植性并且更加易于部署,因此能够在运营过程中为部署和敏捷性带来很大帮助。此外,测试报告显示相比于传统hypervisor,容器在完成某些特定任务方面具有很大的性能优势,最多只需要使用原有时间的15%。
容器技术拥有如此多的优势,以至于很多人不太理解除了行业内的保守派之外,容器技术为什么还没有完全取代原有hypervisor。毕竟,Docker在这个行业当中拥有很强的领导能力,并且容器技术也已经基本成熟。
容器是一种全新技术,并且正在快速发展。而与之对比的hypervisor则更加成熟,并且已经通过市场的证明。其在安全性方面不断加固,并且x86 VTx架构为其提供了硬件辅助,因此想要实现跨租户间的袭击几乎是不可能的。相对来说有人质疑容器更加脆弱,攻击者可能袭击底层操作系统,进而控制服务器当中的所有实例。
由此产生的结果是容器通常被运行在hypervisor之上。每个租户的容器实例都被隔离在单独的虚拟机当中,这样就能够实现硬件保护,防止遭遇跨租户袭击。这种方式的缺点也十分明显。不仅更加复杂,而且还会涉及hypervisor代码以及操作系统拷贝等授权问题,并且影响性能,甚至是失去敏捷性——但是至少实例是安全的。
但是现在容器生态系统已经能够应付这种局面。一些Thin hypervisor,比如英特尔的Clear Container,就是被设计用来保护容器并且合理利用硬件——不会占用大量空间或者过度影响系统性能表现。其他一些安全改进——特别是在镜像证明和认证方面——意味着容器已经能够弥补和hypervisor在安全性方面的差距了。
Hypervisor如何回应
Hypervisor开发者也并不清闲。尽管最初他们否认容器会对其带来威胁,但是最终还是开始应对容器技术所带来的各种威胁可能性。比如,VMware使用内存页面去重复化技术来降低内存使用量,这种技术能够替换整个内存页面,将所有重复内容都指向同一个内存地址。这种方式能够有效降低负载,但是hypervisor的运行速度依然无法和容器相提并论。在运营过程中还可以通过其他方式来实现平衡。内存页面去重复化技术能够进一步演变,比如针对已经加载的镜像创建索引,针对已经在系统当中的文件进行检查。这种方式不会带来任何额外负载,能够大幅度提升去重复化速度。我们想要将现在的hypervisor和未来的容器进行对比,表明hypervisor虚拟化并没有停滞不前。
除了内存和性能问题之外,两种解决方案的应用领域也各不相同。对于那些需要进行大规模扩展、但是几乎不会相互影响——至少不会直接相互影响——的任务来说,使用容器更加合适。比如,容器技术能够很好地满足Web服务以及微服务的需求,如果能够对容器进行恰当配置,那么其还能够在云中发挥重要作用。
相比于容器,hypervisor更加适用于那些规模庞大的独立应用,管理员能够更好地控制和应用相关的网络和存储架构,由于这些大型应用通常都被用来执行一些关键任务,因此节约资源和启动时间并不是其主要考虑因素——特别是和潜在的故障时间或者安全隐患相比。
科学计算,几年之前刚刚进入虚拟化领域,已经在很大程度上提升了生产力。这些工具通常都会根据当前环境进行调整,因此更加适合于复杂任务。
至于成本因素,应用和操作系统授权方式还需要进行不断调整,这样才能使得所有用户都能够负担的起虚拟化的价格,不论选择使用哪种虚拟化方式。每个实例每分钟的收费方式也许将会成为最终标准。
凭借现有的强大生态系统以及庞大的用户群体,hypervisor还将会在IT领域发挥重要作用。在容器和hypervisor的竞争当中,只有当hypervisor设计者不再进行回应的的时候,容器才有可能成为最终的胜利者,但是这几乎是不可能的。事实上,未来最有可能的发展方向就是hypervisor和容器技术相互融合,至少在特性和优势方面。那些现在已经非常依赖于hypervisor基础架构的IT部门也许希望继续使用这种方式,比如使用简化的hypervisor实例或者在hypervisor实例当中使用容器。另一方面,全新安装的企业最有可能会直接使用Docker或者其他方案。对应用进行分类也是一种可行方案,hypervisor虚拟化更加适用于庞大的单一应用。

8、问题:容器如果重启后数据是可以保留的话为什么还需要容器的持久化?
docker里的数据不做持久化的话数据是不保留的。所有的数据都是临时的,关了或者重启都会让数据丢失
如何持久化保存容器的数据,这是自Docker诞生之日起就一直存在的问题。在Docker的初始设计中,数据与容器共生共灭,人们很难把容器从一台机器迁移到另一台机器。时至今日,存储的发展和变革给了容器持久化存储以多种多样的解决之道。
容器架构使用到三种类型的存储:
第一是镜像存储。这可以利用现有的共享存储进行交付,要求类似于服务器虚拟化环境中虚拟机镜像分发保护的平台架构。容器镜像的一项好处在于其存储容量相较于完整的虚拟机镜像小了许多,因为它们不会复制操作系统代码。此外,容器镜像的运行在设计之初便是固定的,因此可以更高效地存储、共享。但也因此,容器镜像无法存储动态应用程序的数据。
第二类需要存储的数据是容器的管理。当然,可以借助现有存储完成这项工作。不论使用Docker、Kubernetes、Tectonic、Rancher还是其它类型的容器管理,都需要存储配置数据、日志记录等管理数据。
第三类存储,容器应用的存储,是最具挑战的。只有支持真正的微服务式编程时,容器代码可以直接写入镜像目录和文件。但是容器使用一种分层文件系统,将所有新写入的数据存储在临时虚拟层,最底层的容器镜像却未被修改。一旦容器消失——相比虚拟机,容器的设计寿命更短——所有的临时存储都会随之消散。
Docker等容器管理产品提供可插拔的卷管理。例如Flocker是开源Docker可插拔卷中的最受欢迎的替代品,可以通过集群智能管理、迁移数据卷及其容器。大多数传统存储供应商和云存储服务提供商为其存储阵列生成各类容器系统卷插件,就是很好的顺应了时代的发展。

9、问题:容器有无ubiquity volume plugin的区别?
所谓Plugin就是一个插件,按照Docker的定义:
Docker plugins are out-of-process extensions which add capabilities to the Docker Engine.
就是增强了Docker的功能。
如果你用过浏览器的插件(比如Flash,有了Flash你能看Flash的片子,没有就不能看,有了Java的插件你能运行Applet,没有就运行不了),其相似度是类似的。

10、问题:docker容器在不同机器上如何实现数据迁移?
迁移容器和镜像
export与import命令使用:
export导出容器会丢失历史记录和元数据,类似与快照
先创建测试容器:
$ sudo docker exec web touch /opt/test.txt
$ sudo docker exec web ls /opt
test.txt
执行导出:
$ sudo docker export web > web.tar
执行导入:
$ cat web.tar | sudo docker import - web:v2
$ sudo docker images
wKiom1aHmtuhyu9UAAAHiNrmLo0553.png$ sudo docker run -itd --name web_v2 web:v2 /bin/bash
启动这个镜像要加/bin/bash,否则报错Error response from daemon: No command specified
$ sudo docker exec web_v2 ls /opt
test.txt
总结:通过export命令也可以将容器里的数据保存,并可以迁移到别的docker主机
save与load命令使用:
一般用于迁移镜像到别处
导出:
$ sudo docker save web > web.tar
导入:
$ sudo docker load < ubuntu.tar
注:不会丢弃历史记录和元数据,并可以回滚版本。启动不用加/bin/bash

11、问题:docker能否实现mysql postgresql等数据库的持久化?
当然可以,和我们常用的持久化存储一样,和标准持久化一样处理

12、问题:Docker容器如何帮助构建高可用的解决方案?
docker就是一个工具,要想落地成为一套解决方案,还需要很多组件来集成。

K8就是一个比不可少的集群管理软件,此外还有很多资源分配调度的、服务注册以及调度的、监控调度等等。看什么业务场景,根据特定场合进行组合。
docker本身是一个开源的工具,由docker社区负责维护,它的高可用解决方案,不是由一个或者几个docker容器就能解决的,需要有其他的软件或者硬件一起来配合。
从硬件层面的高可用,包含主机/存储/网络
从软件层面的高可用,容器本身,例如k8s本身的运行机制就能保证容器集群的高可用
从容器内部运行的应用看来,需要有一些监控和pacemaker之类的HA软件来保证

13、问题:Docker Volume Plugin的原理和机制分析?
Docker Plugin其实是一种API.
包括Plugin的发现,描述,套接字,握手协议等。
具体的细节在Docker的官网上有描述,可以参考(不过是英文的)
支持的厂家有IBM,EMC,Netapp,Veritas等

因为应用数据对安全,可用性,共享,性能等方面的要求和Root Image的要求完全不一样,所以Docker并不推荐采用Root Image的存储方式来存储应用数据,而是采用了Volume这样一个独立的数据访问接口。应用通过Volume去访问相关的数据,Volume的实现和CoW的分层文件系统完全独立,通过Volume plugin机制可轻易驱动外部存储。
(1) Docker Daemon对Volume的管理
Docker Daemon结构中有个成员Volumes,类型是VolumeStore类型,包含一组管理Volume的函数:Create、Remove、List、Get、Refs ...。通过两个变量,管理Container和Volume的关系。 names : map结构,Key是Volume的name,value是实现Volume接口的结构对象。存储该Daemon内所有的Volume。 ReFS: map结构,key是volume的name,value是string数组保存引用该Volume的Container ID。 Docker Daemon通过Volumes变量,就可以管理所有的Volume。
(2) Docker Volume的管理
Docker提供两个接口Volume和Driver,所有提供给Docker使用的Volume必须实现Volume接口。后端驱动需要实现Driver接口。Driver是对提供出去的Volume进行管理。目前Docker实现了两种Volume &Drive。
(2.1)基于本地文件系统的Volume
可以在执行Docker create或Docker run时,通过-v参数将主机的目录作为容器的数据卷。这部分功能便是基于本地文件系统的volume管理。上图中蓝色部分LocalVolume和Root。这两个结构就是对主机目录和文件进行管理
(2.2)适配Plugin的volume
Docker为了支持第三方存储方案,在1.8版本引入Volume Plugin机制,Volume Adapter和Volume Driver Adapter分别实现了接口Volume和Driver接口,用于表示由Plugin提供的Volume和Plugin driver。
(3) Docker Plugin实现原理
Volume Driver Adapter : 实现Driver接口,用于抽象各种Plugin的驱动,该类型可以适配所有符合规范的Volume Plugin,对Plugin进行管理。 Volume Adapter : 实现Volume接口,用于抽象所有Plugin提供的Volume,该类型可以适配所有符合规范的Volume Plugin提供的类型,对Volume进行管理。 通过抽象,对于Plugin和其提供的Volume,Docker Daemon结构和Container结构使用上述两个适配类型,对Plugin和Volume进行管理和使用。
发现步骤: Docker Daemon首先会在/run/docker/plugins搜索对应的套接字文件,套接字文件名必须和Volume Driver名一致,如上述命令,便是搜索convoy.sock。 如果上一步搜索不到,则到/etc/docker/plugins和/usr/lib/docker/plugins两个目录搜索spec或json文件。文件中指定套接字文件的URL。如:unix:///var/run/convoy/convoy.sock 。 根据前面两步发现的Unix域套接字URL,构建Plugin对象,并将新建对象加入到全局变量storage的Plugins字段中。

14、问题:Docker容器关闭后,容器产生的数据还在磁盘上吗?
如何持久化保存容器的数据,这是自Docker诞生之日起就一直存在的问题。在Docker的初始设计中,数据与容器共生共灭,人们很难把容器从一台机器迁移到另一台机器。时至今日,存储的发展和变革给了容器持久化存储以多种多样的解决之道。
容器架构使用到三种类型的存储:
第一是镜像存储。这可以利用现有的共享存储进行交付,要求类似于服务器虚拟化环境中虚拟机镜像分发保护的平台架构。容器镜像的一项好处在于其存储容量相较于完整的虚拟机镜像小了许多,因为它们不会复制操作系统代码。此外,容器镜像的运行在设计之初便是固定的,因此可以更高效地存储、共享。但也因此,容器镜像无法存储动态应用程序的数据。
第二类需要存储的数据是容器的管理。当然,可以借助现有存储完成这项工作。不论使用Docker、Kubernetes、Tectonic、Rancher还是其它类型的容器管理,都需要存储配置数据、日志记录等管理数据。
第三类存储,容器应用的存储,是最具挑战的。只有支持真正的微服务式编程时,容器代码可以直接写入镜像目录和文件。但是容器使用一种分层文件系统,将所有新写入的数据存储在临时虚拟层,最底层的容器镜像却未被修改。一旦容器消失——相比虚拟机,容器的设计寿命更短——所有的临时存储都会随之消散。
Docker等容器管理产品提供可插拔的卷管理。例如Flocker是开源Docker可插拔卷中的最受欢迎的替代品,可以通过集群智能管理、迁移数据卷及其容器。大多数传统存储供应商和云存储服务提供商为其存储阵列生成各类容器系统卷插件,就是很好的顺应了时代的发展。

15) 问题:docker挂载目录到容器后对目录的改变会不会影响容器?
Docker挂载的是Volume,如果是用NFS挂在的,那么目前看对容器本身没什么影响,但是对容器中的应用有影响(数据变了,应用会不会有问题不好说)容器对文件系统的应用是可以隔离的(AUFS)

16) 问题:Docker中,如何通过Volume实现持久化存储和数据共享?
Volume Mapping给Docker后就像一个文件系统一样,Docker直接写这个Volume就可以了。
数据共享的话可以让一个Volume mapping给多个容器。

17、问题:虚拟机有逃逸,容器是否也有这类问题?
容器的逃逸可以理解为容器的高可用,像k8s中,就有一个机制来保障,当一个容器故障了,集群监测到之后,就会根据其之前制定的策略,启动一个新的容器代替之。
如果说是容器内部应用的高可用,那么只能依靠一些高可用软件,例如powerVC,suse ha,vertias等

18、问题:如何确保Docker容器在运行过程中的数据变化,被更新到原容器镜像?
Docker本身和VM不一样,不是一个单独的载体,而是多个载体的合并。
Docker在运行的时候是从镜像分离出来一个副本进行运行的。
一般情况下Docker中的数据变化是不会保存下来的,要保存的话需要提供Volume Plugin写入Docker外部存储空间。
如果要修改镜像,需要用commit命令产生新的镜像。从而下次运行新镜像的时候就是一个完全不同的Docker了

19、问题:金融行业中,什么业务场景可以使用容器,如何判断?
我们保险行业,有很多的应用,应用之间有很强的耦合关系。
开发部门,为了解决这些问题,在整体设计上使用了微服务架构。
那么,对于底层来讲,需要使用更加灵活的机制,例如容器平台来解决这个问题

20、问题:不同场景下持久化存储的解决方案如何选择?
容器持久化的解决方案在于需要不需要保存数据。
其次,保存在哪?
保存在本地(故障率高),那就是本地硬盘
保存在外部
1.分布式系统(并行处理),那么就需要分布式系统支持Volume Plugin
2.共享存储(高可用),那么外部存储需要支持Volume Plugin的Driver(厂家提供)
那么这个问题就变成你用哪家人家的存储/存储软件,然后这家的是不是支持Volume Plugin
开发测试云:

  • 容器的轻量级特性,降低了开发测试环境的虚拟化成本,提高了资源利用率
  • 容器的快速部署和启停能力,提高了开发测试环境的部署效率和产品迭代效率
  • 容器的应用隔离能力,降低了同一操作系统中不同应用间的测试干扰
  • 容器的操作系统无关性,降低了开发测试环境的迁移复杂度和迁移成本
  • 容器的多副本镜像管理能力,降低了应用程序测试版本的管理复杂度
  • 容量按需扩展
  • 开发、测试环境数据共享
  • 数据分层及自动备份归档
  • 不同应用数据隔离
  • 跨物理机的容器及数据迁移
  • 数据分层及自动备份归档
    DevOps开发运维一体化:
    除了“开发测试云”中实现的容器化收益之外,
  • 开发、测试与生产环境共享镜像仓库,加速研发交付流程,让代码承载业务的脉动,快速推向市场
  • 容器的volume特性,可实现同一应用的不用容器在不同物理机上的负载均衡部署
  • 有效结合Jenkins、Zabbix等开源框架实现自动化的CI/CD持续集成与持续交付以及自动化的监控与运维能力
  • 容量按需扩展
  • 开发、测试、生产环境数据共享
  • 数据分层及自动备份归档
  • 不同应用间数据隔离
  • 跨物理机的数据共享及容器迁移
  • 关键数据分层及自动备份归档
  • 关键数据高可用及灾备能力
    BigData大数据服务:
  • 容器的轻量级特性,降低了开发测试环境的虚拟化成本,提高了资源利用率
  • 容器的批量快速部署能力,加速了大数据集群的部署过程,还可以按需快速调整容器数量以适应大数据平台资源需求的变化
  • 容器的应用隔离,降低了同一操作系统中不用应用间的测试干扰
  • 容器的操作系统无关性,降低了生产环境至大数据环境的迁移复杂度和迁移成本
  • 容器的volume特性,可实现同一大数据应用的不用容器在不同物理机上的负载均衡
  • 容量按需扩展
  • 生产、大数据环境数据共享
  • 数据分层及自动备份归档
  • 支持大规模容器启动,提供高性能访问能力
  • 不同大数据应用间数据隔离
  • 跨物理机的数据共享及容器迁移
  • 元数据、关键数据分层及自动备份归档
    Container Cloud容器云平台:
    结合Docker Swam,Kubernets等开源容器云平台,商业容器云平台实现:
  • 镜像的自动化发布
  • 容器的自动化编排、高可用及应用的负载均衡
  • 镜像、容器、存储的资源管理、监控及运维
  • 容量按需扩展
  • 云平台应用商店,镜像自动发布
  • 数据分层及自动备份归档
  • 支持大规模容器启动,提供高性能访问能力
  • 有状态容器的数据存储及隔离
  • 跨物理机的数据共享及容器高可用
  • 关键数据分层及自动备份归档
  • 存储资源的集成监控管理

21、问题:金融保险行业上容器平台的必要性和风险评估?
金融保险行业传统的使用基于vmware的虚拟化达到共享资源的目的。云计算兴起之后,kvm/x en/等开源项目的兴起,又促进了共享技术的创新。现今it容器的兴起,大有取代传统虚拟化的趋势。
从必要性看来:
1)技术驱动,docker的兴起
2)业务驱动,微服务架构的兴起
风险评估:
1)技术的稳定性如何满足金融保险行业苛刻的要求
2)如何与现有的传统架构相融合
必要性就是实现敏捷业务场景的需要;风险就是对互联网技术的把控能力。

22、 目前能够提供容器持久化存储的开源/商品化的解决方案有哪些?其优势对比?
这个就很多了,IBM,HPE,EMC|DELL,Veritas等大厂商都有支持Docker Volume的Plugin
开源的话就比较复杂了,一般你用内置盘的话Docker自己就有一个
但你用外部存储或者商品话系统的话,你需要一个Driver,这个就是各家厂商提供了。
像IBM提供的Plugin本身也是开源的,IBM提供代码并托管到Github上。
支持GPFS以及IBM的块存储
开源领域主要是ceph,由redhat/intel/suse/zte等一波开源社区坚定的支持者来维护。能否提供一个集块,对象,文件合一的统一存储。它的优势在于性价比,劣势在于产品化严重不足,需要专家级团队的支持

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

9

添加新评论1 条评论

ye_1990ye_1990产品经理, 南京佳建网络科技有限公司
2019-12-25 11:24
写的非常好
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广