Oracle Cloud Infrastructure 包括各种服务产品，包括计算、存储、网络、数据库和负载平衡——实际上，构建基于云的数据中心所需的所有基础设施。 在这篇评论的上下文中，我们对 Oracle 云基础设施计算类别感兴趣，特别关注它们的裸机实例。 与大多数云提供商一样，Oracle 提供虚拟化计算实例，但与大多数其他虚拟产品不同，Oracle 可以为需要低延迟的应用程序提供包含高达 25TB NVMe 存储的形状来支持这些实例。 尽管如此，Oracle 通过提供业界首个高性能裸机实例进一步提高了云计算性能，非常适合延迟至关重要的任务关键型应用程序。 实例配备多达 52 个 OCPU、768GB RAM、双 25GbE NIC 和多达 51TB 的本地连接 NVMe 存储。 对于那些想要更多的人，可以使用高达 512TB 的网络连接 NVMe 块存储以及 GPU 选项。 所有不同的 Oracle 计算产品都在高度优化的软件定义网络上运行，该网络经过调整以最大限度地减少争用并最大限度地提高性能。
Oracle Cloud Infrastructure 包括各种服务产品，包括计算、存储、网络、数据库和负载平衡——实际上，构建基于云的数据中心所需的所有基础设施。 在这篇评论的上下文中，我们对 Oracle 云基础设施计算类别感兴趣，特别关注它们的裸机实例。 与大多数云提供商一样，Oracle 提供虚拟化计算实例，但与大多数其他虚拟产品不同，Oracle 可以为需要低延迟的应用程序提供包含高达 25TB NVMe 存储的形状来支持这些实例。 尽管如此，Oracle 通过提供业界首个高性能裸机实例进一步提高了云计算性能，非常适合延迟至关重要的任务关键型应用程序。 实例配备多达 52 个 OCPU、768GB RAM、双 25GbE NIC 和多达 51TB 的本地连接 NVMe 存储。 对于那些想要更多的人，可以使用高达 512TB 的网络连接 NVMe 块存储以及 GPU 选项。 所有不同的 Oracle 计算产品都在高度优化的软件定义网络上运行，该网络经过调整以最大限度地减少争用并最大限度地提高性能。
目前有各种各样的云产品，甚至还有几个大型云产品，其中 AWS、谷歌云平台和微软 Azure 位居榜首。 尽管这些云服务提供商提供了许多出色的产品和服务，但他们通常不具备的一件事就是性能。 将云与本地进行比较时，本地总是轻而易举地击败云。 甲骨文希望通过其云基础设施产品改变这种观点。
Oracle 的计算产品具有人们对本地存储或服务器的期望，包括性能、可用性、多功能性和治理。 性能方面支持关键任务应用程序的峰值和一致性能，并由 最近宣布了端到端的云基础架构 SLA，在撰写本文时，这是业内唯一类似的。 该产品支持多层可用性，包括 DNS、负载平衡、复制、备份、存储快照和集群。 计算产品范围从单核 VM 到 52 核单租户裸机，提供了运行从常见工作负载到 HPC 集群的所有内容的多功能性。 借助 Oracle 的裸机实例，客户可以获得本地服务器的隔离和控制权，因为它们不包含其他租户，也没有 Oracle 提供商软件。
Oracle Cloud 的计算产品有多种“形式”，包括裸机实例、裸机 GPU 实例和 VM 实例。 对于本次审查，我们将研究裸机实例，根据 Oracle 的说法，它可以提供高达 5.1 万次 IOPS，并且适用于任务关键型数据库应用程序、HPC 工作负载和 I/O 密集型 Web 应用程序等用例。 为了进行比较，我们还将展示 Oracle 的 VM 形状，具有本地 NVMe 存储 (DenseIO) 和网络块存储（标准）。
管理
Oracle Cloud Infrastructure 的管理 GUI 非常容易理解。 如果需要，主页有演练和帮助。 顶部是租户或帐户、正在使用的区域（在我们的示例中为 us-ashburn-1），以及主页（主页）、身份、计算、数据库、网络、存储、审计的选项卡和电子邮件。 对于我们的测试，显示了 DenseIO2 和 Standard2。
由于本次审查侧重于计算方面，因此在该选项卡下我们可以看到我们将用于性能测试的实例。 每个实例都有其名称、形状、区域、可用性域和创建时间。 在左侧，用户可以通过选择状态来更改列表，例如“正在运行”。
单击右侧的省略号可以让您更深入地了解一个实例。 查看 BM.DenseIO2.52，可以轻松查看实例是否正在运行以及有关它的更深入信息。 标签也可以在这里与之相关联。 信息顶部是创建自定义图像、启动、停止或重新启动实例、终止实例或应用标签的能力。 向下滚动也可以附加块卷。
在“网络”选项卡下，可以看到正在使用的虚拟云网络或创建一个。 对于 VCN，有区域、默认路由表、DNS 域和创建时间等信息。 同样，右侧的省略号允许向下钻取、应用标记和创建子网。
在“存储”选项卡下，用户可以查看其分区中的块卷并创建更多。 块卷按创建日期列出，用户可以深入了解更多信息、创建手动备份、从实例中分离块卷、删除卷或应用标签。
正如审计所暗示的那样，人们可以通过选择日期和时间范围来快速查看过去的事件。 这使企业能够满足管理合规性需求，捕获每个事件或环境变化的用户和操作。
性能
VDBench 工作负载分析
为了评估这些 Oracle 云实例的性能，我们利用了在每个平台上本地安装的 vdbench。 我们的测试同时分布在所有本地存储上，因此如果同时存在 BV（块卷）和 NVMe 存储，我们将一次测试一组。 对于这两种存储类型，我们为每个设备分配了 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 完整克隆和链接克隆跟踪
我们同时关注远程块设备 (BV) 和 NVMe。 由于存在如此显着的性能差异，我们将结果分为两个图表（延迟会相距甚远，以至于图表很难阅读）。 在本次审查中，我们查看了 Bare Metal (BM) 和 VM 配置，其中标准和密集 IO 在 BV 上运行，而密集 IO 仅在 NVMe 上运行。
查看 BV 的峰值 4K 读取，所有四次运行都以强烈的亚毫秒延迟开始。 第一个剥离的是 VM.Standard，使其略低于 53K IOPS，然后达到 60,591 IOPS 的峰值，延迟为 15 毫秒。 下一个打破亚毫秒延迟的是 VM.DenseIO，在与标准相同的位置超过 1 毫秒，但峰值为 72,626 IOPS，延迟为 7.5 毫秒。 两种裸机运行都比 DenseIO 运行亚毫秒延迟性能要好得多，直到大约 235K IOPS，峰值为 252,275 IOPS，延迟为 4.1 毫秒。 BM.Standard 在超过 250 毫秒之前达到了大约 1K IOPS，并以 258,329 毫秒的延迟达到 4.05 IOPS 的峰值。
查看 NVMe 的峰值 4K 读取性能，两次运行始终具有亚毫秒级延迟。 VM.DenseIO 的峰值为 569,534 IOPS，延迟为 214μs。 BM.DenseIO 的峰值为 4,419,490 IOPS，延迟仅为 174.6 μs。
切换到 BV 的随机 4K 写入峰值性能，我们看到与以前类似的位置，VM 的峰值比 BM 早得多。 VM.Standard 在打破亚毫秒延迟之前达到了大约 63K IOPS，并在 77,229ms 延迟时达到了 5.3 IOPS 的峰值。 VM.DenseIO 在超过 69 毫秒之前达到约 1K IOPS 的性能要好一些，峰值为 84,274 IOPS，延迟为 3.9 毫秒。 BM.DenseIO 能够在延迟超过 263 毫秒之前达到 1K IOPS 以上，并以 280,158 毫秒的延迟达到 2.02 IOPS 的峰值。 BM.Standard 是性能最高的配置，在超过亚毫秒延迟之前达到约 278K IOPS，峰值为 280,844 IOPS，延迟为 1.84ms。
对于 4K 写入的 NVMe，BM 的性能再次优于 VM，两者始终具有亚毫秒级延迟性能。 VM.DenseIO 的峰值为 412,207 IOPS，延迟为 141μs。 BM.DenseIO 的峰值为 3,232,215 IOPS，延迟为 125μs。
继续顺序工作，首先我们看一下 BV 的 64K 读取。 VM.Standard 和 VM.DenseIO 均以约 1K IOPS 或 15.5MB/s 的速度打破了 968 毫秒的延迟。 随着延迟攀升至 8.2 毫秒，两者或多或少都保持了相同的性能。 我们再次看到 BM.Standard 和 BM.DenseIO 都以大约 1K IOPS 或 37.5GB/s 的速度突破 2.35 毫秒。 两种配置在 47 毫秒延迟时均达到 2.95K IOPS 或 8.4GB/s 的峰值。
NVMe 顺序 64K 读取使两种配置始终保持低于亚毫秒延迟。 VM.DenseIO 峰值为 39,512 IOPS 或 2.5GB/s，延迟为 403μs，而 BM.DenseIO 峰值为 323,879 IOPS 或 20.2GB/s，延迟为 361μs。
对于 BV 的 64K 顺序写入，我们再次看到 VM.Standard 和 VM.DenseIO 的类似现象都以 1K IOPS 或 12MB/s 的性能打破了 770ms 的延迟。 两者均以 15.1 毫秒的延迟达到约 943K IOPS 或 3.1MB/s 的峰值。 BM.Standard 和 BM.DenseIO 均以约 1K IOPS 或 42GB/s 的速度突破 2.6ms 延迟，而 BM.DenseIO 的峰值为 46,768 IOPS 或 2.92GB/s，延迟为 2.6ms。 BM.Standard 的峰值为 46,787 IOPS 或 2.92GB/s，延迟为 3.4ms。
对于 NVMe 的 64K 顺序写入，VM.DenseIO 和 BM.DenseIO 都再次具有亚毫秒级延迟性能，但两者都出现了延迟峰值（加上 BM.DenseIO 的性能最终降低）。 VM.DenseIO 达到 25K IOPS 或 1.56GB/s 的峰值，在峰值达到 311μs 后延迟为 754μs。 BM.DenseIO 的峰值性能要好得多（160,895 IOPS 或 10.1GB/s，延迟为 170μs），但它最终确实有所下降，延迟也有所上升，最终达到 132,192 IOPS 或 8.8GB/s延迟为 310μs。
在我们针对 BV 的 SQL 工作负载中，VM.Standard 是第一个在大约 1K IOPS 时超过 50ms 的，它的峰值为 73,259 IOPS，延迟为 3.4ms。 VM.DenseIO 在大约 1K IOPS 时延迟超过 58 毫秒，峰值为 78,624 IOPS，延迟为 3.1 毫秒。 对于 BM，两者的延迟都保持在 1 毫秒以下，直到大约 275K（BM.DenseIO 运行时间更长）。 BM.Standard 峰值为 305,368 IOPS，延迟为 1.7ms，而 BM.DenseIO 峰值为 307,979 IOPS，延迟为 1.35ms。
VM.DenseIO 在 188,786 IOPS 和 167μs 时达到峰值，NVMe 的 SQL 在整个过程中再次具有亚毫秒级延迟。 BM.DenseIO 的峰值为 1,684,869 IOPS，延迟为 142μs。
在 BV 的 SQL 90-10 基准测试中，两个虚拟机都以大约 58K IOPS 打破了亚毫秒级延迟性能。 VM.Standard 的峰值为 71,691 IOPS，延迟为 3.5 毫秒。 VM.DenseIO 的峰值为 79,033 IOPS，延迟为 3.05 毫秒。 BM.Standard 在大约 1K IOPS 的性能下打破了 270ms 的延迟，并以 303,904ms 的延迟达到 1.7 IOPS 的峰值。 BM.DenseIO 在达到约 290K IOPS 之前具有亚毫秒延迟，并以 307,472ms 的延迟达到 1.34 IOPS 的峰值。
对于 NVMe SQL 90-10，VM.DenseIO 峰值为 172,693 IOPS，延迟为 182μs。 BM.DenseIO 在 1,328,437μs 时达到 165 IOPS 的峰值。
在 BV 的 SQL 80-20 基准测试中，VM.Standard 在超过 54 毫秒之前达到了大约 1K IOPS，并以 72,204 毫秒的延迟达到 3.4 IOPS 的峰值。 VM.DenseIO 在达到约 59K IOPS 之前具有亚毫秒级延迟，并以 78,787 毫秒的延迟达到 2.99 IOPS 的峰值。 BM.Standard 运行到约 280K IOPS，延迟低于 1ms，峰值为 300,014 IOPS，延迟为 1.6ms。 BM.DenseIO 在大约 1K IOPS 时打破了 285 毫秒的延迟，并在性能下降之前以 299,730 毫秒的延迟达到 1.3 IOPS 的峰值。
在 NVMe 的 SQL 80-20 基准测试中，VM.DenseIO 的峰值为 144,010 IOPS，延迟为 218μs。 BM.DenseIO 的峰值为 1,114,056 IOPS，延迟为 182μs，然后性能略有下降。
在我们使用 BV 的 Oracle 工作负载中，VM.Standard 具有亚毫秒级的延迟性能，直到达到约 52K IOPS 并达到 70,096 IOPS 的峰值，延迟为 3.4 毫秒。 VM.DenseIO 在大约 1K IOPS 时打破了 58ms 的延迟，并在 75,000 IOPS 时达到峰值，延迟为 3.1ms。 BM.Standard 在 1K 左右打破了 255ms 延迟，峰值性能为 280,599 IOPS，延迟为 1.41ms。 BM.DenseIO 在达到约 260K IOPS 之前具有亚毫秒级延迟，并在 267,632 IOPS 时达到峰值，延迟为 1.3 毫秒。
我们使用 NVMe 的 Oracle 工作负载显示 VM.DenseIO 的峰值性能为 132,553 IOPS，延迟为 257μs。 使用 BM.DenseIO，峰值性能为 1,043,104 IOPS，延迟为 199μs。
在用于 BV 的 Oracle 90-10 中，VM.Standard 具有亚毫秒级延迟，直到刚好超过 54K IOPS，峰值为 72,533 IOPS，延迟为 2.2 毫秒。 VM.DenseIO 在大约 1K IOPS 时打破了 61ms 的延迟，并在 76,908 IOPS 时达到峰值，延迟为 1.86ms。 在打破 297 毫秒延迟之前，两个 BM 都达到了 1K IOPS。 BM.Standard 的峰值为 305,771 IOPS，延迟为 1.17 毫秒。 BM.DenseIO 的峰值性能为 297,509 IOPS，延迟为 1.03 毫秒。
在用于 NVMe 的 Oracle 90-10 中，VM.DenseIO 的峰值性能为 133,330 IOPS，延迟为 163μs。 BM.DenseIO 的峰值性能为 1,088,454 IOPS，延迟为 142μs。
在带有 BV 的 Oracle 80-20 中，VM.Standard 在不到 55 毫秒的时间内达到了大约 1K，并以 74,032 毫秒的延迟达到 2.14 IOPS 的峰值。 VM.DenseIO 在大约 51K 之前具有亚毫秒延迟，峰值为 75,666 IOPS，延迟为 2 毫秒。 在打破 295ms 之前，两个 BM 都达到了大约 1K IOPS。 BM.Standard 的峰值为 306,955 IOPS，延迟为 1.14 毫秒。 BM.DenseIO 的峰值约为 295K IOPS，延迟为 893μs。
在带有 NVMe 的 Oracle 80-20 中，VM.DenseIO 峰值为 108,483 IOPS，延迟为 195μs。 BM.DenseIO 的峰值为 956,326 IOPS，延迟为 158μs。
接下来我们研究了 VDI 完整克隆。 对于使用 BV 的引导，VM.Standard 在 1K IOPS 下突破 40ms，并以 56,057ms 的延迟达到 4.2 IOPS 的峰值。 VM.DenseIO 以亚毫秒延迟达到了大约 43K IOPS，并以 61,570 IOPS 达到峰值，延迟为 3.6 毫秒。 两个 BM 都有亚毫秒级延迟，直到刚刚超过 200K IOPS 阈值。 在性能下降之前，两者都达到了约 220K IOPS 的峰值，延迟为 2.1。
对于使用 NVMe 的完整克隆启动，VM.DenseIO 的峰值约为 136K IOPS，延迟为 235μs。 BM.DenseIO 的峰值为 1,032,322 IOPS，延迟为 213μs。
使用 VDI Full Clone Initial Log In with BV，两个虚拟机都达到了大约 41K IOPS，延迟为亚毫秒，VM.Standard 峰值为 55,522 IOPS，延迟为 3.7ms，VMDenseIO 峰值为 59,560 IOPS，延迟为 3.6ms . 两个 BM 都在 203K IOPS 左右打破了亚毫秒延迟（标准先于密集）。 BM.Standard 的峰值约为 225K IOPS，延迟为 2.04ms，而 BM.DenseIO 的峰值为 224,385 IOPS，延迟为 1.8ms。
对于使用 NVMe 的 VDI 完整克隆初始登录，VM.Standard 的峰值为 59,883 IOPS，延迟为 506μs。 BM.DenseIO 的峰值为 467,761 IOPS，延迟为 262μs。
VDI Full Clone Monday Login with BV 具有亚毫秒延迟的 VM.Standard，直到略低于 36K IOPS，峰值为 50,685 IOPS，延迟为 2.3 毫秒。 VM.DenseIO 的执行时间不到 1 毫秒，直到略高于 38K IOPS，峰值为 53,304 IOPS，延迟为 2.2 毫秒。 BM.Standard 在大约 1K IOPS 时打破了 205ms 的延迟，并在 224,764 IOPS 时达到峰值，延迟为 1.5ms。 BM.DenseIO 在 1K 左右超过 210ms，峰值超过 220K IOPS，延迟为 1.2ms。
VDI Full Clone Monday Login with NVMe 显示 VM.DenseIO 的峰值性能为 44,384 IOPS，延迟为 356μs。 BM.DenseIO 峰值为 356,691 IOPS，延迟为 252μs。
我们最终选择的测试着眼于 VDI 链接克隆。 再次开始使用 BV 进行启动测试，VM.Standard 在达到约 29K IOPS 之前具有亚毫秒级延迟，峰值约为 38K IOPS，延迟为 2.4ms。 VM.DenseIO 在突破 32ms 之前达到了大约 1K IOPS，并达到了大约 38K IOPS 的峰值以及 2.16ms 的延迟。 在超过 100 毫秒的延迟之前，两个 BM 都达到了大约 1K IOPS。 两者的峰值性能约为 114K IOPS，延迟为 3 毫秒。
借助适用于 NVMe 的 VDI 链接克隆启动，我们看到 VM.DenseIO 峰值达到 65,384 IOPS，延迟为 238μs。 BM.DenseIO 的峰值为 555,004 IOPS，延迟为 217μs。
使用 BV 初始登录时，两个虚拟机均以大约 1K IOPS 打破了 28 毫秒的延迟，其中 VM.Standard 峰值达到 36,682 IOPS，延迟为 1.6 毫秒，VM.DenseIO 峰值达到 38,525 IOPS，延迟为 1.6 毫秒。 两个 BM 在大约 1K IOPS 时都打破了 132ms 延迟，BM.Standard 峰值达到 140,848 IOPS，延迟为 1.3ms，BM.DenseIO 峰值达到 139,883 IOPS 和 1.2ms 延迟。
使用 NVMe 的初始登录看到 VM.DenseIO 的峰值性能为 24,228 IOPS 和 326μs，BM.DenseIO 的峰值性能为 242,778 IOPS 和 234μs。
最后，使用 VDI Linked Clone Monday Login with BV，VM.Standard 具有亚毫秒级延迟性能，直到大约 27K IOPS，峰值为 39,874 IOPS，延迟为 2.86 毫秒。 VM.DenseIO 在大约 1K IOPS 时突破 25ms，并在 42,469 IOPS 和 3ms 延迟时达到峰值。 两个 BM 都有亚毫秒级的延迟，直到大约 135K IOPS，峰值都在 146K IOPS，denseIO 的延迟为 1.6ms，标准的延迟为 1.76ms。
借助使用 NVMe 的 VDI 链接克隆星期一登录，VM.DenseIO 达到 34,016 IOPS 的峰值和 464μs 的延迟。 BM.DenseIO 的峰值为 260,527 IOPS，延迟为 317μs。
结语
甲骨文的云基础设施解决了云的主要问题之一——性能或缺乏性能——并通过其裸机实例解决了这个问题。 Oracle 提供裸机和虚拟计算实例以及具有高达 25TB NVMe 存储的 NVMe 版本，以提供云中其他任何产品都无法比拟的性能。 要达到 Oracle 高达 5.1 万 IOPS 的报价性能，需要的不仅仅是 NVMe 存储； 这些实例还具有多达 52 个 OCPU、768GB RAM、双 25GbE NIC 和多达 51TB 的本地连接 NVMe 存储。 此级别的性能主要用于任务关键型数据库应用程序、HPC 工作负载和 I/O 密集型 Web 应用程序等用例。
在性能方面，我们使用本地 NVMe 存储 (DenseIO) 和网络块存储（标准）对裸机 (BM) 和 VM 形状进行了 VDBech 测试。 简而言之，表演让我们大吃一惊。 对于每个测试，我们运行两组图表，因为 DenseIO 和标准之间的延迟差异如此之大，如果所有图表都在一组上，图表将难以阅读。 就这些实例与传统存储相比的存储性能而言，它们可以与市场上许多最好的共享存储选项相媲美，更不用说云替代方案了。 通过 iSCSI 托管并备份的附加 BV 提供了以低延迟提供的吞吐量和带宽的强大组合。 为了说明这一点，我们看到许多测试在 32 个 OCPU 实例上附加了 52 个 BV，超过了我们在实验室测试过的全闪存存储阵列的性能。 有些实际上可能稍微快一些，考虑到我们将云实例与 250 万美元以上的 AFA、FC 交换和多个计算主机进行比较，这非常令人印象深刻。
然而，让 Oracle 云裸机实例真正令人难以置信的是本地连接的 NVMe 存储。 DenseIO2.8 有 1 个设备，而 DenseIO2.52 有 8 个，这些实例的性能以百万 IOPS 衡量。 具有 1 个 NVMe SSD 的实例的随机 4K 读取速度最高为 569k IOPS，而具有 8 个 NVMe SSD 的实例的性能飙升至 4.4M IOPS。 带宽也不是开玩笑的。 较小实例的读取峰值为 2.5GB/s，而较大实例的读取峰值超过 20GB/s。 请务必制定备份计划，因为 NVMe 形状毕竟是本地附加存储，需要加以保护。
甲骨文在云中构建了顶级规格的服务器和存储； 唯一可以与他们的裸机实例相媲美的是构建一个本地托管的顶级服务器，以及支持它的所有其他组件和服务。 与所有云解决方案一样，Oracle 提供了打开和关闭实例的流动性以及根据需要调整存储需求的灵活性。 在这些情况下，显而易见的问题是成本。 在 Oracle Cloud 中在线获取实例的便利性与在您自己的数据中心设置类似硬件所需的工作量和费用相比，可能是关键的决定因素。 虽然 NVMe 附加存储很昂贵，但我们看到的性能优势是毋庸置疑的。 如果您的业务受到大型数据集处理时间的影响，那么没有比我们使用的基于 NVMe 的形状更容易或更快地完成分析等工作负载的解决方案了。 并不是标准的附加块形状不好，NVMe 形状太不真实了，它们使其他形状黯然失色。 最重要的是，能够从高性能云中获得可衡量价值的具有前瞻性思维的企业肯定应该评估甲骨文的进展。 迁移到云时有很多选择，但没有什么比我们在 Oracle 云裸机实例中看到的更快，这使这些解决方案成为我们授予云服务的第一个编辑选择奖的明显和当之无愧的赢家提供商。
