作者一只红松鼠·2022-05-28 15:24

其它·其它

如何进行容器云平台的存储选型

字数 5856阅读 2845评论 0赞 3

## 写在前面：宾主易位

最近有朋友问我容器持久化选型的问题。从18年接触有状态容器数据持久化开始，感觉大家一直有很多纠结和迷惑之处。所以把我的想法做下总结，希望对大家有所借鉴。在讨论之前，先梳理一下有状态容器的发展情况，主要是请大家注意**容器环境中的存储选型从以容器为中心转向以业务需求和存储能力为中心，即“宾主易位”**。

Docker在部署便利性，轻量化，弹性等方面的巨大优势非常适合构建微服务并促成DevOps落地，因而虽然使用容器需要做无状态化、发布方式流程、编排调度等改造，但都没有阻碍容器迅速走红，甚至很多应用开发部门反而是推动容器改造的主力。这使得长期以来业务是围着容器转，存储的选型也要根据容器对存储的使用要求来定。

然而随着容器化的深入，应用改造的难度、风险和投入越来越大，促成了有状态容器的发展。这种从改造业务到改造容器的“宾主易位”推动容器存储CSI接口架构出现，解决了第三方存储开发存储插件的问题，使原来仅有少量存储可供选择的局面大为改观，导致容器适配的选型重要性下降，并使容器中存储选型可以更聚焦于满足业务需求或提升容器整体能力进而服务于业务。所以本文重点从业务应用的问题与需求视角，分析容器中如何做存储选型。

## 想用存储要解决什么问题

### 实现数据共享避免业务改造

#### 数据共享解决什么问题

这是容器使用存储最常见的需求。这类应用中存储用来给多个应用实例访问同一份数据来实现并行或串行的分布式处理，从而满足业务的高性能、扩展性等需求。实现数据共享需要所有容器有相同的访问入口，因此虽然使用了存储，但**应用更接近无状态应用特性，只要不改变数据共享方式，往往不需要大量业务改造**。来看一个通信行业计费处理的例子：

![](/home/attachment/202205/28/1253021_165371879433600.png)

上图为“抢占式多任务”话单处理部署逻辑图。我们电话的通话记录以话单文件的形式存储，由话单队列传输到共享文件系统，共享文件系统用相同的Mount路径让多个服务器上的多个处理进程组成的集群可以访并发处理文件，数据库则记录并发锁避免重复。由于单个目录会有数十万个小文件，加上处理时效性要求非常高，**对文件存储性能有非常高的要求**，以往都是使用用于HPC和数据库的高性能分布式文件系统GPFS，最近两年开始使用国产高性能企业NAS存储。

**话单处理直接影响用户感知，是典型的稳态业务**，但同时又有处理定期/不定期业务高峰的敏捷弹性需求，我把这类业务的容器化改造称为**稳态业务敏捷化**：即希望用容器解决扩展性、服务管理等问题，但要保证系统的稳定可靠安全，说白了就是不能做大规模业务改造。不过从应用架构可以看出它做容器化的难度不大，只要将话单进程打包进容器，存储层面虽然GPFS配置和扩展比较复杂，不好与K8S联动，但应用配置稳定，存储的变更需求不多，主要的弹性需求来自对计算能力的扩展。因此把GPFS在所有服务器上事先配好，用Hostpath来使用就行了。后来用高端企业级NAS存储替换了GPFS，简化了组网，但容器存储接口没有调整。

#### 对存储的需求

用存储实现容器间数据共享的目的就是避免应用向消息队列、数据库转移数据而造成“地震式”应用改造，而且基本上应用打算上容器前已经使用共享存储了，如日志系统，运营商计费系统，金融票据等。所以对存储的选型主要基于业务的需要：

- **容器存储接口**

上面话单处理的例子也能看出，如果对CSI接口的功能要求不多，甚至如果应用对存储的隔离性、弹性扩展等无需求可以不考虑接口问题，重点是满足业务需求。当然最好是使用CSI接口实现PVC配置。

- **满足业务可靠性、运维、性能要求：**

由于大量应用迟迟没有容器化与容器中没有满足业务需求的存储有关，这部分应重点评估，保障上容器后业务性能、可靠性不下降，整体运维难度可控。

对于原来使用存储的应用，上容器就是应用和存储一起平移，业务不改造，那么对存储的需求也没有变化。可以按原有存储选型标准进行评估。

- **接口类型：**

同样是以不改造应用为原则，存储接口类型也尽量不变或使业务无感知。比如原来为对象或NAS就还使用同协议对象或NAS存储，如果是POSIX类型的其它共享文件系统如GPFS，可以替换成同等能力的NAS存储，因为NAS在组网灵活性，容器CSI接口支持力度上都要更好。

### 实现资源池化按需分配

#### 实现计算和存储按需分配

与实现数据共享不同，通过存储实现资源按需分配是对容器能力的补齐增强，是要实现真正的“容器云”。来看[京东](https://developer.jdcloud.com/article/985)的例子：

![图片来自 ChubaoFS+Vitess的低成本数据库存储计算分离实现方案](/home/attachment/202205/28/1253021_165371896333421.jpg)

在资源分配时需要考虑的维度有计算能力，包括算力（主要是CPU）、内存和存储能力，包括容量、性能（又可细分为IO、带宽、时延）。因为不同业务的资源需求是参差不齐的，如果使用本地盘，就会像左图一样虽然还有部分资源空余，但不满足某个APP整体资源需求，无法利用这部分资源。京东的例子是MySQL数据库面临的“存储之殇”。还有一个常见场景是大数据/数据湖容器化时，一般会考虑使用外置存储充分释放容器的灵活按需资源分配能力，因为大数据业务的计算和存储需求往往是极度不匹配的。此外如果要实现生产和分析业务“混部”也同样要先实现两类业务的存算分离。

#### 对存储的需求

- **容器存储接口需求：**

要实现按需分配资源，使用CSI插件是通常的选择，至少要支持动态创建PVC和对PVC的在线扩容，必要时要支持多租户。不过如果是文件类型存储（NAS，对象，HDFS），因为是多个容器访问同一个挂载点或路网络径，如果管理不太复杂，也可以不通过K8S调度直接在存储侧进行配置。如果存储的性能也是资源池的主要池化分配SLA，那么QoS也是必须考虑的功能。

- **协议选择：**

与实现数据共享不同，实现按需分配的场景往往原来没有部署在外置存储上，应用不一定需要数据共享。需要注意的是并不是所有Local Disk架构的应用都不使用共享存储，大数据应用往往需要共享存储，AWS，阿里，华为，腾讯，浪潮等厂商都采用对象存储或HDFS接口大数据存储来实现。

从HADOOP生态架构可以看到，虽然采用了Local Disk部署方式，但HADOOP是“计算可移动”架构，有逻辑独立的可供所有节点共享的存储层HDFS。分离后存储需要继承和支持共享能力。

![ Hadoop生态有单独的共享存储层HDFS ](/home/attachment/202205/28/1253021_165372247951333.png)

- **存储能力：**

**性能：**

对于原先使用本地盘的应用，往往是因为考虑本地盘性能更好。因此在更换为外置存储时，性能评估会比较关键。同时由于存储的类型有非常大的变化，原先的选型评估体系和经验无法利用，需要更多测试和谨慎评估。

但要注意外置存储的性能不是一对一与本地盘对比。因为本地盘是固定配置，既可能存在性能过剩，也可能存在对突发峰值需求难以应付的问题。

**可靠性：**

由于资源池要承载多个业务的数据，可靠性要求要从故障可接管转向重点保障服务不降级。因此要更关注缩短故障对业务的影响（最好0中断）、缩短故障恢复重构时间和防止的亚健康的能力。

成本：

总体成本需要有所下降，尤其是大数据等对成本敏感的应用。不过要注意评估时要将资源按需分配带来的成本下降以及使用中机房占用、耗电等成本综合考虑，尤其是在减排的大背景下。

**其它：**

要提供与按需分配相关联的租户、资源隔离能能力。而这些也正是本地盘比较缺乏的但要构建“云”必须的。

因为性能、可靠性、成本往往是方案是否能实现的关键因素，一些厂商在存储中专门进行了性能优化以达到于本地盘持平的性能，可靠性、成本也有相应优化方案，如果有这类产品可考虑优先选择。

使用对象存储替代HDFS时需要使用插件进行转换，对一部分Hadoop生态应用支持不太好，需要应用进行适配，同时增加了配置复杂度和性能下降。线下存储厂商像华为是采用HDFS兼容接口，适配性更好，对性能影响也比较小，选型时可综合其它因素考虑。

### 实现灵活伸缩及提升可用性

#### 不可变基础设施才更灵活可靠

上一个需求是通过实现容器资源池化提升资源使用效率，这个需求则要用云原生不可变基础设施架构实现弹性伸缩和更高的可用性。当容器存储部署在本地盘时，数据就绑在了本地盘上，当需要增加容器或搬迁容器到新增的服务器、以及因故障更换服务器时，都需要复制迁移/恢复大量数据，“**耗费时间极长。如果遇到大量数据写入，有可能出现新加的从库一直无法追上主库，导致扩容还未完成，原来的数据库实例硬盘的剩余空间就已经被耗尽，造成数据库宕机，无法提供服务**”，完全失去了容器灵活扩展和快速漂移的优势。京东将这一问题称为[“扩容之痛”和“运维之艰”](https://developer.jdcloud.com/article/985)。

云原生特征中有一个“不可变基础设施”，即要求服务器镜像生成后就不再做配置变更和数据修改，从而在扩容或故障恢复时只要复制镜像并启动服务即可。显然要在数据库和大数据应用中实现不可变基础设施，需要把数据部署在外置存储上，否则虽然镜像中没有数据，但本地盘上的数据在漂移时是带不走的。除了京东云的MySQL数据库，阿里、AWS主推的云数据库和数据湖采用外置存储都有这方面考虑。

存储对扩展和可靠性的增强还可以通过存储的特性能力来实现，如快照/Clone常被用来在云上用来做数据备份，也可用于生成扩容用POD的数据副本。

#### 对存储的需求

如果已经想用容器+存储解决扩展和可靠性问题，那么一般已经对容器的使用非常深入了，这一场景对存储的需求也是最为多样的。

- **容器存储接口需求：**

需要支持基本的存储分配，POD漂移后存储会随POD漂移。如果要使用快照等存储增值特性，除了在CSI接口上要实现相应功能外，还需要容器平台的配合与编排。为了简化这些操作，一些厂商提供了对特性的服务封装，在选型时可以关注。

- **协议选择：**

和上一场景类似，协议由应用决定，不过由于NAS在实现容器漂移这一基础功能的能力上要容易些，在安全性和性能能保障的情况下，可以考虑用NAS替代块存储。

对于共享存储架构，例如实现存算分离的HADOOP，需要增加计算能力时只需要增加容器实例。而像Mysql这类应用扩展计算实例时还需要一份额外的存储，增加了成本。目前已有厂商在探索将Mysql这类开源数据库改造为使用共享存储的A-A架构，不过可选方案目前比较有限。

**存储能力：**

这个场景全部是本地盘迁移到外置存储，对存储能力的需求可参考上一场景。

## 抓住主要矛盾规避观念误区

在开篇处就讲了容器存储选型的宾主易位问题。原因是很多不成功的实践与纠结于像社区认可度，接口能力如何，甚至是否是分布式存储，而没能很好地服务于支撑业务这一主要矛盾有关。应该说早期由于K8S的存储接口演进方向不明确，有状态容器不成熟，加上受接口协议限制与K8S配合比较好的主要是“分布式”开源存储，上述考虑有一定道理，但在宾主易位后，需要放下这些观念，抓住满足业务这个主要矛盾。

。

### 抓住满足业务需求这个主要矛盾

17年接手过一个容器化迁移项目，当时首先考虑的是做容器的无状态化改造。有过类似经历的朋友可能有体会：能做无状态化改造的应用，早就改造了，最后不得不用外置存储的，都是改不了的。连应用都改不了，更不要指望应用会迁就存储能力的不足了。

早期那些与K8S兼容适配较好的存储产品，往往在性能和可靠性等方面满足不了业务的需求。以前是没得选，现在如果查一下[CSI插件的官方手册](https://kubernetes-csi.github.io/docs/drivers.html "CSI插件的官方手册")Driver一节，EMC、HUAWE、HDS、IBM、HPE这些存储主流厂家都已有在列。何况当前容器存储的需求大户文件型共享存储甚至没有标准接口也因其数据共享的业务特性能通过统一的挂载点来使用。前面分析的三个场景中无论哪一个，满足业务的需求都应是第一位的，即一定要首先保证应用迁移到容器上之后或容器由本地盘更换为外置存储后不带来业务改造和使用问题。

### 不要纠结于架构和“出身”

容器有着云原生，微服务，开源，分布式等多重光环。这让我们在选型时可能会陷入“门当户对”的误区中。当然“门当户对”在选型中并不是没有好处，它简化了我们筛选的工作量和难度，但不能刻舟求剑。比如现在K8S容器存储接口普遍使用CSI插件方式后大量商用存储产品实现了对K8S的支持，以前认为开源产品与K8S对接更好的观点就不再适用。

架构也是经常纠结的问题，容器是“分布式”的，那么是否应该用“分布式存储”？架构的问题比较复杂，如有兴趣可参考[近年云计算存储发展中颠覆认知的新趋势解析](https://mp.weixin.qq.com/s/XEWaUAMVt04nVvC_yLYOGw)一文。简单来讲，第一能支撑好业务的就是好架构，架构无绝对优劣，更无绝对先进之分；第二随着存储技术发展，所谓集中式和分布式的架构分界已不准确，用它来指导选型可能南辕北辙；第三有状态容器都是后来才有的“不正确”的架构，当年我做业务向容器迁移时，业务做无状态改造是没商量的，哪想到现在又来搞有状态容器呢？以“架构正确”作为选型要求用到“不正确”的场景中，未必能得到正确的结果。

容器中的存储选型还有很多需要探索的问题，前面的分享算是第一关的“通关”经验，之后还有与容器平台集成、有状态容器编排等BOSS要打，希望本文能给大家一点启发，并欢迎大家一起探讨。

容器云平台存储选型

著作权归作者所有

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

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

如何进行容器云平台的存储选型

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料