首页 企业版 Microsoft Azure Stack HCI 评论(带有英特尔傲腾 NVMe 的 DataON HCI-224)

Microsoft Azure Stack HCI 评论(带有英特尔傲腾 NVMe 的 DataON HCI-224)

by StorageReview 企业实验室
微软 Azure Stack HCI 评论 DataON

到目前为止我们已经 深入了解 Microsoft Azure Stack HCI,微软 Azure 云服务的本地实施。 Azure Stack HCI 可被视为两全其美的平台类型。 它拥有 Azure 的所有管理工具,如 Azure Monitor、Azure 安全中心、Azure 更新管理、Azure 网络适配器和 Azure 站点恢复,同时在本地存储数据并满足某些法规。 Azure Stack HCI 分为三个部分:软件定义的架构、Azure 服务和硬件。


到目前为止我们已经 深入了解 Microsoft Azure Stack HCI,微软 Azure 云服务的本地实施。 Azure Stack HCI 可被视为两全其美的平台类型。 它拥有 Azure 的所有管理工具,如 Azure Monitor、Azure 安全中心、Azure 更新管理、Azure 网络适配器和 Azure 站点恢复,同时在本地存储数据并满足某些法规。 Azure Stack HCI 分为三个部分:软件定义的架构、Azure 服务和硬件。

正如我们在文章中详述的那样,选择正确的硬件很重要,“硬件在 Microsoft Azure Stack HCI 中的重要性” 部署 Azure Stack HCI 的第一步是找到经过认证的硬件供应商,在本例中为 DataON。 DataON 多年来一直与 Microsoft 和 Intel 建立牢固的合作伙伴关系,并将这种合作伙伴关系在 Intel Select 配置中充分实现 Azure Stack HCI 的硬件布局。 与英特尔合作的一个有趣方面是能够利用该公司的 PMEM(当然还有其最新的处理器)与 Azure Stack HCI。

在许多情况下,DataON HCI Intel Select 解决方案在其自己的机架中进行配置和运输,可立即部署。 这种交付方法在现有 IT 基础设施有限或不存在的边缘特别有用。 在 StorageReview 实验室中,我们部署了四个存储和计算节点、域控制器和交换机,如下图所示。

建筑与设计

我们审查的 Microsoft Azure Stack HCI 集群构建在 DataON HCI-224 全闪存 NVMe 平台上。 这些服务器的尺寸为 2U,前面有 24 个 NVMe 托架,为基于 PCIe 的组件提供了大量的后部扩展。 标签与哑光黑色驱动器盒形成鲜明对比,如果需要换出,可以轻松发现特定驱动器。 一切都有标签,这并不少见,但标签的范围是。 我们的部署有每个节点标记(1 到 4),以及许多其他项目,可以轻松地在数据中心部署和管理。

我们的配置配备了 48 个 NVMe SSD,或每个节点 12 个。 其中包括四个 375GB Intel Optane P4800X SSD 和八个 Intel P4510 2TB SSD。

在后面,我们有两个双端口 100G Mellanox Connect-X 5 NIC,通过两个 Mellanox 100G 交换机 (SN2100) 为集群网络流量提供完全冗余的连接。 在我们的工作室照片中没有显示所有连接,在适当的网络电缆的每一端都有完整的标签,以允许在部署阶段进行无错误的布线。

StorageReview Microsoft Azure Stack HCI DataON 集群图

在此之前,我们从来没有将这种级别的文档放入标签中的解决方案。 Microsoft 和 DataON 使部署 Azure Stack 成为一个轻松的过程,因此客户可以立即开始运营。 每根电缆都根据特定用途进行了颜色编码,并标记了每一端的位置。 结合 DataON 为客户提供的定制表,它几乎可以保证无错误部署。 在我们的部署中,系统在发货前预先配置了 IP 地址,并标记了用于管理和 IPMI 的 IP 地址。

管理和可用性

对于在 Windows Server 上运行 Hyper-V 商店的买家来说,Microsoft Azure Stack HCI 将是一个轻松的过渡。 许多相同的管理工具已经到位,其中许多提供了更加集成和简单的工作流程。 在我们的审查过程中,我们利用 Windows 故障转移集群管理器来管理 DataOn HCI 集群,并利用 Windows 管理中心来监控工作负载并查看它们的执行情况。

首先通过登录到其中一个节点的 Microsoft 远程桌面 (RDP) 会话查看更多节点级别,我们查看了 Windows 故障转移集群管理器。 这提供了节点级别的管理功能以及集群级别的可见性。 这种类型的访问将更适合于初始部署,其中日常监控将从 Windows 管理中心进行。

首先,我们单击我们的特定集群并获取有关它的一般信息、配置它的能力以及查看资源。 这提供了所选集群的摘要视图,使您可以查看问题所在并开始深入研究特定区域。

接下来是故障转移角色。 在这里我们可以看到集群上运行的所有 Hyper-V 虚拟机。 显示的是我们用于对集群进行压力测试的许多 vmfleet 虚拟机。

Networks 允许我们查看哪些集群网络可用以及每个网络的状态。 选择集群网络可以让您看到与其关联的底层网卡及其 IP 地址。

在存储选项下是磁盘、池和机箱。 对于磁盘,可以单击虚拟磁盘并获取状态、分配位置、所有者节点、磁盘编号、分区样式和容量等信息。 用户还可以更深入地挖掘更多信息,例如池 ID、名称和描述,以及虚拟磁盘 ID、名称和描述、运行状况和运行状态以及弹性。

存储池类似,有一些存储池的信息,如状态、健康、所有者节点、运行状态和整体容量,以及空闲和已用空间。

在 Nodes 下,可以很容易地看到集群中的所有节点及其状态。

在右侧,可以切换到故障转移磁盘并在底部查看给定节点的单个磁盘。

从同一个侧边栏,还可以查看给定节点的网络。

虽然 Windows 故障转移集群管理器是一种更“注重细节”的管理设备,但它需要用户通过 Windows 远程桌面连接到服务器本身(或连接到该集群的另一台服务器)才能使用它。 虽然这种管理方式适用于许多用途,但 Microsoft 确实通过一个名为 Windows Admin Center 的新平台使事情变得更容易。 与故障转移群集管理器不同,Windows Admin Center 完全基于 Web 浏览器,可以更轻松地从工作场所的任何计算机或平板电脑进行连接。 它还提供了现代化且美观的外观和感觉,使日常监控成为一项更愉快的任务。 它提供了对许多相同信息的查看,更侧重于 Failover Cluster Manager 不提供相同程度的活动监控。

一旦 Windows Admin Center 与群集相关联,您就可以深入到特定区域以查看和管理操作。 在这里,我们看到整体集群计算性能信息,它跟踪 VM 使用的整体资源。

虽然 Windows Admin Center 非常适合查看活动,但您仍然可以与群集中的 VM 进行交互。 下面我们启动了一些 vmfleet 虚拟机。

用户还可以深入了解特定虚拟机的信息。

在角色下,我们对角色的看法略有不同,但大多数关键信息都是相同的。

在设置下,用户可以下载、安装和更新 Azure 的扩展。

通过 Windows Admin Center,我们还可以进入 Hyper-Converged Cluster Manager 以更仔细地查看计算和存储。 我们打开仪表板,其中包含服务器、驱动器、虚拟机、卷的数量以及 CPU、内存和存储的使用情况等一般信息。 仪表板底部是集群性能,它被分解为特定的时间范围、IOPS 和延迟。

在计算下,管理员可以自己深入服务器进行管理,包括从集群中删除服务器。 这里有关于所用服务器的一般信息,例如正常运行时间、位置、域、制造商、型号、序列号、操作系统名称、版本和内部版本号。 此外,用户还可以查看特定于服务器的性能。

单击“卷”选项卡可为用户提供集群上所有卷的摘要。 卷的健康状况用颜色编码:绿色代表健康,红色代表严重,黄色代表警告。 还跟踪所有卷的性能,按时间范围分解为 IOPS、延迟和吞吐量。

向下钻取到单个卷可提供该卷的特定属性,包括状态、文件系统、路径、故障域感知、总大小、已用大小、弹性和占用空间。 可以在此处关闭或打开可选功能(重复数据删除和压缩以及完整性校验和)。 容量以图形方式显示,显示已用与可用。 再一次,我们看到了性能。

在“驱动器”选项卡下,我们获得了系统中所有驱动器的摘要。 在这里,我们可以看到驱动器总数,以及是否有任何与卷颜色编码相同的警报。 我们还可以看到容量:已用、可用和保留。

Clinking on Inventory,我们得到所有驱动器的列表和一些细节。 详细信息包括驱动器的状态、型号、容量大小、类型、用途以及使用的存储量。

我们可以深入到单个驱动器并查看状态、位置、大小、类型、用途、制造商、型号、序列号、固件版本以及它所在的存储池等属性。我们可以看到已使用的容量与单个驱动器的可用性及其在 IOPS、延迟和吞吐量方面的性能相比。

在性能下方,我们还可以看到驱动器延迟和错误统计信息。

性能

Microsoft Azure Stack 生态系统内部的性能一直都很好,这是一个从存储空间时代就开始发展起来的强项。 考虑到这一点,我们在本次审查中查看了一些常见的基准测试工作负载,以让用户了解该平台与市场上其他 HCI 解决方案的比较情况。 考虑到这一点,我们使用工作负载来强调随机的小块大小以及大块传输,以展示该 Microsoft 解决方案可以提供的潜力。 在我们的 Azure Stack HCI 审查中,我们利用 vmfleet 进行性能基准测试,而在 VMware 或裸机 Linux 上,我们使用 vdbench。

对于此处的性能,我们使用 2 向镜像和 3 向镜像测试了系统。 镜像是指数据保护的方式(两份或三份)。 显然副本越多,用户就会损失一些容量。 从性能的角度来看,3-way 应该通过增加并行性带来更好的读取,而 2-way 的写入性能更好,网络流量减少三分之一。

对于我们的 4K 随机测试,2 路镜像的读取吞吐量为 2,204,296 IOPS,平均延迟为 247µs,写入吞吐量为 564,601 IOPS,平均延迟为 3.69ms。 3 路的读取吞吐量为 2,302,610 IOPS,平均延迟为 170µs,写入吞吐量为 338,538 IOPS,平均延迟为 9.12ms。 为了正确看待这一点,VMware 的 vSAN 产品在每个节点使用两个 Optane SSD 和四个 NVMe Capacity SSD,在峰值时测得 521K IOPS 4K 读取和 202K IOPS 写入。

接下来我们看看我们的 32K 顺序基准测试。 对于读取,我们看到 2 路达到 42.59GB/s,3 路达到 39.48GB/s。 对于写入,HCI 为我们提供了 13.8 路 2GB/s 和 7.19 路 3GB/s 的速度。

继续我们的顺序工作,我们继续进行 64K 测试。 在这里,2 路达到 39.5GB/s 读取和 15.24GB/s 写入,3 路达到 46.47GB/s 读取和 7.72GB/s 写入。 与 vSAN 相比,读取带宽差异甚至没有接近,其测试中的带宽超过 5.3GB/s,块大小为 64K。 写入带宽也有类似的差异,其中 vSAN 的最高速度为 2.55GB/s。

我们的下一个基准测试是具有混合读/写性能的 SQL。 在这里,2-way 的吞吐量为 1,959,921 IOPS,平均延迟为 324µs。 3 路达到 1,929,030 IOPS,平均延迟为 185µs。 SQL 工作负载是 Azure Stack HCI 能够显示其优势的另一个领域,测得的 IOPS 不到 2 万,而 VMware 的 vSAN 在相同的工作负载配置文件中测得 321k IOPS。

使用 SQL 90-10,2 路达到 1,745,560 IOPS,平均延迟为 411µs,3 路达到 1,547,388 IOPS 和 285µs 的延迟。

对于 SQL 80-20,2-way 的吞吐量为 1,530,319 IOPS,延迟为 581µs。 3 路达到 1,175,469 IOPS 和 681µs 的延迟。

规格书

接下来是我们的 SPECsfs 2014 SP2 基准测试——这里是我们的新测试。 SPECsfs 是衡量文件服务器吞吐量和响应时间的基准套件。 该基准测试为我们提供了一种标准化的方法来比较不同供应商平台的性能。 基准测试通过设置一个比例并递增直到点延迟对于基准测试的规格来说太大。 在这里,我们看看在 11 毫秒被破坏之前可以完成的规模,以及服务器在延迟数失败时命中的带宽。

我们将在这里首先查看延迟,因为它将更清楚地说明为什么带宽在第二部分停止的位置。 2 路和 3 路的规模及其延迟如下表所示:

SPECsfs 延迟(毫秒)
扩展 DataON HCI-224 2路镜 DataON HCI-224 3路镜
100 0.243 0.262
200 0.329 0.371
300 0.466 0.499
400 0.636 0.699
500 0.753 0.896
600 0.953 1.083
700 1.113 1.314
800 1.326 1.557
900 1.501 1.826
1000 1.88 2.167
1100 2.061 2.807
1200 2.323 4.64
1300 2.749 8.557
1400 5.47 10.449
1500 8.616 11.285(失败)
1600 10.485 11.414(失败)
1700 11.069
1800 11.697(失败)
1900 12.51(失败)

正如您所看到的,两种配置都在接近 250µs 时开始,2 路略低于并始终保持这种状态。 在 1500 的比例下,3 向失败达到 11.285ms,使其范围为 262µs 至 10.45ms。 2-way 在 1800 的规模达到 11.7ms 时失败,使其范围为 243µs 到 11.07ms。

下表显示了每个构建时每个配置的带宽,上面列出了延迟中的故障。

SPECsfs 带宽 (KB/s)
扩展 DataON HCI-224 2路镜 DataON HCI-224 3路镜
100 300897 300880
200 600372 600857
300 901672 902964
400 1202779 1203106
500 1504492 1503394
600 1805952 1806455
700 2105973 2108432
800 2408183 2406171
900 2710895 2707106
1000 3007499 3009280
1100 3308648 3308168
1200 3608244 3610219
1300 3910414 3888303
1400 4212976 4026720
1500 4513454 4000079(失败)
1600 4587183 4229678(失败)
1700 4621067
1800 4630352(失败)
1900 4569824(失败)

对于带宽,两种配置以 300MB/s 的间隔并驾齐驱,直到 3 路以 4.02GB/s 的最终通过带宽和 2-way 的最终通过带宽为 4.62GB/s 失败延迟为止秒。

结语

我们已经有一段时间没有深入了解 Microsoft 以存储为中心的堆栈中的任何东西了; 男孩,我们很高兴回来。 通过重新命名的 Microsoft Azure Stack HCI 解决方案,Microsoft 做了一些非常基础和基础的事情,很容易被低估。 微软已经让他们的 HCI 解决方案操作起来非常简单,没有覆盖任何东西来抑制性能。 从我们的数字中可以看出,我们一直在测试的 DataON 集群已经发布了巨大的数字,这是我们在中端市场 4 节点 HCI 集群中看到的最快的。 公平地说,我们甚至都没有测试 DataON 最新最好的硬件。 虽然此配置显然毫不逊色,配有 Intel Optane DC SSD,但 DataON 提供了更快的解决方案,这些解决方案利用了 Intel Xeon 第二代 CPU、持久内存和更快的网络。 Azure Stack HCI 解决方案提供更多性能这一事实令人兴奋,但同样重要的是要记住该解决方案也可以缩小到小至 双节点超融合 可为低成本边缘或 SMB 解决方案配置无交换机。

深入研究性能数据,Microsoft Azure Stack HCI 集群能够提供数量惊人的 I/O 和带宽。 在四角领域,我们测量了超过 2.3M IOPS 4K 随机读取和 3 向镜像配置,以及 338k IOPS 4K 随机写入。 如果您需要更高的写入性能,2 路镜像配置能够将 4K 随机写入速度提升至 564k IOP。 不过,查看带宽才是 Microsoft Azure Stack 真正的亮点。 在我们的 64K 块顺序传输工作负载中,2 路镜像测得 39.5GB/s 读取和 15.24GB/s 写入,而 3 路镜像测得 46.47GB/s 读取和 7.72GB/s 写入。 这远远超过了我们从过去的 HCI 集群中测得的数据。

总体而言,事实证明,Microsoft 的 Azure Stack HCI 解决方案易于部署、易于管理且性能卓越,应有尽有。 DataON 作为解决方案的合作伙伴,擅长提供交钥匙构建,提供带有明确说明的按规格构建的硬件,最终以可立即启动和运行的配置出售。 在很多情况下,客户甚至可以跳过布线,因此这真的取决于具体需求。 不管怎样,Azure Stack HCI 与 Intel Optane、Intel NVMe SSD 和 Mellanox 100G 网络的结合证明了自己是一股不可忽视的力量。

DataON HCI 解决方案

讨论这篇评论

注册 StorageReview 时事通讯