通用电气GE微服务实践：在容器中部署有状态应用

通用电气GE

通用电气GE，创立于1892年，是世界上最大的技术和服务跨国公司。自托马斯·爱迪生创建通用电气公司以来，业务遍及世界上100多个国家，拥有员工315,000人。

GE在航空，电力，运输，能源等行业具备丰富的产品线和运营经验。同时GE也通过数字化的方式帮助客户进行产品的运维，数据分析和改进。GE为此建立了自己的物联网数字化平台。

GE采用微服务架构，并通过容器来运行有状态应用。为此，需要建立CSI（Container Storage Interface），GE尝试了一些办法，但是从使用上来说并不成熟，无法给平台的用户和合作伙伴，提供简单易操作的容器存储和数据管理方法。需要有一个能够同时运行无状态应用和有状态应用的基础层。

最终，GE选择了与Portworx携手，来建立CSI对容器存储和数据进行有效管理。

Portworx建立了物理存储之上的软件定义的存储抽象层，用户不需要思考具体在使用那种物理存储，也不需要知道承载应用的是哪朵公有云或者私有云。

在没有这样一个抽象层之前，用户需要手动的把物理存储卷来分配到某个容器上。传统的存储，都是通过虚拟机和操作系统来驱动存储的，对于容器来说则很不适用。因为容器通常被编排程序Orchestrator排程在多节点的环境下来运行。应用程序也不都是在单一的容器内运行。比如Cassandra, 通常是部署在一系列的容器上。一个Cassandra集群可能会有3个、10个、15个Cassandra容器，被部署在15个不同的虚拟机上，甚至可能在不同的物理数据中心里。所以当我们尝试把某个卷添加到这样一个分布式系统里的时候，就会出现非常多的问题。这些问题需要运维工程师花大量的时间来做调整，让卷与这样的分布式系统产生映射。假如说一个5节点的Cassandra集群，这些节点都运行在哪些虚拟机上呢？又是在哪个存储上呢？于是我们不得不把应用跟虚拟机对应起来，因为我们在使用虚拟机对应的存储资源。如果虚拟机停机了，我们就不得不去手动寻找相对应的存储，然后把它和新的虚拟机对应起来。这跟云原生的思想和容器排程器Orchestrator的定位并不对路。同时新的问题又会产生，如何在这样的分布式系统里为存储设定密码？如何做快照？这些问题都将留给我们的用户，这就更有问题了。

作为GE，我们并不想把这样的复杂的基础架构爬坑工作留给用户。

Portworx本身是一种基于容器的超融合架构，将计算资源与存储有机结合在一起。同时Portworx与K8S的调度软件scheduler无缝集成。

像数据库这样的有状态型容器化应用需要在分布式节点上的永久数据。Portworx使用有状态的Stateful Fabric来管理数据卷，即container-SLA-aware，来做到这一点。复制卷数据确保其状态，同时满足容器化应用的性能和可用性。更重要的是，Portworx可在每个容器级别中管理其快照、克隆副本和复制操作，使DevOps能够单独管理微服务，而不是像LUNs那用做传统存储系统的绑定组。使用Portworx管理有状态容器Stateful Containers很方便，每个容器级别的数据的可用性和管理也很简单，且高度自动化。

如果需要部署一个Cassandra集群，而又并不想让所有的节点在同一个环网上，在同一个Availability Zone或者Failure domain，Portworx可以帮助用户更好的来架构这些分布式的应用。另外通常我们希望物理资源能够有80%以上的利用率。我们需要让不同的应用在同一个硬件内共存，而不产生IO的冲突。Portworx并不是直接把存储或者物理的LUNs跟应用连接起来，我们提供一个虚拟的存储卷层来避免IO的冲突，并实现容器的加密或者是快照。尤其是当一个容器宕机，然后又从另外一个位置恢复后，我们就能够快速找到原来的存储，并且在新的容器中恢复。同时Portworx的安全与合规管理功能，帮助GE满足公司内部对于平台架构的安全合规要求，也满足了用户和客户的存储加密，存储快照这样的需求。