IT领域，变革的速度令人瞠舌。快速增长的数据，云计算规模的处理，以及百万级的物联网设备正在推动我们向着更高效、可靠和可扩展的方向发展。传统的应用架构已日趋极限，我们正试图努力开发部署最佳的新方案。所幸的是，最被看好的容器化技术——这项据称能够解决许多问题的技术(如果不能算是全部的话)——正成为应对上述难题的妙药良方。

    在容器化应用程序设计中，每个容器间彼此隔离，独立扩展，并可作为处理某项大型网络应用的组件。有别于以往处理整个应用程序，大型的容器化应用程序可由数百个(甚至上千个)相关容器组合而成。这些应用程序支持敏捷设计、开发和部署方式。它们可以在生产环境中轻松扩展，非常适合于分布式、甚至基于云的混合式基础架构。

    遗憾的是，容器在最初设计中并非用于实现全堆栈应用程序，亦不适合需要长期储存数据的应用。容器的设计初衷是可以轻易地大规模创建、部署微服务的应用层，并将微服务视为一种高度敏捷的中间件，在概念上无需持久的存储数据。

    持之以恒

    由于容器方式具有很强的灵活性、易于扩展、高效性，并面向云计算，在许多情况下这都是一种经济的部署模式，因此现在人们希望将其应用范围扩展到微服务之外。容器架构提供了更好的方式来构建现代化的应用程序，我们看到许多商业软件和系统供应商在内部开发中转向容器形式，甚至将其广泛部署，而且通常在上层保持对最终用户和IT管理人员的透明。大多数名列财富100强的企业已经开始以容器形式进行生产环境的第三方IT应用托管，尤其在内部应用、融合架构和专用的基础架构领域。

    你或许会看到大型的、容器化的数据库，甚至存储系统的出现。然而，设计企业级的、长期存储数据的应用程序仍是不小的挑战，容器可能在分布式和混合基础架构中来回迁移。而数据需要控制、保护、受到管制和监督，所以很多时候持续数据存储需要更像是锚点那样，容器在这方面着实面临着短板。

    容器架构使用到三种类型的存储：第一是镜像存储。这可以利用现有的共享存储进行交付，要求类似于服务器虚拟化环境中虚拟机镜像分发保护的平台架构。容器镜像的一项好处在于其存储容量相较于完整的虚拟机镜像小了许多，因为它们不会复制操作系统代码。此外，容器镜像的运行在设计之初便是固定的，因此可以更高效地存储、共享。但也因此，容器镜像无法存储动态应用程序的数据。

    第二类需要存储的数据是容器的管理。当然，你同样可以借助现有存储完成这项工作。不论使用Docker、Kubernetes、Tectonic、Rancher还是其它类型的容器管理，都需要存储配置数据、日志记录等管理数据。

    还有第三类存储，容器应用的存储，是最具挑战的。只有支持真正的微服务式编程时，容器代码可以直接写入镜像目录和文件。但是容器使用一种分层文件系统，将所有新写入的数据存储在临时虚拟层，最底层的容器镜像却未被修改。一旦容器消失——相比虚拟机，容器的设计寿命更短——所有的临时存储都会随之消散。

    假如一个容器应用程序需要保存数据，一种方式是显示地在容器的全局命名空间内加载一个特定的系统数据卷——或在Kubernetes框架下的持久卷这样可以让容器直接方案读/写主机目录或文件系统。假如容器被关闭或重新启动，它依旧可以访问之前写入的，用于长期存放的数据。但这并不是一个简单易行的方式，需要考虑在容器之间共享数据，因此应用程序开发人员必须兼顾共享、锁定、争用和重启的问题。而且存储管理员如何甄别保护——快照、备份和灾难恢复产生的——成千上万由程序控制的海量数据。

    此外，假如容器集群中的某一个容器位于另一台主机，那么存储管理员需要确保共享或分布式文件系统(例如NFS)在所有的集群主机上均保持同样的配置，甚至应用程序员可能要添加更多与I/O相关的代码，从而确保可靠的集群级别的共享。所幸的是，专家级的存储管理员会选择将现有的企业级存储(如NAS和SAN)带入这个全新的容器领域。如果他们与开发人员紧密合作，可以实际配置出高端的企业级生产环境。

    不过，容器领域内的最佳实践是让Agile DevOps具备相同的沙箱、测试与生产环境。从容器角度看，这种方式为最终用户提供动态配置，从而确保容器的移动和迁移。系统的存储配置越是静态和脆弱，容器化的好处便越是难以体现。

    Docker等容器管理产品提供可插拔的卷管理。例如Flocker是开源Docker可插拔卷中的最受欢迎的替代品，可以通过集群智能管理、迁移数据卷及其容器。虽然Flocker的主要赞助商ClusterHQ已不复存在，但我们预计这种功能将持续发展，并在基准容器平台内变得日益本土化；Rancher Labs的“Convoy”项目正朝着这个方向发展。大多数(如果不说全部的话)传统存储供应商和云存储服务提供商为其存储阵列生成各类容器系统卷插件，这不失为在存储上持续投资的好方法。

    存储即软件

    相较于尝试将旧版存储强制迁移到新的容器环境中，不断增长的替代方案会引发新一波的软件定义存储(SDS)风潮来完成这项工作。SDS由一个存储操作系统和完全部署为软件层的服务构成，该服务层通常作为虚拟机呈现，不过现在其越来越多地部署为容器模式。容器化软件存储的快速发展是很容易想见得到的，以便于容器化应用程序使用存储服务。

    相比在传统的生产环境中，服务器虚拟化环境通常基于大型而昂贵的主机集群，容器的托管体系架构能够轻松使用由更开放的、广泛而廉价的通用服务器组建起的私有、公有或混合云基础架构。这有些类似于Hadoop和Spark等大数据项目使用通用基础架构的优势，并且通过使用SDS和内存来讲我们从专用而昂贵的平台中释放出来。

    SDS的另一项核心优势特别针对Ceph，Torus和GlusterFS等分布式容器方案，将存储以最适合的方式交付给容器集群。管理诸如GlusterFS之类的技术对传统的SAN管理员而言可谓是一项挑战，但容器化存储与身居来具有各种诸如敏捷性、可扩展性和可用性方面的优势，同时通过本地化数据存储改善应用程序性能。

    简而言之，预融合和超融合容器设备使得内置本地容器存储功能(如Datera和Diamanti)变得更加简单。通过使用SDS来得到在同一平台设备格式下融合万物所需的灵活性和便捷性。虽然我们尚未有听到有企业真正在生产环境中使用融合容器托管方式，但未来的IT基础架构必将延续融合道路，同时建立更多云端服务。

    当然，IT人员的工作在于判断是否为某家供应商专有的技术买单，或是转向免费的开源代码，加以投资，并封闭在该领域。假如要得到经过预先集成、验证的企业级功能和全天候的技术支持，通常需要长期选定某家供应商的开源分发或预融合的堆栈。换句话说，这不仅是选择传统的哪家供应商，更是选择供应商专有还是开源的技术，或是完全依赖自己的开发。

    云端扩展的对象存储

    容器化应用程序往往采取云计算架构，其体系架构要根据外部工作负载情况的变化、增长而持续扩展内部的服务。这种基于云的理念同样渗透到现代应用程序开发人员调用存储的方式。许多新的容器化应用程序是针对对象存储的I / O，而非传统的文件系统或数据块编写的。

    大多数当前的容器环境在现实部署中平稳进行——当然在公有云中可谓例外，来自Hedvig、Qumulo和Scality等在线扩展对象存储恰好满足容器所需。在实施或迁移容器应用程序时，Amazon Web Services Simple Storage Service (S3)和类似的公有云已经开始将对象存储用作持久的存储层。

    面向未来

    我们尚未看到容器最终在永久数据存储方面会有怎样的表现。根据过去存储领域的发展演进经验来看，我们可能会看到“容器认知”存储的出现，其为容器配置而生，并配以适合的管理功能。就像虚拟机认知存储一样，我们应该还可以看到一项容器存储服务，可以保持数据并持续追溯——甚至在跨集群容器和跨云容器环境中。最终，我们期待看到使用服务器闪存和新兴的持续性闪存(如非易失性存储器快照)的容器认知缓存，并且和持续存储层相结合。

    希望未来的容器认知存储可以兼顾到所有关键的方面，从容器清单到应用蓝图。我们同样希望在未来完成多容器环境的存储管理，可以追溯、预测和优化存储订阅，以满足持续容器运作所需。另外，存储认知的存储需要能通过简单的策略机制，随时随地地保护到所有数据、确保高可用性和灾难恢复。

    以虚拟机形式呈现的服务器虚拟化花费了超过10年才替代掉企业数据中心中应用程序专用的物理服务器。现在，容器化应用程序似乎将会在一两年内替换许多完整的虚拟机应用。最大挑战在于我们能否为容器快速提供企业级持续性数据存储。