我们在第一部分《容器时代的存储问题：插件是救世主吗?》中指出了容器的存储问题愈发严重，去年Docker发布了Docker 1.9版本，迈出了重要的一步，采用插件方式增加了对永久性存储的支持。除了插件方式是否还有更多的解决方案?

　　持久性之外

　　Rancher Labs是一家为容器提供基础设施运营软件的公司，该公司的联合创始人兼CEO Sheng Liang说，即便推出了卷插件，目前容器环境支持的存储功能仍旧有限。

　　他认为，尽管卷插件是一个很好的起点，除打开、关闭、读、写功能外，Docker生态系统最终还要增加额外的功能。例如如何生成快照或者制作备份。

　　Docker自己也承认会推出更多的存储卷插件。Docker在1.7版本中公布了存储卷插件，但直到1.9版本才开始被普遍使用。Docker产品管理与设计高级副总裁Scott Johnston说：“存储卷插件在易用性、灵活性、差异化方面有很多的迭代。这是个很不错的开始，但并不意味着没有其他工作要做了。例如，Docker还不支持在线迁移，而该功能在生产环境中至关重要。”

　　CoreOS公司推出了与Docker竞争的容器引擎Rocket以及构造业务流程框架，该公司的CEO Alex Polvi认为需要考虑建立容器生态系统。即使已经在容器引擎级实现了数据卷管理器，但在集群级实现数据卷管理器非常重要。因此考虑容器的组织必须探索容器管理系统比如Mesos、Docker Swarm以及Kubernetes如何在容器与底层数据卷之间建立映射。

　　尽管没有Kubernetes这样的工具也能够运行容器化环境，但如果你计划对环境进行扩展，那么不借助工具并不是个好主意。Polvi说一切都处于动态变化之中，任何存储系统都应该能够支持容器的动态特性。

　　XtremIO是一家提供scale-out全闪存存储平台的公司，该公司的CTO Itzik Reich说IT运营团队正在计划大规模使用容器。最近他们为一家大型银行客户演示了一个由XtremIO存储、ClusterHQ Flocker驱动以及Mesosphere/Marathon调度与编排所组成的demo。尽管该客户至少领先两代，但他们在积极地评估容器技术。他们希望要的是可以真正使用的技术，而不是等待第一批订单。

　　做好准备吧!

　　当这些生产工作负载开花结果，预计会给存储带来哪些压力?

　　Docker的Johnston说，与传统的虚拟机不同，容器没有给底层存储子系统施加过大的压力。容器与虚拟化面临的问题有所不同。虚拟机模拟底层硬件——比如CPU或I/O子系统——容器在资源之间创建隔离边界。因此，容器为CPU以及IO提供了“原始性能”，只有很少的网络开销(5%)。

　　考虑到容器共享操作系统的单个副本，与虚拟机相比，组织也往往会在每台服务器上运行更多的容器。这会增加存储系统的密度，导致问题出现。因为容器几乎可以即时启动，因此资源需要实时可用。

　　例如，在Portworx的案例中，通过针对容器的分层文件系统进行优化，其存储系统在密度以及突发负载方面面临的挑战很小。其软件定义的存储堆栈目前正在测试，预计今年夏天可以使用。

　　位于美国加州的Hedvig公司同样制作了分布式scale-out软件定义存储，并认为可扩展性对容器环境至关重要——下一代应用比如Cassandra以及MongoDB经常会在这样的环境下运行。Hedvig的营销副总裁Rob Whiteley说这对不能预测三、五个月之后需求的客户非常重要。系统还提供了可以应用于容器、应用或者虚拟机的高级存储策略，以及一种固有的多站点体系架构，用于内置灾难恢复。

　　“Packet正在提供方便用户使用的容器友好型存储。用户去年使用产品时需要创建他们自己的存储，但大多数用户太懒或者太害怕。”Smit说，“他们仍旧想要灵活的、具备安全性与可控性的块服务。”因此，Packet现在为用户提供块存储Datera，提供形式有两种(“缓慢庞大”或者“快速小巧”)，数据放置及分层是在Datera平台存储中实现的。

　　抽象及自动化级别可能预示着容器对存储的巨大影响：根本不必考虑存储。正如容器使开发者不用再担心在哪个版本的Linux上构建他们自己的应用，作为一名应用开发人员，你不用再为需要IOPS达到700的上TB的存储空间而担忧。