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 時打破了 285ms 的延遲，在性能下降之前以 299,730ms 的延遲達到 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.7 毫秒，VMDenseIO 峰值為 59,560 IOPS，延遲為 3.6 毫秒. 兩個 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。
使用 VDI Linked Clone Monday Login with NVMe，VM.DenseIO 達到 34,016 IOPS 的峰值和 464μs 的延遲。 BM.DenseIO 的峰值為 260,527 IOPS，延遲為 317μs。
結論
Oracle 的雲基礎設施解決了雲的主要問題之一——性能或缺乏性能——並通過其裸機實例解決了這個問題。 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 雲裸機實例中看到的更快，這使這些解決方案成為我們授予雲服務的第一個編輯選擇獎的明顯和當之無愧的贏家提供商。
