Microsoft Azure Stack HCI 評論（帶有英特爾傲騰 NVMe 的 DataON HCI-224）

到目前為止我們已經 深入了解 Microsoft Azure Stack HCI，微軟 Azure 雲服務的本地實施。 Azure Stack HCI 可被視為兩全其美的平台類型。 它擁有 Azure 的所有管理工具，如 Azure Monitor、Azure 安全中心、Azure 更新管理、Azure 網絡適配器和 Azure 站點恢復，同時在本地存儲數據並滿足某些法規。 Azure Stack HCI 分為三個部分：軟件定義的架構、Azure 服務和硬件。

到目前為止我們已經 深入了解 Microsoft Azure Stack HCI，微軟 Azure 雲服務的本地實施。 Azure Stack HCI 可被視為兩全其美的平台類型。 它擁有 Azure 的所有管理工具，如 Azure Monitor、Azure 安全中心、Azure 更新管理、Azure 網絡適配器和 Azure 站點恢復，同時在本地存儲數據並滿足某些法規。 Azure Stack HCI 分為三個部分：軟件定義的架構、Azure 服務和硬件。

正如我們在文章中詳述的那樣，選擇正確的硬件很重要，“硬件在 Microsoft Azure Stack HCI 中的重要性” 部署 Azure Stack HCI 的第一步是找到經過認證的硬件供應商，在本例中為 DataON。 DataON 多年來一直與 Microsoft 和 Intel 建立牢固的合作夥伴關係，並將這種合作夥伴關係在 Intel Select 配置中充分實現 Azure Stack HCI 的硬件佈局。 與英特爾合作的一個有趣方面是能夠利用該公司的 PMEM（當然還有其最新的處理器）與 Azure Stack HCI。

在許多情況下，DataON HCI Intel Select 解決方案在其自己的機架中進行配置和運輸，可立即部署。 這種交付方法在現有 IT 基礎設施有限或不存在的邊緣特別有用。 在 StorageReview 實驗室中，我們部署了四個存儲和計算節點、域控制器和交換機，如下圖所示。

構建和設計

我們審查的 Microsoft Azure Stack HCI 集群構建在 DataON HCI-224 全閃存 NVMe 平台上。 這些服務器的尺寸為 2U，前面有 24 個 NVMe 托架，為基於 PCIe 的組件提供了大量的後部擴展。 標籤與啞光黑色驅動器盒形成鮮明對比，如果需要換出，可以輕鬆發現特定驅動器。 一切都有標籤，這並不少見，但標籤的範圍是。 我們的部署有每個節點標記（1 到 4），以及許多其他項目，可以輕鬆地在數據中心部署和管理。

我們的配置配備了 48 個 NVMe SSD，或每個節點 12 個。 其中包括四個 375GB Intel Optane P4800X SSD 和八個 Intel P4510 2TB SSD。

在後面，我們有兩個雙端口 100G Mellanox Connect-X 5 NIC，通過兩個 Mellanox 100G 交換機 (SN2100) 為集群網絡流量提供完全冗餘的連接。 在我們的工作室照片中沒有顯示所有連接，在適當的網絡電纜的每一端都有完整的標籤，以允許在部署階段進行無錯誤的佈線。

在此之前，我們從來沒有將這種級別的文檔放入標籤中的解決方案。 Microsoft 和 DataON 使部署 Azure Stack 成為一個輕鬆的過程，因此客戶可以立即開始運營。 每根電纜都根據特定用途進行了顏色編碼，並標記了每一端的位置。 結合 DataON 為客戶提供的定製表，它幾乎可以保證無錯誤部署。 在我們的部署中，系統在發貨前預先配置了 IP 地址，並標記了用於管理和 IPMI 的 IP 地址。

管理和可用性

對於在 Windows Server 上運行 Hyper-V 商店的買家來說，Microsoft Azure Stack HCI 將是一個輕鬆的過渡。 許多相同的管理工具已經到位，其中許多提供了更加集成和簡單的工作流程。 在我們的審查過程中，我們利用 Windows 故障轉移集群管理器來管理 DataOn HCI 集群，並利用 Windows 管理中心來監控工作負載並查看它們的執行情況。

首先通過登錄到其中一個節點的 Microsoft 遠程桌面 (RDP) 會話查看更多節點級別，我們查看了 Windows 故障轉移集群管理器。 這提供了節點級別的管理功能以及集群級別的可見性。 這種類型的訪問將更適合於初始部署，其中日常監控將從 Windows 管理中心進行。

首先，我們單擊我們的特定集群並獲取有關它的一般信息、配置它的能力以及查看資源。 這提供了所選集群的摘要視圖，使您可以查看問題所在並開始深入研究特定區域。

接下來是故障轉移角色。 在這裡我們可以看到集群上運行的所有 Hyper-V 虛擬機。 顯示的是我們用於對集群進行壓力測試的許多 vmfleet 虛擬機。

Networks 允許我們查看哪些集群網絡可用以及每個網絡的狀態。 選擇集群網絡可以讓您看到與其關聯的底層網卡及其 IP 地址。

在存儲選項下是磁盤、池和機箱。 對於磁盤，可以單擊虛擬磁盤並獲取狀態、分配位置、所有者節點、磁盤編號、分區樣式和容量等信息。 用戶還可以更深入地挖掘更多信息，例如池 ID、名稱和描述，以及虛擬磁盤 ID、名稱和描述、運行狀況和運行狀態以及彈性。

存儲池類似，有一些存儲池的信息，如狀態、健康、所有者節點、運行狀態和整體容量，以及空閒和已用空間。

在 Nodes 下，可以很容易地看到集群中的所有節點及其狀態。

在右側，可以切換到故障轉移磁盤並在底部查看給定節點的單個磁盤。

從同一個側邊欄，還可以查看給定節點的網絡。

雖然 Windows 故障轉移集群管理器是一種更“注重細節”的管理設備，但它需要用戶通過 Windows 遠程桌面連接到服務器本身（或連接到該集群的另一台服務器）才能使用它。 雖然這種管理方式適用於許多用途，但 Microsoft 確實通過一個名為 Windows Admin Center 的新平台使事情變得更容易。 與故障轉移群集管理器不同，Windows Admin Center 完全基於 Web 瀏覽器，可以更輕鬆地從工作場所的任何計算機或平板電腦進行連接。 它還提供了現代化且美觀的外觀和感覺，使日常監控成為一項更愉快的任務。 它提供了對許多相同信息的查看，更側重於 Failover Cluster Manager 不提供相同程度的活動監控。

一旦 Windows Admin Center 與群集相關聯，您就可以深入到特定區域以查看和管理操作。 在這裡，我們看到整體集群計算性能信息，它跟踪 VM 使用的整體資源。

雖然 Windows Admin Center 非常適合查看活動，但您仍然可以與群集中的 VM 進行交互。 下面我們啟動了一些 vmfleet 虛擬機。

用戶還可以深入了解特定虛擬機的信息。

在角色下，我們對角色的看法略有不同，但大多數關鍵信息都是相同的。

在設置下，用戶可以下載、安裝和更新 Azure 的擴展。

通過 Windows Admin Center，我們還可以進入 Hyper-Converged Cluster Manager 以更仔細地查看計算和存儲。 我們打開儀表板，其中包含服務器、驅動器、虛擬機、卷的數量以及 CPU、內存和存儲的使用情況等一般信息。 儀表板底部是集群性能，它被分解為特定的時間範圍、IOPS 和延遲。

在計算下，管理員可以自己深入服務器進行管理，包括從集群中刪除服務器。 這裡有關於所用服務器的一般信息，例如正常運行時間、位置、域、製造商、型號、序列號、操作系統名稱、版本和內部版本號。 此外，用戶還可以查看特定於服務器的性能。

單擊“卷”選項卡可為用戶提供集群上所有捲的摘要。 卷的健康狀況用顏色編碼：綠色代表健康，紅色代表嚴重，黃色代表警告。 還跟踪所有捲的性能，按時間範圍分解為 IOPS、延遲和吞吐量。

向下鑽取到單個卷可提供該卷的特定屬性，包括狀態、文件系統、路徑、故障域感知、總大小、已用大小、彈性和占用空間。 可以在此處關閉或打開可選功能（重複數據刪除和壓縮以及完整性校驗和）。 容量以圖形方式顯示，顯示已用與可用。 再一次，我們看到了性能。

在“驅動器”選項卡下，我們獲得了系統中所有驅動器的摘要。 在這裡，我們可以看到驅動器總數，以及是否有任何與卷顏色編碼相同的警報。 我們還可以看到容量：已用、可用和保留。

Clinking on Inventory，我們得到所有驅動器的列表和一些細節。 詳細信息包括驅動器的狀態、型號、容量大小、類型、用途以及使用的存儲量。

我們可以深入到單個驅動器並查看狀態、位置、大小、類型、用途、製造商、型號、序列號、固件版本以及它所在的存儲池等屬性。我們可以看到已使用的容量與單個驅動器的可用性及其在 IOPS、延遲和吞吐量方面的性能相比。

在性能下方，我們還可以看到驅動器延遲和錯誤統計信息。

性能

Microsoft Azure Stack 生態系統內部的性能一直很好，這是一個從存儲空間時代開始就成功的強項。 考慮到這一點，我們在本次審查中查看了一些常見的基準測試工作負載，以讓用戶了解該平台與市場上其他 HCI 解決方案的比較情況。 考慮到這一點，我們使用工作負載來強調隨機的小塊大小以及大塊傳輸，以展示該 Microsoft 解決方案可以提供的潛力。 在我們的 Azure Stack HCI 審查中，我們利用 vmfleet 進行性能基準測試，而在 VMware 或裸機 Linux 上，我們使用 vdbench。

對於此處的性能，我們使用 2 向鏡像和 3 向鏡像測試了系統。 鏡像是指數據保護的方式（兩份或三份）。 顯然副本越多，用戶就會損失一些容量。 從性能的角度來看，3-way 應該通過增加並行性帶來更好的讀取，而 2-way 的寫入性能更好，網絡流量減少三分之一。

對於我們的 4K 隨機測試，2 路鏡像的讀取吞吐量為 2,204,296 IOPS，平均延遲為 247µs，寫入吞吐量為 564,601 IOPS，平均延遲為 3.69ms。 3 路的讀取吞吐量為 2,302,610 IOPS，平均延遲為 170µs，寫入吞吐量為 338,538 IOPS，平均延遲為 9.12ms。 為了正確看待這一點，VMware 的 vSAN 產品在每個節點使用兩個 Optane SSD 和四個 NVMe Capacity SSD，在峰值時測得 521K IOPS 4K 讀取和 202K IOPS 寫入。

接下來我們看看我們的 32K 順序基準測試。 對於讀取，我們看到 2 路達到 42.59GB/s，3 路達到 39.48GB/s。 對於寫入，HCI 為我們提供了 13.8 路 2GB/s 和 7.19 路 3GB/s 的速度。

繼續我們的順序工作，我們繼續進行 64K 測試。 在這裡，2 路達到 39.5GB/s 讀取和 15.24GB/s 寫入，3 路達到 46.47GB/s 讀取和 7.72GB/s 寫入。 與 vSAN 相比，讀取帶寬差異甚至沒有接近，其測試中的帶寬超過 5.3GB/s，塊大小為 64K。 寫入帶寬也有類似的差異，其中 vSAN 的最高速度為 2.55GB/s。

我們的下一個基準測試是具有混合讀/寫性能的 SQL。 在這裡，2-way 的吞吐量為 1,959,921 IOPS，平均延遲為 324µs。 3 路達到 1,929,030 IOPS，平均延遲為 185µs。 SQL 工作負載是 Azure Stack HCI 能夠顯示其優勢的另一個領域，測得的 IOPS 不到 2 萬，而 VMware 的 vSAN 在相同的工作負載配置文件中測得 321k IOPS。

使用 SQL 90-10，2 路達到 1,745,560 IOPS，平均延遲為 411µs，3 路達到 1,547,388 IOPS 和 285µs 的延遲。

對於 SQL 80-20，2-way 的吞吐量為 1,530,319 IOPS，延遲為 581µs。 3 路達到 1,175,469 IOPS 和 681µs 的延遲。

規格書

接下來是我們的 SPECsfs 2014 SP2 基準測試——這裡是我們的新測試。 SPECsfs 是衡量文件服務器吞吐量和響應時間的基準套件。 該基準測試為我們提供了一種標準化的方法來比較不同供應商平台的性能。 基準測試通過設置一個比例並遞增直到點延遲對於基準測試的規格來說太大。 在這裡，我們看看在 11 毫秒被破壞之前可以完成的規模，以及服務器在延遲數失敗時命中的帶寬。

我們將在這里首先查看延遲，因為它將更清楚地說明為什麼帶寬在第二部分停止的位置。 2 路和 3 路的規模及其延遲如下表所示：

正如您所看到的，兩種配置都在接近 250µs 時開始，2 路略低於並始終保持這種狀態。 在 1500 的比例下，3 向失敗達到 11.285ms，使其範圍為 262µs 至 10.45ms。 2-way 在 1800 的規模達到 11.7ms 時失敗，使其範圍為 243µs 到 11.07ms。

下表顯示了每個構建時每個配置的帶寬，上面列出了延遲中的故障。

對於帶寬，兩種配置以 300MB/s 的間隔並駕齊驅，直到 3 路以 4.02GB/s 的最終通過帶寬和 2-way 的最終通過帶寬為 4.62GB/s 的延遲失敗為止秒。

結論

我們已經有一段時間沒有深入了解 Microsoft 以存儲為中心的堆棧中的任何東西了； 男孩，我們很高興回來。 通過重新命名的 Microsoft Azure Stack HCI 解決方案，Microsoft 做了一些非常基礎和基礎的事情，很容易被低估。 微軟已經讓他們的 HCI 解決方案操作起來非常簡單，沒有覆蓋任何東西來抑制性能。 從我們的數字中可以看出，我們一直在測試的 DataON 集群已經發布了巨大的數字，這是我們在中端市場 4 節點 HCI 集群中看到的最快的。 公平地說，我們甚至都沒有測試 DataON 最新最好的硬件。 雖然此配置顯然毫不遜色，配有 Intel Optane DC SSD，但 DataON 提供了更快的解決方案，這些解決方案利用了 Intel Xeon 第二代 CPU、持久內存和更快的網絡。 Azure Stack HCI 解決方案提供更多性能這一事實令人興奮，但同樣重要的是要記住該解決方案也可以縮小到小至 雙節點超融合 可為低成本邊緣或 SMB 解決方案配置無交換機。

深入研究性能數據，Microsoft Azure Stack HCI 集群能夠提供數量驚人的 I/O 和帶寬。 在四角領域，我們測量了超過 2.3M IOPS 4K 隨機讀取和 3 向鏡像配置，以及 338k IOPS 4K 隨機寫入。 如果您需要更高的寫入性能，2 路鏡像配置能夠將 4K 隨機寫入速度提升至 564k IOP。 不過，查看帶寬才是 Microsoft Azure Stack 真正的亮點。 在我們的 64K 塊順序傳輸工作負載中，2 路鏡像測得 39.5GB/s 讀取和 15.24GB/s 寫入，而 3 路鏡像測得 46.47GB/s 讀取和 7.72GB/s 寫入。 這遠遠超過了我們從過去的 HCI 集群中測得的數據。

總體而言，事實證明，Microsoft 的 Azure Stack HCI 解決方案易於部署、易於管理且性能卓越，應有盡有。 DataON 作為解決方案的合作夥伴，擅長提供交鑰匙構建，提供帶有明確說明的按規格構建的硬件，最終以可立即啟動和運行的配置出售。 在很多情況下，客戶甚至可以跳過佈線，因此這真的取決於具體需求。 不管怎樣，Azure Stack HCI 與 Intel Optane、Intel NVMe SSD 和 Mellanox 100G 網絡的結合證明了自己是一股不可忽視的力量。

DataON HCI 解決方案

討論這篇評論

註冊 StorageReview 時事通訊