Oracle Cloud Infrastructure Compute Bare Metal Instanceのレビュー

Oracle Cloud Infrastructureには、コンピューティング、ストレージ、ネットワーキング、データベース、ロード・バランシングなど、クラウドベースのデータセンターを構築するために必要なすべてのインフラストラクチャを含む幅広いサービスが含まれています。このレビューの文脈では、Oracle Cloud Infrastructure Computeカテゴリに興味があり、特にベアメタル・インスタンスに焦点を当てています。ほとんどのクラウドプロバイダーと同様に、オラクルは仮想化されたコンピューティングインスタンスを提供しますが、他のほとんどの仮想サービスとは異なり、オラクルは、低遅延を必要とするアプリケーション向けに、最大 25TB の NVMe ストレージを含む形状でこれらをサポートできます。オラクルは、これらの優れた点と同様に、業界初の高性能ベアメタル・インスタンスを提供することで、クラウド・コンピューティング・パフォーマンスの水準をさらに引き上げました。これは、レイテンシが最優先されるミッションクリティカルなアプリケーションに最適です。インスタンスには、最大 52 個の OCPU、768GB RAM、デュアル 25GbE NIC、およびローカル接続された最大 51TB の NVMe ストレージが搭載されています。さらに多くの機能をご希望の場合は、最大 512TB のネットワーク接続型 NVMe ブロックストレージと GPU オプションをご利用いただけます。 Oracle のさまざまなコンピューティング製品はすべて、競合を最小限に抑え、パフォーマンスを最大化するように調整された、高度に最適化されたソフトウェアデファインドネットワーク上で実行されます。

Oracle Cloud Infrastructureには、コンピューティング、ストレージ、ネットワーキング、データベース、ロード・バランシングなど、クラウドベースのデータセンターを構築するために必要なすべてのインフラストラクチャを含む幅広いサービスが含まれています。このレビューの文脈では、Oracle Cloud Infrastructure Computeカテゴリに興味があり、特にベアメタル・インスタンスに焦点を当てています。ほとんどのクラウドプロバイダーと同様に、オラクルは仮想化されたコンピューティングインスタンスを提供しますが、他のほとんどの仮想サービスとは異なり、オラクルは、低遅延を必要とするアプリケーション向けに、最大 25TB の NVMe ストレージを含む形状でこれらをサポートできます。オラクルは、これらの優れた点と同様に、業界初の高性能ベアメタルインスタンスを提供することで、クラウドコンピューティングパフォーマンスの水準をさらに引き上げました。これは、レイテンシが最優先されるミッションクリティカルなアプリケーションに最適です。インスタンスには、最大 52 個の OCPU、768GB RAM、デュアル 25GbE NIC、およびローカル接続された最大 51TB の NVMe ストレージが搭載されています。さらに多くの機能をご希望の場合は、最大 512TB のネットワーク接続型 NVMe ブロックストレージと GPU オプションをご利用いただけます。 Oracle のさまざまなコンピューティング製品はすべて、競合を最小限に抑え、パフォーマンスを最大化するように調整された、高度に最適化されたソフトウェアデファインドネットワーク上で実行されます。

現時点ではさまざまなクラウド製品があり、AWS、Google Cloud Platform、Microsoft Azure を筆頭に大規模なクラウド製品もいくつかあります。これらのクラウドサービスプロバイダーは多くの優れた製品やサービスを提供していますが、一般的に欠けているものの 1 つはパフォーマンスです。クラウドとオンプレミスを比較すると、オンプレミスは常にクラウドに圧倒的に勝ります。 Oracle は、クラウドインフラストラクチャ製品によってこの見方を変えようとしています。

オラクルのコンピューティング製品には、パフォーマンス、可用性、汎用性、ガバナンスなど、オンプレミスのストレージやサーバーに期待される機能が備わっています。パフォーマンス面では、ミッションクリティカルなアプリケーションのピークで一貫したパフォーマンスをサポートし、最近発表されたエンドツーエンドのクラウドインフラストラクチャ SLA、この記事の執筆時点では、業界で同様のものはこれだけです。この製品は、DNS、ロードバランシング、レプリケーション、バックアップ、ストレージスナップショット、クラスタリングなどの複数のレイヤーでの可用性をサポートします。コンピューティング製品は、シングルコア VM から 52 コアシングルテナントベアメタルまで多岐にわたり、一般的なワークロードから HPC クラスターまであらゆるものを実行する多用途性を提供します。また、Oracle のベアメタルインスタンスを使用すると、オンプレミスサーバーには他のテナントや Oracle プロバイダーソフトウェアが含まれないため、顧客はオンプレミスサーバーの分離と制御が可能になります。

Oracle Cloudのコンピューティング製品には、ベアメタル・インスタンス、ベアメタルGPUインスタンス、VMインスタンスなど、いくつかの「形状」があります。このレビューでは、Oracle によれば最大 5.1 万 IOPS を実現でき、ミッションクリティカルなデータベースアプリケーション、HPC ワークロード、I/O 集中型の Web アプリケーションなどのユースケース向けのベアメタルインスタンスに注目します。比較のために、ローカル NVMe ストレージ (DenseIO) とネットワークブロックストレージ (標準) を使用した Oracle の VM 形状も示します。

マネジメント

Oracle Cloud Infrastructureの管理GUIは非常に簡単に理解できます。メインページには、必要に応じてウォークスルーとサポートが表示されます。上部にはテナントまたはアカウント、使用しているリージョン（この場合は us-ashburn-1）が表示され、ホーム（メインページ）、アイデンティティ、コンピューティング、データベース、ネットワーキング、ストレージ、監査のタブが表示されます。、および電子メール。今回のテストでは、DenseIO2 と Standard2 が示されています。

このレビューはコンピューティング側に焦点を当てているため、そのタブの下を見ると、パフォーマンステストに使用するインスタンスが表示されます。各インスタンスには、名前、形状、リージョン、可用性ドメイン、および作成日があります。左側で、ユーザーは状態 (たとえば「実行中」) を選択してリストを変更できます。

右側の省略記号をクリックすると、インスタンスをさらに深く掘り下げることができます。 BM.DenseIO2.52 を見ると、インスタンスが実行されているかどうか、およびそれに関する詳細な情報が簡単にわかります。ここでもタグを関連付けることができます。情報の上部には、カスタムイメージの作成、インスタンスの開始、停止、再起動、終了、タグの適用を行う機能が表示されます。下にスクロールすると、ブロックボリュームをアタッチすることもできます。

「ネットワーク」タブで、使用されている仮想クラウド・ネットワークを確認したり、仮想クラウド・ネットワークを作成したりできます。 VCNについては、リージョン、デフォルトルートテーブル、DNSドメイン、作成日などの情報があります。ここでも右側の省略記号を使用すると、ドリルダウン、タグの適用、サブネットの作成が可能になります。

[ストレージ] タブで、ユーザーは自分のコンパートメント内のブロックボリュームを確認し、さらにブロックボリュームを作成できます。ブロックボリュームは作成日ごとにリストされ、ユーザーは詳細情報をドリルダウンしたり、手動バックアップを作成したり、インスタンスからブロックボリュームをデタッチしたり、ボリュームを削除したり、タグを適用したりできます。

また、Audit が示すように、日付と時刻の範囲を選択することで、過去のイベントをすばやく確認できます。これにより、企業は、あらゆるイベントや環境の変化に対するユーザーとアクションがキャプチャされる管理コンプライアンスのニーズを満たすことができます。

性能

VDBench ワークロード分析

これらのOracle Cloudインスタンスのパフォーマンスを評価するために、各プラットフォームにローカルにインストールされたvdbenchを利用しました。テストはすべてのローカルストレージに同時に分散されたため、BV（ブロックボリューム）と NVMe ストレージの両方が存在する場合は、一度に 12 つのグループをテストしました。どちらのストレージタイプでも、各デバイスの XNUMX% を割り当て、それらをまとめてグループ化し、適度な量のデータの局所性を備えたピークのシステムパフォーマンスを調べました。

これらのワークロードは、「4 コーナー」テスト、一般的なデータベース転送サイズテスト、さまざまな VDI 環境からのトレースキャプチャに至るまで、さまざまなテストプロファイルを提供します。これらのテストはすべて、スクリプトエンジンを備えた共通の vdBench ワークロードジェネレーターを利用して、大規模なコンピューティングテストクラスターの結果を自動化して取得します。これにより、フラッシュアレイや個々のストレージデバイスを含む幅広いストレージデバイスにわたって同じワークロードを繰り返すことができます。

プロフィール：

4K ランダム読み取り: 100% 読み取り、128 スレッド、0 ～ 120% の読み取り
4K ランダム書き込み: 100% 書き込み、64 スレッド、0 ～ 120% の書き込み
64K シーケンシャル読み取り: 100% 読み取り、16 スレッド、0 ～ 120% の iorate
64K シーケンシャル書き込み: 100% 書き込み、8 スレッド、0 ～ 120% iorate
合成データベース: SQL および Oracle
VDI フルクローンおよびリンククローントレース

リモートブロックデバイス (BV) と NVMe の両方を検討します。パフォーマンスに大きな差があるため、結果を 2 つのグラフに分けました (遅延が大きく離れているため、グラフが非常に読みにくくなります)。このレビューでは、ベアメタル (BM) 構成と VM 構成の両方について、BV での標準および高密度 IO 実行と、NVMe での高密度 IO 実行の両方を調べます。

BV のピーク 4K 読み取りを見ると、53 つの実行すべてがミリ秒未満の強力なレイテンシで始まりました。最初に剥離したのは VM.Standard で、60,591 IOPS をわずかに下回り、その後 15 ミリ秒の遅延でピークに達した 1 IOPS になりました。次にミリ秒未満のレイテンシを突破したのは VM.DenseIO で、標準とほぼ同じ地点で 72,626 ミリ秒を超えましたが、レイテンシ 7.5 ミリ秒で 235 IOPS に達しました。どちらのベアメタル実行も、DenseIO 実行時のレイテンシが約 252,275 IOPS になるまで、ミリ秒未満のレイテンシパフォーマンスではるかに優れており、レイテンシ 4.1 ミリ秒で最高 250 IOPS に達しました。 BM.Standard は、1ms を超える前に約 258,329K IOPS まで到達し、レイテンシー 4.05ms で XNUMX IOPS に達しました。

NVMe のピーク 4K 読み取りパフォーマンスを見ると、両方の実行で全体の遅延がミリ秒未満でした。 VM.DenseIO は、レイテンシ 569,534μs で 214 IOPS に達しました。 BM.DenseIO のピークは 4,419,490 IOPS で、遅延はわずか 174.6 μs でした。

BV のランダム 4K 書き込みピークパフォーマンスに切り替えると、VM が BM よりもはるかに早くピークに達し、以前と同様の順位になっていることがわかります。 VM.Standard は、ミリ秒未満の遅延を突破する前に約 63 IOPS に達し、77,229 ミリ秒の遅延で 5.3 IOPS に達しました。 VM.DenseIO はパフォーマンスが少し良くなり、69 ミリ秒を超える前に約 1 IOPS に達し、レイテンシ 84,274 ミリ秒で 3.9 IOPS に達しました。 BM.DenseIO は、レイテンシが 263 ミリ秒を超える前に 1 IOPS を超えることができ、レイテンシ 280,158 ミリ秒で 2.02 IOPS に達しました。また、BM.Standard は、ミリ秒未満のレイテンシを超える前に約 278 IOPS を達成する最高のパフォーマンス構成であり、レイテンシ 280,844 ミリ秒で 1.84 IOPS に達しました。

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/秒で 968 ミリ秒のレイテンシーを突破しました。そして、遅延が 8.2 ミリ秒に上昇しても、どちらも多かれ少なかれ同じパフォーマンスを維持しました。ここでも、BM.Standard と BM.DenseIO で同様のことが確認され、どちらも約 1K IOPS または 37.5GB/s で 2.35 ミリ秒を割りました。どちらの構成も、47 ミリ秒の遅延で 2.95 IOPS または 8.4 GB/秒のすぐ北でピークに達しました。

NVMe シーケンシャル 64K 読み取りでは、両方の構成が一貫してミリ秒未満のレイテンシーを維持しました。 VM.DenseIO は、レイテンシ 39,512 μs で 2.5 IOPS または 403GB/s でピークに達しましたが、BM.DenseIO は、レイテンシ 323,879 μs で 20.2 IOPS または 361GB/s でピークに達しました。

BV の 64K シーケンシャル書き込みでは、VM.Standard と VM.DenseIO で同様の現象が再び見られ、どちらも 1K IOPS または 12MB/s のパフォーマンスで 770ms のレイテンシーを突破しています。どちらも 15.1 ミリ秒のレイテンシーで約 943K IOPS または 3.1MB/秒に達しました。 BM.Standard と BM.DenseIO ではどちらも約 1K IOPS または 42GB/s で 2.6ms のレイテンシーを突破し、BM.DenseIO は 46,768ms のレイテンシーで 2.92 IOPS または 2.6GB/s でピークに達しました。 BM.Standard のピークは 46,787 IOPS または 2.92GB/秒で、遅延は 3.4 ミリ秒でした。

NVMe の 64K シーケンシャル書き込みでは、VM.DenseIO と BM.DenseIO の両方のレイテンシパフォーマンスが再びミリ秒未満でしたが、両方ともレイテンシのスパイクも発生しました (BM.DenseIO の最終的なパフォーマンスの低下と相まって)。 VM.DenseIO は 25K IOPS または 1.56GB/s でピークに達し、最大 311μs のスパイクの後、レイテンシーは 754μs でした。 BM.DenseIO はピークパフォーマンス (レイテンシ 160,895 μs で 10.1 IOPS または 170GB/s) よりはるかに優れていましたが、レイテンシも上昇して最後に若干低下し、132,192 IOPS または 8.8GB/s で終了しました。レイテンシーは310μsです。

BV の SQL ワークロードでは、VM.Standard が最初に約 1 IOPS で 50 ミリ秒を超え、ピークは 73,259 IOPS、レイテンシは 3.4 ミリ秒でした。 VM.DenseIO は、約 1 IOPS で 58 ミリ秒の遅延を超え、78,624 ミリ秒の遅延で 3.1 IOPS に達しました。 BM では、どちらも 1K 付近までレイテンシが 275ms 未満にとどまりました (BM.DenseIO の実行はもう少し長くなります)。 BM.Standard は 305,368 ミリ秒のレイテンシーで 1.7 IOPS でピークに達しましたが、BM.DenseIO は 307,979 ミリ秒のレイテンシーで 1.35 IOPS でピークに達しました。

NVMe 用の SQL では、VM.DenseIO のピークが 188,786 μs で 167 IOPS に達し、全体的にミリ秒未満のレイテンシが発生しました。 BM.DenseIO のピークは 1,684,869 IOPS、遅延は 142μs でした。

BV の SQL 90-10 ベンチマークでは、両方の VM が約 58K IOPS でミリ秒未満のレイテンシパフォーマンスを達成しました。 VM.Standard は、レイテンシ 71,691 ミリ秒で 3.5 IOPS に達しました。 VM.DenseIO は、レイテンシ 79,033 ミリ秒で 3.05 IOPS に達しました。 BM.Standard は、約 1 IOPS のパフォーマンスで 270 ミリ秒の遅延を突破し、303,904 ミリ秒の遅延で 1.7 IOPS に達しました。 BM.DenseIO は、約 290 IOPS まではミリ秒未満のレイテンシを持ち、307,472 ミリ秒のレイテンシで 1.34 IOPS に達しました。

NVMe SQL 90-10 の場合、VM.DenseIO は 172,693μs のレイテンシーで 182 IOPS でピークに達しました。 BM.DenseIO は、1,328,437μs で 165 IOPS でピークに達しました。

BV の SQL 80-20 ベンチマークでは、VM.Standard は 54 ミリ秒を超える前に約 1 IOPS に達し、レイテンシ 72,204 ミリ秒で 3.4 IOPS に達しました。 VM.DenseIO は、約 59 IOPS まではミリ秒未満の遅延でしたが、78,787 ミリ秒の遅延で 2.99 IOPS に達しました。 BM.Standard は、280 ミリ秒未満のレイテンシで約 1 IOPS まで実行され、300,014 ミリ秒のレイテンシで 1.6 IOPS に達しました。 BM.DenseIO は、約 1 IOPS で 285 ミリ秒のレイテンシを突破し、299,730 ミリ秒のレイテンシで 1.3 IOPS でピークに達し、その後パフォーマンスが低下しました。

NVMe の SQL 80-20 ベンチマークでは、VM.DenseIO は 144,010μs のレイテンシーで 218 IOPS でピークに達しました。 BM.DenseIO は、パフォーマンスがわずかに低下する前に、レイテンシ 1,114,056μs で 182 IOPS でピークに達しました。

BV を使用した Oracle ワークロードでは、VM.Standard は約 52 IOPS に達するまでミリ秒未満のレイテンシパフォーマンスを示し、レイテンシ 70,096 ミリ秒で 3.4 IOPS に達しました。 VM.DenseIO は、約 1 IOPS で 58 ミリ秒の遅延を突破し、75,000 ミリ秒の遅延で 3.1 IOPS に達しました。 BM.Standard は、1K 付近で 255ms のレイテンシーを突破し、ピークパフォーマンスは 280,599 IOPS、レイテンシーは 1.41ms でした。 BM.DenseIO は、約 260 IOPS まではミリ秒未満のレイテンシでしたが、レイテンシ 267,632 ミリ秒で 1.3 IOPS に達しました。

NVMe を使用した Oracle ワークロードでは、VM.DenseIO のピークパフォーマンスが 132,553 IOPS、遅延が 257μs でした。 BM.DenseIO を使用した場合、ピークパフォーマンスは 1,043,104 IOPS、レイテンシは 199μs でした。

Oracle 90-10 for BV では、VM.Standard の遅延は 54 IOPS をわずかに超えるまではミリ秒未満で、ピークに達したときは 72,533 IOPS、遅延は 2.2 ミリ秒でした。 VM.DenseIO は、約 1 IOPS で 61 ミリ秒のレイテンシーを突破し、76,908 ミリ秒のレイテンシーで 1.86 IOPS でピークに達しました。どちらの BM も、297 ミリ秒のレイテンシーを突破する前に 1 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 ミリ秒未満で約 1 に達し、レイテンシ 74,032 ミリ秒で 2.14 IOPS に達しました。 VM.DenseIO のレイテンシは約 51K まではミリ秒未満で、レイテンシ 75,666ms で 2 IOPS に達しました。どちらの BM も、295 ミリ秒を切る前に約 1 IOPS まで到達しました。 BM.Standard のピークは 306,955 IOPS、遅延は 1.14 ミリ秒でした。 BM.DenseIO は、レイテンシ 295μs で約 893K IOPS でピークに達しました。

NVMe を搭載した Oracle 80-20 では、VM.DenseIO のピークは 108,483 IOPS、遅延は 195μs でした。 BM.DenseIO は、レイテンシ 956,326μs で 158 IOPS に達しました。

次に、VDI フルクローンについて調べました。 BV を使用したブートでは、VM.Standard は 1 IOPS をわずかに下回る 40 ミリ秒を突破し、レイテンシー 56,057 ミリ秒で 4.2 IOPS に達しました。 VM.DenseIO は、約 43 IOPS まではミリ秒未満のレイテンシで達成し、レイテンシ 61,570 ミリ秒で 3.6 IOPS に達しました。どちらの BM も、200K IOPS しきい値をわずかに超えるまで、ミリ秒未満の遅延がありました。どちらも、パフォーマンスが低下する前に、レイテンシ 220 で約 2.1K IOPS でピークに達しました。

NVMe を使用したフルクローンブートの場合、VM.DenseIO は 136μs のレイテンシーで約 235K IOPS でピークに達しました。 BM.DenseIO のピークは 1,032,322 IOPS、遅延は 213μs でした。

BV を使用した VDI フルクローン初期ログインでは、どちらの VM もミリ秒未満のレイテンシで約 41 IOPS に達しました。VM.Standard はレイテンシ 55,522 ミリ秒でピーク 3.7 IOPS、VMDenseIO はレイテンシ 59,560 ミリ秒でピーク 3.6 IOPS でした。。どちらの BM も、203 IOPS 付近でミリ秒未満のレイテンシーを突破しました (標準は高密度の前にあります)。 BM.Standard は 225 ミリ秒のレイテンシで約 2.04 IOPS でピークに達し、BM.DenseIO は 224,385 ミリ秒のレイテンシで 1.8 IOPS でピークに達しました。

NVMe を使用した VDI フルクローンの初期ログインの場合、VM.Standard のピークは 59,883 IOPS、遅延は 506 μs でした。そして、BM.DenseIO は 467,761μs のレイテンシーで 262 IOPS でピークに達しました。

BV を使用した VDI フルクローン Monday Login では、VM.Standard のレイテンシが 36 IOPS 手前までミリ秒未満で、ピーク値は 50,685 IOPS、レイテンシは 2.3 ミリ秒でした。 VM.DenseIO は、1 IOPS のすぐ北までは 38 ミリ秒未満で実行され、53,304 ミリ秒のレイテンシーで 2.2 IOPS に達しました。 BM.Standard は、約 1 IOPS で 205 ミリ秒の遅延を突破し、224,764 ミリ秒の遅延で 1.5 IOPS でピークに達しました。 BM.DenseIO は 1K 付近で 210ms を超え、ピーク時の IOPS は 220K 強、レイテンシは 1.2ms でした。

NVMe を使用した VDI フルクローン Monday Login では、レイテンシ 44,384 μs で 356 IOPS の VM.DenseIO のピークパフォーマンスが示されました。 BM.DenseIO は、レイテンシ 356,691μs で 252 IOPS でピークに達しました。

テストの最終選択は、VDI リンククローンを対象としています。再び BV を使用したブートテストから始めると、VM.Standard の遅延は約 29 IOPS まではミリ秒未満で、最大約 38 IOPS、遅延は 2.4 ミリ秒でした。 VM.DenseIO は、32 ミリ秒を切る前に約 1 IOPS まで到達し、同様に 38 ミリ秒の遅延で約 2.16 IOPS でピークに達しました。どちらの BM も、遅延が 100 ミリ秒を超える前に、約 1 IOPS に到達しました。どちらも、ピークパフォーマンスは約 114K IOPS、遅延は 3ms でした。

NVMe 用の VDI リンククローンブートでは、VM.DenseIO のピークは 65,384 IOPS、遅延は 238μs でした。 BM.DenseIO は、レイテンシ 555,004 μs で 217 IOPS に達しました。

BV による初期ログインでは、両方の VM が約 1 IOPS で 28 ミリ秒のレイテンシを突破しました。VM.Standard はレイテンシ 36,682 ミリ秒でピーク 1.6 IOPS、VM.DenseIO はレイテンシ 38,525 ミリ秒でピーク 1.6 IOPS でした。どちらの BM も、約 1 IOPS で 132 ミリ秒のレイテンシを突破しました。BM.Standard は、レイテンシ 140,848 ミリ秒でピーク 1.3 IOPS、BM.DenseIO は、レイテンシ 139,883 ミリ秒でピーク 1.2 IOPS でした。

NVMe を使用した最初のログインでは、VM.DenseIO では 24,228 IOPS および 326 μs のピークパフォーマンスが見られ、BM.DenseIO では 242,778 IOPS および 234 μs のピークパフォーマンスが見られました。

最後に、BV を使用した VDI リンククローン Monday Login を使用すると、VM.Standard は約 27 IOPS (ピーク時 39,874 IOPS、レイテンシ 2.86 ミリ秒) までミリ秒未満のレイテンシパフォーマンスを実現しました。 VM.DenseIO は約 1 IOPS で 25 ミリ秒を突破し、42,469 IOPS と 3 ミリ秒の遅延でピークに達しました。両方の BM のレイテンシは約 135 IOPS までミリ秒未満で、両方とも 146 IOPS でピークに達しました。denseIO のレイテンシは 1.6 ミリ秒、標準のレイテンシは 1.76 ミリ秒でした。

NVMe を使用した VDI リンククローン Monday Login では、VM.DenseIO のピークは 34,016 IOPS、レイテンシは 464μs でした。 BM.DenseIO のピークは 260,527 IOPS、レイテンシは 317μs でした。

まとめ

オラクルのクラウド・インフラストラクチャは、クラウドの主な問題の 25 つであるパフォーマンスかその不足に対処し、ベアメタル・インスタンスでそれに対処します。オラクルは、ベアメタルおよび仮想コンピューティングインスタンスに加え、クラウドで他に類を見ないパフォーマンスを実現する最大 5.1 TB の NVMe ストレージを備えた NVMe バージョンを提供します。 Oracle が見積もっている最大 52 万 IOPS のパフォーマンスを達成するには、NVMe ストレージ以上のストレージが必要です。インスタンスには、最大 768 個の OCPU、25GB RAM、デュアル 51GbE NIC、およびローカル接続された最大 XNUMXTB の NVMe ストレージも搭載されています。このレベルのパフォーマンスは、主にミッションクリティカルなデータベースアプリケーション、HPC ワークロード、I/O 集中型の Web アプリケーションなどのユースケースに使用されます。

パフォーマンス面では、ローカル NVMe ストレージ (DenseIO) とネットワークブロックストレージ (Standard) の両方を使用して、ベアメタル (BM) シェイプと VM シェイプの両方に対して VDBech テストを実行しました。一言で言えば、そのパフォーマンスは私たちを驚かせました。 DenseIO と Standard の間のレイテンシの差が非常に大きく、すべてを 32 つのセットにするとグラフが読みにくくなるため、テストごとに 52 セットのグラフを実行しました。これらのインスタンスのストレージパフォーマンスが従来のストレージと比較してどれほど優れているかという点では、クラウドの代替品はもちろんのこと、市場で最高の共有ストレージオプションの多くに匹敵します。 iSCSI 経由でホストされバックアップされる接続された BV は、低遅延でスループットと帯域幅の強力な組み合わせを提供します。これを状況に合わせて説明すると、250 個の OCPU インスタンスに接続された XNUMX 個の BV を使用した多くのテストでは、ラボでテストしたオールフラッシュストレージアレイのパフォーマンスを超えていることがわかりました。実際には若干高速だったものもあるかもしれませんが、クラウドインスタンスを XNUMX 万ドル以上の AFA、FC スイッチング、および複数のコンピューティングホストと比較していることを考えると、これは非常に印象的です。

ただし、Oracle Cloud ベアメタルインスタンスを本当に素晴らしいものにしているのは、ローカルに接続された NVMe ストレージです。 DenseIO2.8 には 1 つのデバイスがあり、DenseIO2.52 には 8 つのデバイスがあり、これらのインスタンスのパフォーマンスは数百万 IOPS で測定されます。 NVMe SSD を 1 基搭載したインスタンスでは、ランダム 4K 読み取り速度の最高速度が 569k IOPS に達しましたが、NVMe SSD を 8 基搭載したインスタンスでは、パフォーマンスが 4.4 万 IOPS まで急上昇しました。帯域幅も冗談ではありませんでした。小さいインスタンスでは読み取りのピークが 2.5GB/s でしたが、大きいインスタンスでは最高で 20GB/s を超えました。結局のところ、NVMe シェイプはローカルに接続されたストレージであり、保護する必要があるため、必ずバックアップ計画を立ててください。

オラクルは最高仕様のサーバーとストレージをクラウドに構築しました。ベアメタルインスタンスに匹敵する唯一のことは、ローカルでホストされる最高スペックのサーバーと、それをサポートする他のすべてのコンポーネントとサービスを構築することです。すべてのクラウドソリューションと同様に、オラクルはインスタンスのオンとオフを切り替えるための流動性と、必要に応じてストレージ要件を調整する柔軟性を提供します。このような例では、明らかに問題となるのはコストです。 Oracle Cloud 内でインスタンスをオンラインにすることの利便性と、自社のデータセンターに同等のハードウェアをセットアップするのに必要な労力と費用が、おそらく重要な決定要因となります。 NVMe 接続ストレージは高価ですが、私たちが確認したパフォーマンス上の利点には異論の余地はありません。大規模なデータセットの処理時間の影響を受けるビジネスを行っている場合、分析などのワークロードを完了するためのソリューションとして、当社が使用した NVMe ベースのシェイプほど簡単かつ迅速なソリューションはありません。また、標準で付属しているブロックの形状が悪かったわけではなく、NVMe の形状が他のブロックを覆い隠すほど非現実的でした。結論としては、高性能クラウドから測定可能な価値を引き出せる先進的な企業は、Oracle の取り組みを確実に評価する必要があるということです。クラウドを利用する場合には多くの選択肢がありますが、Oracle Cloudベアメタル・インスタンスほど高速なものはなく、これらのソリューションがクラウド・サービスに与えられる最初のEditor's Choice Awardの受賞者にふさわしいものであることは明らかです。プロバイダー。