两年前，我们在 KubeCon 2017 上首次认识 Diamanti，他们的愿景给我们留下了深刻印象：提供专为微服务和云原生环境构建的裸机容器平台，并针对 Kubernetes 或基本上是超融合进行了优化Kubernetes 的基础设施设备。 我们认为这是一个有趣的游戏，去年在 KubeCon 2018 上，我们开始与他们讨论与我们合作以了解 Kubernetes 上的存储以及如何以有条不紊的方式测试和量化 Kubernetes 存储，以便我们可以开始测试和记录Kubernetes 存储性能。
两年前，我们在 KubeCon 2017 上首次认识 Diamanti，他们的愿景给我们留下了深刻印象：提供专为微服务和云原生环境构建的裸机容器平台，并针对 Kubernetes 或基本上是超融合进行了优化Kubernetes 的基础设施设备。 我们认为这是一个有趣的游戏，去年在 KubeCon 2018 上，我们开始与他们讨论与我们合作以了解 Kubernetes 上的存储以及如何以有条不紊的方式测试和量化 Kubernetes 存储，以便我们可以开始测试和记录Kubernetes 存储性能。
Diamanti 与 Diamanti 合作非常愉快，并且能够为我们提供创建测试方法所需的对 Kubernetes 和 Kubernetes 存储的深刻理解。 Diamanti 由前 VMware、VERITAS 和 Cisco 工程师创立，由高盛和其他知名风险投资公司资助，这令人印象深刻，但更令人印象深刻的是 Diamanti 一直是存储和网络标准（即 FlexVolume/CSI）的主要贡献者和 CNI）已被上游 Kubernetes 代码接受。
企业业务正在以光速发展，公司正试图通过新技术跟上这种发展的步伐，以加快其整个应用程序的生产周期。 容器是旨在加速应用程序开发和部署的技术，但在遗留基础设施上构建它们可能很复杂，并且很快成为构建功能齐全的容器堆栈的相当大的障碍。 容器与传统存储和网络基础设施不兼容，因此构建容器环境的自己动手 (DIY) 方法对 IT 具有挑战性、成本高且节奏缓慢。 Diamanti Enterprise Kubernetes Platform 旨在为基础设施架构师、IT 运维人员和应用程序所有者提供大规模运行有状态容器化应用程序所需的速度、简单性、效率和控制力。
Diamanti Enterprise Kubernetes Platform 是一个裸机容器平台，专注于快速启动和运行的网络和存储方面，尤其适用于大型企业。 通过完全集成开源 Docker 和 Kubernetes，以及专用硬件和对整个堆栈的完整支持，Diamanti Enterprise Kubernetes Platform 是一个可以在几分钟内部署的完整容器解决方案。 Diamanti 表示在其企业 Kubernetes 平台上具有无与伦比的性能和利用率； 这种性能的秘诀在于使用专为 Kubernetes 容器使用网络和存储资源的方式而设计的独特超融合架构。
Diamanti D10 规格
| 网络 | 4×10 GbE 通过单个 QSFP+ 连接（每个节点） |
| 数据存储 | 4 TB 配置（每个节点 4 个 1000 GB NVMe SSD） 8 TB 配置（每个节点 4 个 2000 GB NVMe SSD） 32 TB 配置（每个节点 4 个 8000 GB NVMe SSD） |
| 主机操作系统和 Docker 镜像存储 | 960 GB（每个节点 2 个 480 GB SATA SSD） |
| 计算 | |
| 中央处理器 | 2 个 Intel Xeon 处理器，20 / 32 / 44 核（每个节点） |
| 内存 | 192 GB / 384 GB / 768 GB（每个节点 |
| 物理 | |
| 外形 | 1U |
| 尺寸和重量（每个节点） | 17.25″W x 28″D x 1.72″H / 52 磅。 43.8cm x 71.1cm x 4.4cm / 24 公斤 |
| 电力 | 双冗余 110/220V 电源 |
| 环境 | 工作温度：50°C至95°C（10°F至35°F） |
建筑与设计
Diamanti 设备是 Diamanti 容器堆栈解决方案的物理硬件。 该设备以最小的三节点集群提供，其中每个节点都是一个 1U 机架，提供高达 32TB 的数据存储容量和 960GB 的主机操作系统和 Docker 映像存储。
节点的正面显示了一个铝制格栅，专为高效气流而设计，中间是公司的原木，左上角是一个锁定机构。 在正面的右上角，是提供电源开关的控制面板，以及用于显示系统运行状况的 LED 指示灯。 卸下铝制格栅将显示驱动器插槽位置，还有一个 VGA 和两个 USB 端口。
移动到设备的后部，我们可以看到设备的端口。 这里我们重点介绍左边的两个独立电源和一个通风系统； 中间/右侧是两个管理端口，一个用于连接高性能和低延迟节点的 10GbE 端口，一个 QSFP+ 端口（用于 4x10G SFP+），以及 4 个用于连接键盘和其他外围设备的 USB 端口。
该设备附带预集成的完整软件堆栈，包括操作系统、Docker、Kubernetes 和其他容器融合服务。 它通过浏览器、CLI 或 REST API 和 Diamanti OS 提供仪表板和报告功能。 Diamanti 企业 Kubernetes 平台通过了 K8s 认证； CNCF 组织设计的认证。
对于管理，我们期待 Diamanti 控制台。 打开它，我们直接进入仪表板，其中包含易于快速阅读的基本信息。 在这里我们可以看到有多少节点在运行，有多少容器，有多少 Pod。 CPU、存储、内存和网络的使用情况也很容易在左侧的百分比中看到。 右边是以 Kbps 为单位的带宽。
下一个主要选项卡是创建应用程序。 一旦用户创建了他们想要创建的应用程序，子选项卡就会显示带有一个小 Kubernetes 图标的 Deploy。 用户需要从这里输入名称、图像、环境、端口、卷安装以及 CPU 和内存量等信息。
下一个主要选项卡是应用程序。 主选项卡下方是子选项卡：Pod、Replications Controllers、Replica Sets、Stateful Sets、Daemon Sets、Deployments 和 Jobs。 Pod 为用户提供了所选 Pod 的健康状况以及归属计算、网络和存储的简要摘要。
Stateful Sets 子选项卡使用户能够深入了解集合并在需要时导出它们。 在这里，我们会看到一些基本信息，例如名称、命名空间、所需号码、当前号码、准备就绪的号码、年龄以及采取什么行动的选项。
用户还可以深入查看 Pod 日志以查看活动和任何潜在问题。
下一个主要选项卡是 K8S 配置。 用户可以在这里管理 Kubernetes 相关的应用程序配置，如服务帐户、查看 Secrets、Config Maps 和创建命名空间。
从节点管理选项卡，用户可以查看、添加或删除节点以及监控节点资源利用率。 同样，用户可以在这里监控给定节点和资源的整体健康状况：计算、网络和存储。
正如该选项卡的名称所暗示的那样，存储管理使用户能够查看存储的所有内容，包括卷、快照、驱动器、持久卷、持久卷声明、存储类和备份。 在 Volumes 子选项卡下，我们可以创建新卷或查看现有卷的摘要，包括其运行状况、存储吞吐量和使用情况。
Drives 子选项卡允许用户查看物理驱动器利用信息，例如驱动器所在的插槽、其 S/N、原始容量、可用容量、分配的容量、其固件以及它所处的状态。驱动器可以从此子选项卡进行格式化。
Persistent Volumes 子选项卡允许用户创建或导出持久卷，并提供诸如其名称、类型容量、访问、回收、状态、声明、存储可用性、年龄和操作列表（包括编辑、导出和删除）等信息。删除。
Persistent Volume Claims 对 PVC 的作用与上述相同。
我们的下一个主要选项卡是网络管理选项卡。 用户可以在这里创建、删除、编辑或导出网络。 这里我们给出了名称、组、是否为默认网络、主机网络、其子网、网关、起始地址、结束地址和 IP 地址等信息。
用户管理相当简单。 管理员可以在这里创建用户和组，并设置各种访问控制策略。
高级设置允许管理员创建和调整集群和性能层。
虽然我们通常会逐步介绍各种管理功能，让读者大致了解他们逐步了解某些内容时会发生什么，但我们这次做的事情有点不同。 我们还运行了我们的基准测试，以便我们可以看到 GUI 在其上运行更重的工作负载时的表现。 对于这些基准中的每一个，我们都将位于“节点管理”选项卡中。
通过我们的基本（随机和顺序）测试，您可以轻松地看到右侧的计算和性能指标。
我们的 SQL 测试对计算和网络造成的损失相当小，而存储达到近 1 万次 IOPS。
最后，我们给出了一个示例，说明在我们的 Oracle 测试运行时会发生什么。
性能
VDBench 工作负载分析
在对存储阵列进行基准测试时，应用程序测试是最好的，综合测试排在第二位。 虽然不能完美代表实际工作负载，但综合测试确实有助于为具有可重复性因素的存储设备建立基线，从而可以轻松地在竞争解决方案之间进行同类比较。 这些工作负载提供了一系列不同的测试配置文件，包括“四个角”测试和常见的数据库传输大小测试，以及来自不同 VDI 环境的跟踪捕获。 所有这些测试都利用通用的 Vdbench 工作负载生成器和脚本引擎来自动化和捕获大型计算测试集群的结果。 这使我们能够在各种存储设备上重复相同的工作负载，包括闪存阵列和单个存储设备。
简介：
- 4K 随机读取：100% 读取，128 个线程，0-120% 重复率
- 4K 随机写入：100% 写入，64 线程，0-120% iorate
- 64K 顺序读取：100% 读取，16 线程，0-120% 迭代
- 64K 顺序写入：100% 写入，8 个线程，0-120% 迭代
- 综合数据库：SQL 和 Oracle
在我们所有的 VDBench 测试中，我们基于一次运行 3、6、9 或 12 个 Vdbench pod 的不同部署测试了 Diamanti 设备，以突破设备的极限。 从随机 4K 读取性能开始，所有 Vdbench pod 都以 120μs 的延迟启动； IO 性能介于 3 个 pod 的 95,863 IOPS 和 12 个 pod 的 269,208 IOPS 之间。 查看峰值性能，所有配置都保持在 600μs 延迟以下。 使用 3 个 Vdbench pod，我们在 947,619μs 的延迟下看到了 370 IOPS 的峰值； 6 个 pod，峰值 1,745,344 IOPS，延迟 436μs； 有 9 个 pod，峰值为 2,492019 IOPS，延迟为 447μs； 最后一个部署是 12 个 pod，峰值为 2,753,170 IOPS，延迟为 554μs。
查看 4K 写入性能，所有测试部署在 300 微秒的延迟下开始，但在达到最大性能时迅速增加到 26 毫秒到 28 毫秒。 性能在 3 个 pod 时达到 13,719 IOPS 的峰值； 6 个 pod，27,747 IOPS； 9 个 pod，42,805 IOPS； 12 个 pod，58,559 IOPS。 在添加更多 pod 时表现出稳定的性能提升。
切换到顺序工作负载，我们查看设备的 64K 读取性能，这里的 3 pod 部署以 14,560 IOPS 或 910MB/s 开始，延迟为 297μs。 所有其他部署开始时接近 18,000 IOPS 或 1.1GB/s，延迟为 227μs。 关于部署的峰值性能，3 pod 部署在 143,431μs 的延迟下继续达到 9 IOPS 或 327GB/s 的峰值。 所有其他部署的峰值性能几乎相同，均为 179,000 IOPS 或 11.1GB/s，12 个 pod 部署是唯一通过 1ms 延迟标记的部署。
在 64K 顺序写入中，Vdbench 的所有部署都以接近 350μs 的延迟开始。 部署达到峰值如下：3 个 pod，9,693 IOPS 或 606MB/s，延迟为 4.9ms； 6 个 pod，22,202 IOPS 或 1.39GB/s，延迟为 4.3ms； 9 个 pod，30,475 IOPS 或 1.9GB/s，延迟为 4.7 毫秒； 最后，12 个 pod 达到 32,052 IOPS 或 2.4GB/s 的峰值，延迟为 4.9ms。
我们的下一组测试是我们的 SQL 工作负载：SQL、SQL 90-10 和 SQL 80-20。 对于 SQL，所有部署都在 180 微秒的延迟下启动。 3 个 pod 以 26,291 IOPS 开始，并以 261,573 IOPS 达到峰值，延迟为 366μs。 6 个 pod 开始时为 57,061 IOPS，峰值为 570,642 IOPS，延迟为 336μs。 9 个 pod 以 86,197 IOPS 开始，峰值为 885,269 IOPS，延迟为 332μs。 12 个 pod 部署以 101,753 IOPS 开始，并以 1,106,860 IOPS 达到峰值，延迟为 346μs。
对于 SQL 90-10，所有部署都以接近 200 微秒的延迟开始。 3 pod 部署开始时为 10,753 IOPS，峰值为 105,877 IOPS，延迟为 904μs。 6 个 pod 开始时为 49,361 IOPS，峰值为 245,158 IOPS，延迟为 782μs。 9 个 pod 以 80,157 IOPS 开始，峰值为 401,444 IOPS，延迟为 716μs。 12 个 pod 部署开始时的 IOPS 为 55,748，峰值为 554,685 IOPS，延迟为 690μs。
对于我们最后的 SQL 测试，80-20，我们看到 Vdbench 部署也开始非常接近 200μs 延迟。 部署达到峰值如下：3 个 pod 部署为 57,944 IOPS，延迟为 1.6 毫秒； 6 个 pod 的峰值为 132,384 IOPS，延迟为 1.4 毫秒； 9 个 pod 217,273 IOPS，延迟为 1.3ms； 12 个 pod 部署达到 305,426 IOPS 的峰值，延迟为 1.2 毫秒。
接下来是我们的 Oracle 工作负载：Oracle、Oracle 90-10 和 Oracle 80-20。 使用 Oracle，所有部署都在 210 微秒内启动。 在这里，我们看到了部署的峰值性能。 3 个 pod 达到 54,844 IOPS 的峰值，延迟为 2.2 毫秒。 6 个 pod 的峰值为 125,633 IOPS，延迟为 1.9 毫秒。 9 个 pod 的峰值为 206,024 IOPS，延迟为 1.7 毫秒。 12 个 pod 部署达到 290,313 IOPS 的峰值，延迟为 1.6 毫秒。
在 Oracle 90-10 中，部署启动时间不到 200 微秒。 3 个 pod 部署达到 106,182 IOPS 的峰值，延迟为 620μs。 6 个 pod 的峰值为 243,383 IOPS，延迟为 541μs。 9 个 pod 的峰值为 393,727 IOPS，延迟为 502μs。 最后，12 个 pod 部署达到 544,584 IOPS 的峰值，延迟为 483μs。
对于 Oracle 80-20，我们又一次看到所有部署以 210 微秒的延迟开始。 查看部署的峰值性能，我们看到 3 个 pod 的峰值为 58,037 IOPS，延迟为 1.1 毫秒； 6 个 pod 的峰值为 132,911 IOPS，延迟为 991μs； 9 个 pod 的峰值为 215,817 IOPS，延迟为 915μs； 最后，12 个 pod 部署达到 304,391 IOPS 的峰值，延迟为 865μs。
结语
Kubernetes 已经被小公司接受，现在正在成熟为大多数（如果不是所有）财富 500 强公司正在关注的一项技术，并且一些更具前瞻性的公司正在开始实施。 Kubernetes 仅出现了 5 年，但已经通过了技术采用曲线上的创新者阶段，稳固地处于早期采用者的阵营中。 这种在技术采用曲线上的定位很重要，因为 Kubernetes 社区已经找到了让 Kubernetes 运行的方法，现在正专注于让它运行良好，我们希望诸如此类的测试将帮助 Kubernetes 消费者决定与哪些供应商合作并通过给供应商一个标准来帮助他们进行比较。
Diamanti 使用 D10 容器设备构建了一个引人注目的 Kubernetes 解决方案，提供了一个信息丰富且易于使用的管理界面和一个用于托管容器的非常快速的后端存储平台。 由于这仍然是一个新兴领域，市场上没有很多完全充实的解决方案，但从我们所看到的情况来看，D10 能够达到我们传统上从存储或 HCI 解决方案。 性能通常非常出色，从我们的集群测试 2.7 到 4 个 pod 中提供超过 3 万 IOPs 12K 随机读取。 从延迟的角度来看，我们开始时刚好超过 100 微秒，最高时为 600 微秒。 在存储方面，它的性能令人难以置信，而且来自一个非常令人难以置信的新兴技术平台。 从写入的角度来看，该设备提供 50k IOPS 4K 随机，这似乎是唯一的弱点，但公司应该能够通过软件甚至存储介质解决这个问题。 连续带宽提供超过 11GB/s 的读取速度，同样非常强大且可用的性能，峰值写入速度为 2.4GB/s。
总的来说，对于在其环境中部署 Kubernetes 的客户，Diamanti D10 容器设备从托管和存储的角度为那些希望认真研究快速和松散的容器市场的人提供了一个很好的交钥匙方法。 公平地说，这并不适合所有人，集群的目标非常具体。 但是，如果您符合该目标，Diamanti 提供的正是这些客户想要的，它是专门为这些类型的新兴容器工作负载而构建的。 虽然完全有可能利用适用于 VMware 的 PKS 或更专注于企业的替代解决方案，但 Diamanti 提供了一个复杂性较低的系统，并且与传统企业堆栈相比应该具有成本优势。 由于解决方案的完整性（它具有用于更改的良好 GUI）和非常好的性能配置文件，我们确定 D10 是当之无愧的 StorageReview 编辑选择奖得主。
