毫无疑问,亚马逊在通过其 EC2(弹性计算云)网络服务提供的各种云服务方面处于领先地位。 凭借相对简单的配置过程以及轻松扩展或缩小实例和存储需求的能力,EC2 旨在以具有成本效益的价格点提供云的所有承诺。 但是,对于某些人来说,云不仅仅是灵活性和易于部署; 这是关于性能。 能够为分析等关键应用程序启动或关闭强大的环境所带来的商业利益通常远远超过通过 OPEX 而不是 CAPEX 的长期投资这样做的费用。 为此,亚马逊在 3 月推出了 iXNUMX 裸机实例系列,该系列提供对底层服务器 CPU 和内存资源的直接访问。
毫无疑问,亚马逊在通过其 EC2(弹性计算云)网络服务提供的各种云服务方面处于领先地位。 凭借相对简单的配置过程以及轻松扩展或缩小实例和存储需求的能力,EC2 旨在以具有成本效益的价格提供云的所有承诺。 但是,对于某些人来说,云不仅仅是灵活性和易于部署; 这是关于性能。 能够为分析等关键应用程序启动或关闭强大的环境所带来的商业利益通常远远超过通过 OPEX 而不是 CAPEX 的长期投资这样做的费用。 为此,亚马逊在 3 月推出了 iXNUMX 裸机实例系列,该系列提供对底层服务器 CPU 和内存资源的直接访问。
i3.metal 实例建立在 Nitro 系统之上,Nitro 系统是 AWS 构建的硬件卸载和服务器保护组件的集合,可以“安全地为 EC2 实例提供高性能网络和存储资源”。 i3.metal 实例还利用 AWS Cloud 提供的所有其他服务,例如我们在本次审查中使用的 Elastic Block Store (EBS)。 这些实例还具有高达 15.2TB 的 NVMe SSD 支持的实例存储,以及提供 2.3 个超线程内核(36 个逻辑处理器)和 72 GiB 内存的 512 GHz Intel Xeon 处理器。 在结构方面,i3.metal 实例提供高达 25 Gbps 的聚合网络带宽,通过基于 Elastic Network Adapter (ENA) 的增强型网络推动高网络吞吐量和降低延迟。
在 EC2 中,有许多实例类型。 i3 实例属于“存储优化”类别,i3.metal 实例是该组中性能最高的。 下表突出显示了实例类型的系列和配置。
型号 | 虚拟CPU | 内存 (GiB) | 网络性能 | 存储 (TB) |
i3.大号 | 2 | 15.25 | 高达 10 Gb | 1 个 0.475 NVMe 固态硬盘 |
i3.xlarge | 4 | 30.5 | 高达 10 Gb | 1 个 0.95 NVMe 固态硬盘 |
i3.2x大 | 8 | 61 | 高达 10 Gb | 1 个 1.9 NVMe 固态硬盘 |
i3.4x大 | 16 | 122 | 高达 10 Gb | 2 个 1.9 NVMe 固态硬盘 |
i3.8x大 | 32 | 244 | 10千兆 | 4 个 1.9 NVMe 固态硬盘 |
i3.16x大 | 64 | 488 | 25千兆 | 8 个 1.9 NVMe 固态硬盘 |
i3.金属 | 72 | 512 | 25千兆 | 8 个 1.9 NVMe 固态硬盘 |
i3.metal 实例在 AWS 美国东部(弗吉尼亚北部)、美国东部(俄亥俄)、美国西部(俄勒冈)、欧洲(法兰克福)和欧洲(爱尔兰)区域可用,并且可以作为按需实例购买,预留实例(3 年、1 年和可转换),或作为 Spot 实例。 出于本次审查的目的,我们在北弗吉尼亚地区进行了测试。 我们对 NVMe 存储和 EBS 块卷进行了测试。
性能
VDBench 工作负载分析
为了评估 EC2 i3.metal 实例的性能,我们利用本地安装的 VDBench 来测试 EBS (30x1TB) 和 NVMe (8×1.7TB) 存储。 对于这两种存储类型,我们为每个设备分配了 12% 的空间,并将它们组合在一起,以查看具有适度数据局部性的峰值系统性能。
这些工作负载提供了一系列不同的测试配置文件,包括“四个角”测试、常见的数据库传输大小测试,以及来自不同 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
- VDI 链接克隆跟踪
我们在这篇评论中同时研究了 EBS 和 NVMe。 由于存在显着的性能差异,我们将结果分为两个图表(延迟会相距甚远,以至于图表很难阅读)。
我们的第一个测试着眼于 4K 随机读取。 在这里,EBS 实例直到最后都具有亚毫秒级的延迟性能。 在大约 64K IOPS 时,它的延迟飙升至 59.46 毫秒,性能为 64,047 IOPS。
查看 NVMe 4K 峰值随机读取,我们发现该实例的性能要好得多。 该实例的峰值为 2,802,904 IOPS,延迟为 348 微秒。
使用 EBS 的 4K 随机写入与使用 EBS 的 4K 读取几乎相同。 该实例提前 1 毫秒中断,大约 60K IOPS,并以 64,003 IOPS 的峰值达到 29.97 毫秒的延迟。
对于实例的 NVMe 版本,延迟略有上升,但仍低于 1 毫秒。 该实例的峰值为 920,975 IOPS,延迟为 545 微秒。
切换到顺序测试,对于 EBS 64K 峰值读取性能,实例在大约 70K IOPS 或大约 450MB/s 时具有亚毫秒延迟,并在 17,360 IOPS 或 1.08GB/s 时达到峰值,延迟为 27.65ms。
NVMe 的 64K 顺序读取为我们提供了 244,037 IOPS 或 15.25GB/s 的峰值性能,延迟为 514μs。
使用 EBS 进行 64K 写入时,实例启动时间超过 1 毫秒,峰值为 17,359 IOPS 或 1.08GB/s,延迟为 13.8 毫秒。
64K 顺序写入是我们第一次看到 NVMe 实例超过 1 毫秒。 该实例的峰值为 58,572 IOPS 或 3.66GB/s,延迟为 1.08 毫秒。
切换到我们的 SQL 工作负载后,EBS 实例具有亚毫秒级延迟性能,直到大约 55K IOPS 并达到 64,036 IOPS 的峰值,延迟为 14.93 毫秒。
对于实例的 NVMe 版本,我们看到 SQL 测试的峰值性能为 834,231 IOPS,延迟为 302μs。
对于带有 EBS 的 SQL 90-10,该实例在 1K IOPS 左右再次突破 55ms 延迟,并继续以 64,036ms 延迟达到 14.99 IOPS 的峰值。
SQL 90-10 中实例的 NVMe 版本具有 605,150 IOPS 的峰值性能和 415μs 的延迟。
带 EBS 的 SQL 80-20 再次给出了几乎相同的数字,亚毫秒延迟结束于 55K IOPS 左右,峰值为 64,036 IOPS,延迟为 14.93ms。
带有 NVMe 的 SQL 80-20 的实例命中数为 511,840 IOPS,延迟为 493μs。
针对 EBS 的 Oracle 测试显示了几乎相同数量的相同奇数峰值性能。 对于 Oracle,该实例达到 64,036 IOPS,延迟为 13.6 毫秒。 在大约 55K IOPS 之前,该实例具有亚毫秒级延迟性能。
使用 NVMe,该实例在 Oracle 测试中达到 457,372 IOPS,延迟为 613μs。
Oracle 90-10 的 EBS 实例峰值为 64,035 IOPS,延迟为 10.3 毫秒。 该实例在大约 1K IOPS 时中断了 55 毫秒。
Oracle 90-10 中实例的 NVMe 版本能够达到 520,448 IOPS,延迟为 333μs。
Oracle 80-20 的 EBS 在 1K IOPS 左右中断了 55ms,峰值达到 64,036 IOPS,延迟为 10.3ms。
采用 NVMe 的实例的峰值性能为 435,265 IOPS,延迟为 400μs。
接下来我们看看我们的 VDI 链接克隆 (LC) 测试。 从启动开始,实例的 EBS 版本在大约 35K IOPS 之前具有亚毫秒级延迟,并以 42,893 毫秒的延迟达到 11.2 IOPS 的峰值。
在我们的 VDI LC 启动测试中,实例的 NVMe 版本能够达到 349,799 IOPS 的峰值和 363μs 的延迟。
对于 VDI LC 初始登录,EBS 实例跨越了 1ms 的线一段时间,然后下降到大约 31K IOPS。 该实例的峰值为 34,486 IOPS 和 6.95 毫秒延迟。
使用 VDI LC 初始登录时,NVMe 实例达到 93,405 IOPS 的峰值,延迟为 677μs。
在 VDI LC Monday Login 中,EBS 实例再次在 1ms 左右徘徊了一段时间,然后在 25K IOPS 左右暴跌并继续达到 34,643 IOPS 的峰值,延迟为 13.85ms。
最后,我们的 VDI LC Monday Login with NVMe 的实例峰值为 119,615 IOPS,延迟为 1.1 毫秒。
总结
亚马逊的云服务通常被认为是最通用的。 虽然计算和存储肯定是多种多样的,但亚马逊也有性能选项。 亚马逊在其 EC2 网络服务上提供了大量的性能选项,包括其 i3 裸机实例。 这些实例利用 AWS Nitro 系统的专用硬件和软件。 i3.metal 实例通过直接访问 CPU 和内存提供更好的性能,同时仍然为用户提供利用其他功能的能力,例如 AWS EBS 附加存储和本地 NVMe 存储。
对于性能,我们测试了块存储 (EBS) 和 NVMe。 这旨在让读者了解在选项方面的期望,并且少一个比另一个更好(通常 NVMe 存储性能更好并且延迟低得多,这就是为什么有两组图表)。 查看 EBS,我们看到了一个模式,其中实例超过 1 毫秒,然后不久之后,延迟增加并完成。 在我们的整个测试过程中,EBS 的峰值约为 64K IOPS,这是 EBS 允许的最大值。 这包括 4K 测试,以及所有三个 SQL 和 Oracle 测试。 对于我们的 VDI 测试,该实例稍微慢了一点。 Amazon 确实表示可以调整设置以获得超过 64K 规定的 IOPS,但实现这一目标的过程并不是大多数客户会体验到的,所以我们没有追求这条道路。
对于我们的 NVMe 测试,我们看到的结果更符合我们的正常基准。 这里的亮点包括 4 万 IOPS 的随机 2.8K 读取性能、4K IOPS 的 920K 写入、64GB/s 的 15.25K 读取以及所有三个测试中超过 500K IOPS 的 SQL 性能(SQL 测试约为 834K IOPS)。 甲骨文在 NVMe 测试中也表现出色,结果介于 435K IOPS 和 520K IOPS 之间。 我们的 VDI 链接克隆显示出强大的引导性能,大约 350K IOPS。 唯一令人失望的是,客户无法在 i3.metal 实例中选择更多本地 NVMe。
总的来说,i3.metal 实例为我们提供了 Amazon 所承诺的一切。 这让想知道他们将获得承诺的服务水平的客户感到放心。 当然,这并非没有成本,与任何云部署一样,关注点将是易用性以及云与其他云提供商与内部部署的结果。 也就是说,如果客户的工作负载可以使用较低的 IOPS 级别,则可以节省相当多的钱。 但是,这实际上取决于特定实例的最终要求。 为此,i3.metal 实例非常适合主流应用程序,这些应用程序不会或不能超过 i3.metal 提供的性能限制,并且不需要 IOPS 本地全闪存阵列可以提供的实例。 此外,如果您已经加入了 Amazon 大家庭,那么迁移到裸机对您来说很熟悉,并且在批量使用多个 AWS 程序时可能会带来成本效益。