毫無疑問，亞馬遜在通過其 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 測試，該實例稍微慢了一點。 亞馬遜確實表示可以調整設置以獲得超過 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 程序時可能會帶來成本效益。
Amazon