电子帐册:

DevOps不需要带存储的有状态容器,但应用需要

kentoh——Fotolia

管理 学习应用最佳实践并优化您的运营。

集装箱生态系统需要拓展其愿景的持久性

容器的持久性存储将成为一种必要,因为无状态计算方法不再只关注DevOps,而更多地关注最终用户应用程序。

按照最初的设想,容器是用于微服务的无状态家园。容器生态系统的敏捷性和灵活性,加上它们的小资源占用,非常适合微服务的概念。因此,容器与DevOps运动在这十年中,它成为了最热门的技术,并使集装箱以火箭助推的速度增长。

“无国籍”问题不可避免地受到了质疑。事实证明,毫无疑问,真正的应用程序也适合容器生态系统模型。但是真正的应用程序通常不是无状态的。大多数应用程序都有两种存储形式。第一种是多种形式的网络存储,用于数据交换和信息历史。第二个是瞬态的实例存储,在应用程序实例运行时用于scratchpad。

容器与虚拟机的比较

在无状态容器中运行应用程序,而不是在虚拟机中运行应用程序,这意味着实例存储不是一个真正的选项,如果实例由于任何原因失败,这将阻碍恢复。可以访问容器主机上的本地存储,但这可能会产生安全问题,除非容器驻留在虚拟机中。这不是问题所在。如果当前主机发生故障,虚拟机编排可以快速重启另一台服务器上的实例,如果容器要迁移到主流IT,则容器软件需要支持这种功能。

有效的微服务和小程序架构需要数据在容器之间移动——或者让容器化服务实例化数据所在的位置;通常要快得多。为了实现真正的灵活性和灵活性,需要一种便于在集装箱之间移动的车辆来满足需求。

容器存储仍然是IT领域一个混乱的、处于萌芽阶段的领域。

目前的应用程序在各种各样的平台上构建存储,从对象到块,从SAN到超融合。为了让容器完全取代管理程序,容器生态系统也必须满足这种广泛的存储选项。

在这里,不同的参与者之间存在着一些哲学上的差异。Hypervisor的支持者想要无状态的容器,因为容器的完整存储组合可能会毁掉Hypervisor。甚至一些容器爱好者也希望保持无状态容器的纯粹性,尽管这可能只是容器生态系统早期的一个遗留问题目的与管理程序的区别对这个概念的延续至关重要。

大多数容器用户都非常热衷于容器带来的敏捷性和易用性。将这些因素与在服务器中放入3到5倍实例数量的能力结合起来,DevOps的支持者就会看到一个全垒打。因此,向容器选项添加持久数据是必须具备的主要路线图,行业正在顺应这种需求。

容器存储仍然是IT领域一个混乱的、处于萌芽阶段的领域。存储和容器供应商推出了他们自己的解决方案,而不是单一的收敛点,甚至是几个收敛点。好消息是,我们看到的解决方案很多,而且它们有不同的api和功能。不过,这种情况反映了人们对集装箱的热情,对这个细分市场来说是一个健康的信号。

产品和供应商

让我们看看容器生态系统中的各种产品。Portworx PWX允许容器装载可共享弹性块存储。StorageOS更进一步并安装了各种外部存储协议和类型,也提供了压缩等。牧场主实验室旨在实现本地存储,同时支持跨服务器的数据迁移。Microsoft Windows Server为操作系统内核级共享以及Hyper-V实例提供了解决方案。

这个名单还有很多。ClusterHQ使用了Flocker,这是一种开源产品,允许从共享块存储池中创建一个空间,该空间可以通过容器移动,甚至可以跨主机移动。Flocker由VMware支持,可以与EMC和NetApp存储以及其他许多存储设备进行交互。但是ClusterHQ折叠帐篷这使得福洛克失去了主要的啦啦队长。

在核心容器软件中有活动。Kubernetes 1.6后来允许按需存储和多种存储类型,所有主要的云堆栈都有StorageClass对象,包括OpenStack和vSphere以及三大公共云服务提供商。超聚合系统需要自己的容器存储秘密酱汁,Nutanix等供应商有望在不久的将来加入这一行列。

有趣的是,容器业内人士谈论的是“持久性数据”而不是“存储”。我长期以来一直认为,行业向对象存储、软件定义的存储微服务和细粒度容器虚拟化的发展,所有这些都使传统的大文件视图过时。以数据库为例。它实际上由数千个记录大小的对象组成。向细粒度存储的转变可能是所有这些技术发展的结果。

当你添加非易失性DIMM(NVDIMM)在等式中,这变得更为紧迫。在几年内,NVDIMM将保持在字级,而不是使用4KB的块存储模式。因此,在未来,处理容器存储可能是一个糟糕的模式,持久化数据可能会成为一个深刻的选择。

下一步

Docker持久存储由卖主赠送

码头工人容器存储小贩们的想法

StorageOS版本持久容器存储

深入挖掘应用程序存储

搜索灾难复苏
搜索数据备份
搜索汇聚基础设施
Baidu