Kubernetes 、MongoDB和VMware vSAN在一起，会发生什么呢？

【编者按】

VMware vSAN从诞生之日，就有着长远的、清晰的愿景。体现在它正在迈向的通用存储之路（详见文章：面向未来的软件定义存储平台 ，可以直接打开）。

现如今，vSAN的发展还给用户带来了另外一个好处，也就是它在VMware迈向混合云王者之路中，做为VCF（VMware Cloud Foundation）的基石，成为了未来就绪的超融合架构。而这一未来就绪的特点，是其他超融合架构难以媲美的。

看完本篇文章，你会发现，VMware正在逐步实现自己对用户的承诺，也即将vSAN打造成为通用存储平台，不仅适用于目前已经大规模部署了的传统应用（包括如Oracle、SQL Server），也适用于云原生应用。

文章转载自微信公众号 - VMware中国研发中心，作者是vSAN研发团队的武晓今、洛婧。文章原来的标题是《在VMware vSAN的超融合基础架构中使用容器技术运行MongoDB实例》。

---Begin---

如果您已登陆了 VMware 博客，您应该已经确信，VMware vSAN 作为在容器中 MongoDB 的持久存储，是一个非常好的主意。 如果您是无意间看到的这篇文章，那么我们先给您提供一些背景信息。

MongoDB 是许多企业业务中使用的一个非常受欢迎的非关系型文件存储数据库，并且已经迅速成为主流。Docker 是一种高效的打包和部署应用程序的方法，是一个开源的应用容器引擎。使用 Docker 容器来部署 MongoDB 实例提供了许多好处，如易于维护，以及能够按需进行扩展和收缩。

然而，当我们要在容器环境中运行数据库时，我们必须面对几个问题。例如，我们如何将容器中的数据库性能与虚拟机或裸机服务器上的性能进行比较？我们如何有效地管理数据和磁盘？我们如何确保创建了多个容器并使其高效利用？

我们已经发布了相应的参考架构，展示了基于 VMware vSAN 作为超融合基础架构，在 Kubernetes 集群上， 使用容器技术运行 MongoDB 实例。该参考架构包括以下内容：

• 在容器中使用 vSAN 作为 MongoDB 的持久存储

• 展示了 Kubernetes vSphere Cloud Provider 在 vSAN 上的性能，可以提供无缝整合来处理 Kubernetes 节点故障，并且无任何数据丢失

• 展示了 vSAN 对于主机故障的灵活性

• 测量了多个并发 MongoDB 实例的性能

• 评估启用了副本集的 MongoDB 的性能，并展示了应用程序级的高可用性

总体来说，在由 vSAN 和 VMware vSphere 支持的容器中设计和部署 MongoDB 的解决方案将为您带来以下好处。

1. 简单部署

2. 维护开销最小化

3. 高可用性

4. 弹性配置

* 有关详细说明，请参阅我们发布的参考架构。

参考架构

解决方案架构如下图所示。 Kubernetes 集群由 4 节点 vSphere 和 vSAN 集群组成，MongoDB 服务在节点上的部署启用了副本集（Replica Set）和分片技术（Shard）。

参考架构组件

        该参考架构有如下配置：

MongoDB：

• 数据库大小：大约217GB

配置：

• 四个分片：每个分片大约有54GB的数据

• 四个副本集：每个副本集都要有一个主节点， 一个从节点和一个仲裁节点

• 使用Journaling，数据持久存储

使用vSphere Cloud Provider的持久存储：

• 使用StorageClass进行动态虚拟磁盘配置

Kubernetes节点：

• 4个工作节点

• 4个备用工作节点

• 1个主节点

vSAN集群：

• 4个具有相同配置的物理主机

VMware vSAN磁盘组规范（每个主机）

• SSD：2 个 400GB 固态硬盘（Intel SSD SC2BX40）作为缓存层SSD

• SSD：4 个 400GB 固态硬盘（Intel SSD SC2BX40）作为容量层 SSD

虚拟机配置：

• 操作系统：Photon OS 1.0

• 虚机内存：32GB

• 虚机vCPU：8

磁盘配置（每个节点VM）

• 副本集（主／从节点）：2 个250GB虚拟磁盘

• 副本集（仲裁节点）：1 个20GB虚拟磁盘

• 配置服务器：1 个20GB虚拟磁盘

使用vSAN提供持久性存储

为了支持在 vSphere 环境中运行 Kubernetes 应用程序的持久存储需求，VMware 开发了 vSphere Cloud Provider 及其相应的插件卷。下面的工作流将帮助您了解我们从 vSAN 到容器如何实现持久存储 。

可选配置

我们提出了三种配置。每个配置都有不同的复制设置和 vSAN 存储策略。

配置1 – 面向高性能，数据库受 vSAN 的保护，将“容错”（FTT）设置为1。

配置2 - 面向高保护，数据库受到副本集和 vSAN 的双重保护。

配置3 - 应用级保护，数据库提供副本保护，不需要的双倍空间存储数据， 以及不需要镜像写。可将其视为配置 1 的轻量级版本。

测试性能

针对每种不同的配置，我们通过使用雅虎 YCSB 测量工具进行了性能测试。

我们在这里讨论部分测试结果。而有关完整的结果，请参阅我们发布的参考架构。

下面显示的结果是以读为主工作负载（B），它是在配置 1 和配置 2 上运行的 95％/5％ 的读/写混合的结果。

在配置 1 中，通过平衡吞吐量和耐久性的配置，以读取为主的工作负载（95％ 读取），图中显示了从 8 个到 64 个线程，对于平均 ops/sec 和总计 ops/sec， MongoDB 产生了近线性增量 。使用 64 个线程的 99% 读取和更新延迟最大，更新延迟为 5.6 ms，读取延迟为 7.7 ms。我们监测到读取和写入的平均 vSAN 后端延迟时间都小于 1ms。

在配置 2 中，以读取为主的工作负载（95％ 读取），图中显示从 8 个到 64 个线程，对于平均 ops/sec 和总计ops/sec，MongoDB 产生了近线性性能增量 。使用 64 个线程的 99% 读取和更新延迟最大，更新延迟为 6.1 ms，读取延迟为 8.1 ms。

我们监测到读取和写入的平均 vSAN 后端延迟都小于 1.7ms。

应对故障或者主机失效

我们认为，测试 MongoDB 副本集的主节点的故障恢复，测试 Kubernetes 集群中的节点失效以及测试一个 ESXi 主机异常关机，是非常重要的。

通过对故障组件进行分类，结果如下所示。

最佳实践

在 Kubernetes 群集上，在容器中配置 MongoDB 时，我们建议以下最佳实践：

• vSphere：按照 Getting Started on vSphere ，在 vSphere 6.5 上部署 Kubernetes 集群。

• Kubernetes 集群规模：创建 2 x 节点数个节点，以便每个工作节点都有一个备用节点，以防工作节点发生故障，从而允许备份节点尽快托管该节点。

• 基于 vSAN 存储策略的管理（SPBM）：如果不能容忍约 10％ 的延迟增加或者性能下降，我们建议禁用 vSAN 校验和。因为将启用和禁用校验和的性能进行比较时，像 YCSB 工作负载 A 这样的更新密集型工作负载，性能差异（ops / sec 或延迟）大约为 10% 左右。

 总 结 

我们发布的参考架构服务于非常流行的 NoSQL 产品 MongoDB。由 Kubernetes 提供容器的集群化管理。 vSphere Cloud Provider 可以访问在 Kubernetes 中部署的应用程序的 vSphere 托管存储（vSAN，VMFS，NFS）。它能够支持持久卷管理并且支持动态卷配置。 vSphere Cloud Provider 能够与 vCenter 进行交互，以支持各种操作，例如创建和删除卷，将卷附加到应用程序 pod 和节点。

VMware vSAN 与 Kubernetes 和 MongoDB 副本集一起，为应用程序，节点和物理主机级提供了最佳的保护。

与应用程序级复制相比，VMware vSAN 为基于容器的 MongoDB 服务提供了更好的选择。为了获得最佳的性能，我们建议使用 MongoDB 分片，而不使用 MongoDB 复制副本集，并设置 FTT = 1，从而允许vSAN提供数据保护。为了获得最佳的保护，我们建议使用带从节点和仲裁节点的 MongoDB 复制技术和数据分片，同时设置 FTT = 1，从而允许 vSAN 和 MongDB 提供双重数据保护功能。

点击 “阅读全文”，查看具体参考架构文档！

你也可以复制这个链接：

https://storagehub.vmware.com/#!/vmware-vsan/vmware-vsan-tm-as-persistent-storage-for-mongodb-in-containers