Azure NetApp Files 的 Azure VMware 解決方案資料存放區效能考量
本文提供搭配 Azure NetApp Files 使用時，Azure VMware 解決方案 資料存放區設計和重設大小的效能考慮。 此內容適用於虛擬化管理員、雲端架構師或儲存體架構師。
本文中所述的各項考量可協助您以最佳化的成本效益，實現最高層級的應用程式效能。
Azure NetApp Files 為 Azure VMware 解決方案 提供可立即調整、高效能且高度可靠的記憶體服務。 測試包含 Azure VMware 解決方案 與 Azure NetApp Files 之間的各種不同組態。 測試能夠驅動超過 10,500 MiB/秒，以及每秒超過 585,000 個輸入/輸出作業 （IOPS），且只有四部 Azure VMware 解決方案/ESXi 主機和單一 Azure NetApp Files 容量集區。
使用 Azure NetApp Files 達到 Azure VMware 解決方案 更高的記憶體效能
在一個服務層級佈建多個可能較大的資料存放區，或許能降低成本並提高效能。 原因是將負載分散到多個 TCP 數據流，從 Azure VMware 解決方案 主機到數個數據存放區。 您可以透過適用於 Azure VMware 解決方案 TCO 估算器的 Azure NetApp Files 資料存放區，藉由上傳 RVTools 報告或輸入手動平均 VM 調整大小來計算潛在的成本節約。
而要決定如何設定資料存放區時，就管理角度而言，最簡單的解決方案是建立單一 Azure NetApp Files 資料存放區，加以裝載，然後將所有 VM 放入其中。 此種策略雖可適用許多情況，但卻無法應付需要更多輸送量或 IOPS 的場合。 為區分不同的情境，該測試會使用綜合工作負載產生器程式 fio 來評估每種案例的工作負載範圍。 此分析可協助您判斷如何將 Azure NetApp Files 磁碟區佈建為資料存放區，藉以獲致最大的效能和最佳的成本。
開始之前
如需 Azure NetApp Files 效能資料，請參閱：
-
在 Azure VMware 解決方案 主機上，會為每個 NFS 數據存放區建立單一網路連線，類似於在
nconnect=1第 6 節（微調選項）中所參考的 Linux 測試上使用。 此事實是瞭解 Azure VMware 解決方案 如何跨多個數據存放區調整效能的關鍵。
測試方法
本節說明用於測試的方法。
測試案例和反覆項目
此測試遵循「四角」方法，其中包含每項循序和隨機輸入/輸出 (IO) 的讀取作業和寫入作業。 測試的變數包括一對多 Azure VMware 解決方案 主機、Azure NetApp Files 數據存放區、VM（每部主機），以及每個 VM 的 VM 磁碟 （VMDKs）。 其間並已選取下列調整資料點，以找出指定案例的最大輸送量和 IOPS：
- 調整 VMDK 數目，每一 VMDK 均位於其在單一 VM 的自身資料存放區上。
- 調整單一 Azure NetApp Files 資料存放區上每部主機的 VM 數目。
- 調整 Azure VMware 解決方案 主機數目，每個主機都有一個 VM 共用單一 Azure NetApp Files 數據存放區。
- 調整 Azure NetApp Files 資料存放區的數目，每個數據存放區都有一個 VMDK 平均分散到 Azure VMware 解決方案 主機。
同時測試小型和大型區塊作業，並逐一查看循序和隨機工作負載，以確保將計算、儲存體和網路堆疊中的所有元件測試到「邊緣」。 為了使區塊大小和隨機化覆蓋四個角落，因此使用下列常見組合：
- 64 KB 循序測試
- 大型檔案串流工作負載通常會以大型區塊大小進行讀寫，這也是預設的 MSSQL 範圍大小。
- 大型區塊測試通常會產生最高的輸送量 (單位為 MiB/秒)。
- 8 KB 隨機測試
- 此設定是資料庫軟體的常用區塊大小，包括來自 Microsoft、Oracle 和 PostgreSQL 的軟體。
- 小型區塊測試通常會產生最高的 IOPS 數目。
注意
本文僅探討 Azure NetApp Files 的測試。 它未涵蓋隨附於 Azure VMware 解決方案 的 vSAN 記憶體。
環境詳細資料
本文所述結果是以下列環境組態達成：
- Azure VMware 解決方案 主機：
- 大小：AV36
- 主機計數：4
- VMware ESXi 7u3 版
- Azure VMware 解決方案私人雲端連線：具有 FastPath 的 UltraPerformance 網路閘道
- 客體 VM：
- 作業系統：Ubuntu 20.04
- CPU/記憶體：16 個 vCPU/64 GB 記憶體
- Azure VMware 解決方案 vSAN 資料存放區上具有 16 GB OS 磁碟的虛擬 LSI SAS SCSI 控制器
- 用於測試 VMDK 的 Paravirtual SCSI 控制器
- LVM/磁碟組態：
- 每個磁碟一個實體磁碟區
- 每個實體磁碟區一個磁碟區群組
- 每個磁碟區群組一個邏輯分割區
- 每個邏輯分割區一個 XFS 檔案系統
- Azure VMware 解決方案 至 Azure NetApp Files 通訊協定： NFS 第3版
- 工作負載產生器：
fio3.16 版 - Fio 指令碼：
fio-parser
測試結果
本節說明所執行的測試結果。
單一 VM 調整
當您在 Azure VMware 解決方案 虛擬機上設定資料存放區呈現的記憶體時，您應該考慮檔案系統配置的影響。 在多個資料存放區上配置多個 VMDK 可提供最高的可用頻寬。 在單一資料存放區上配置一對多 VMDK 可確保備份和災害復原作業具有最大的便利性，但代價是效能上限較低。 本文中提供的經驗數據可協助您做出相應決策。
為了將效能最大化，通常會在多個 VMDK 上擴展單一 VM，並將這些 VMDK 放在多個資料存放區。 只有一或兩個 VMDK 的單一 VM 可以由一個 NFS 資料存放區進行節流，因為它是透過單一 TCP 連線掛接至指定 Azure VMware 解決方案 主機。
例如，工程師通常會為資料庫記錄佈建 VMDK，然後為資料庫檔案佈建一對多 VMDK。 使用多個 VMDK 時，會有兩個選項。 第一個選項是將每個 VDMK 作為個別的檔案系統。 第二個選項是使用儲存體管理公用程式，例如 LVM、MSSQL 檔案群組或 Oracle ASM，透過在 VMDK 間進行等量分割來平衡 IO。 將 VMDK 作為個別檔案系統時，把工作負載分散到多個資料存放區需以手動方式進行，而且可能十分麻煩。 使用記憶體管理公用程式將檔案分散到 VMDK 中，則能實現工作負載可擴縮性。
如果跨越多個磁碟對磁碟區進行等量分割，請確保備份軟體或災害復原軟體支援同時備份多個虛擬磁碟。 由於個別寫入會跨多個磁碟進行等量分割，因此檔案系統需要確保磁碟在快照集或備份作業期間已然「凍結」。 大多數的新式檔案系統都包含凍結或快照集作業，例如 xfs (xfs_freeze) 和 NTFS (磁碟區陰影複製)，可供備份軟體運用。
若要瞭解隨著新增更多虛擬磁碟而調整單一 Azure VMware 解決方案 VM 的規模，會以一、二、四和八個數據存放區執行測試（每個數據存放區都包含單一 VMDK）。 下圖顯示單一磁碟平均約為 73,040 次 IOPS (從 100% 寫入/0% 讀取調整為 0% 寫入/100% 讀取)。 這項測試增加到兩個磁碟機時，效能會提高 75.8%，達到 128,420 次 IOPS。 增加到四個磁碟機後，單一 VM (按測試大小) 所能推動的 IOPS 開始下降。 所觀察到的尖峰 IOPS 是 147,000 IOPS，隨機讀取量達 100%。
單一主機調整 – 單一資料存放區
隨著從單一主機向單一資料存放區驅動 IO 的 VM 數量增加，其擴縮性也會變差。 這全是因為單一網路流程所造成。 某特定工作負載達到最大效能時，通常是由於在透過單一 TCP 連線到主機的單一 NFS 資料存放區的途中使用單一佇列。 在使用 8KB 區塊大小的情況下，從使用單一 VMDK 的單一 VM 調整到共使用 16 個 VMDK 的四個 VM (每一VM 四個，全部位於單一資料存放區上) 時，總 IOPS 增加了 3% 到 16%。
將大型區塊工作負載的區塊大小增加 (到 64 KB) 則結果相當，峰值達到 2148 MiB/秒 (單一 VM、單一 VMDK) 和 2138 MiB/秒 (4 個 VM、16 個 VMDK)。
單一主機調整 – 多個資料存放區
從單一 Azure VMware 解決方案 主機的內容，而單一數據存放區可讓 VM 驅動約 76,000 IOPS，將工作負載分散到兩個數據存放區，平均輸送量會增加 76%。 從兩個資料存放區增加到四個後，會導致增加163% (與一個資料存放區相比，從兩個增加到四個則多了 49%) ，如下圖所示。 儘管效能仍然有所提升，但增加超過 8 個資料存放區後，回報率會逐漸降低。
多主機調整 – 單一資料存放區
單一主機的單一資料存放區會產生超過 2000 MiB/秒的連續 64 KB 輸送量。 將相同的工作負載分散到所有四台主機上，峰值增益為 135%，驅動速度超過 5000 MiB/秒。 此結果可能代表單一 Azure NetApp Files 磁碟區輸送量效能的上限。
將區塊大小從 64 KB 減少到 8 KB 並重新執行相同的反覆項目，會導致四個 VM 產生 195,000 次 IOPS，如下圖所示。 效能將隨著主機數目和資料存放區數目的增加而擴展，因為網路流程的數量也會增加。 由於網路流程數是主機數乘以資料存放區數的係數，因此可藉由調整主機數目乘以資料存放區數目來增加效能。
多主機調整 – 多個資料存放區
單一資料存放區若使用四個 VM 並分散到四部主機，將產生超過 5000 MiB/秒的循序 64 KB IO。 而對於要求更高的工作負載，會將每個 VM 移至專用資料存放區，總共產生超過 10,500 MiB/秒的速度 (如下圖所示)。
若為小型區塊、隨機的工作負載，單一資料存放區會產生 195,000 次隨機 8 KB IOPS。 擴展到四個資料存放區則可產生超過 530,000 次隨機 8K IOPS。
含意和建議
本節討論為何將 VM 分散到多個資料存放區會帶來顯著的效能優勢。
如測試結果所示，Azure NetApp Files 的效能功用非常強大：
- 測試表明，在四個主機的組態下，一個資料存放區平均可驅動 ~148,980 次 8 KB IOPS 或 ~4147 MiB/秒的 64-KB IOPS (所有寫入 %/讀取 % 測試的平均值)。
- 一個 VM 配一個資料存放區 –
- 如果單一 VM 可能需要超過 ~75K 次 8-KB IOPS 或超越 ~1700 MiB/秒，可將檔案系統分佈在多個 VMDK 上來擴展 VM 的儲存體效能。
- 一個 VM 配多個資料存放區 – 跨 8 個資料存放區的單一 VM 可在 64 KB 區塊大小的情況下實現高達 ~147,000 次 8 KB IOPS 或 ~2786 MiB/秒。
- 一部主機 - 如果每個主機至少使用 4 個 VM 並搭配至少 4 個 Azure NetApp Files 資料存放區，則每個主機平均可支援 ~198,060 次 8 KB IOPS 或 ~2351 MiB/秒。 因此，您可以在配置足量資料存放區以獲得最大效能 (可能是突發效能) 與複雜的管理和成本之間進行平衡。
建議
若單一資料存放區的效能功用不足，可將 VM 分散到多個資料存放區，以進一步調整。 簡單通常是最佳選擇，但效能和延展性或可彌補雖增加但卻有限的複雜性。
四個 Azure NetApp Files 資料存放區可為大型循序 IO 提供高達 10 GBps 的可用頻寬，或驅動高達 500K 次 8K 隨機 IOPS 的能力。 雖然一個資料存放區可能就足以滿足許多效能需求，但為了達到最佳效能，請從至少四個資料存放區開始。
對於精細的效能微調，Windows 和 Linux 客體作業系統都允許跨越多個磁碟進行等量分割。 因此，您應在分散至多個資料存放區上的多個 VMDK 之間對檔案系統進行等量分割。 但如果應用程式快照集一致性是個問題，且無法透過 LVM 或儲存體空間來解決，則可考慮從客體作業系統掛接 Azure NetApp Files，或研究應用程式層級的調整方式，而 Azure 就有很多不錯的選擇。
如果跨越多個磁碟對磁碟區進行等量分割，請確保備份軟體或災害復原軟體支援同時備份多個虛擬磁碟。 由於個別寫入是跨越多個磁碟進行等量分割，檔案系統必須確保磁碟在快照集或備份作業期間已然「凍結」。 大多數的新式檔案系統都包含凍結或快照集作業，例如 xfs (xfs_freeze) 和 NTFS (磁碟區陰影複製)，可供備份軟體運用。
由於 Azure NetApp Files 是按容量集區中佈建的容量計費，而不是按配置的容量 (資料存放區) 計費，因此 4x20TB 資料存放區或 20x4TB 資料存放區兩者會支付相同費用。 如有需要，您可以透過 Azure API/主控台動態地隨需調整資料存放區的容量和效能。
例如，在會計年度即將結束時，您發現到需要提高標準資料存放區的儲存體效能。 您可以將該類資料存放區提高為時一個月的服務等級，使這些資料存放區上的所有 VM 都能獲得更高的效能，同時讓其他資料存放區保持在較低的服務等級。 藉由將工作負載分散到每個 AVS 主機各資料存放區之間更多的 TCP 連線中，您不僅可以節省成本，還能獲得更高的效能。
您可以透過 vCenter Server 或 Azure API/控制台來監視資料存放區計量。 從 vCenter Server，只要在資料存放區上啟用記憶體 IO 控制計量集合，您就可以在效能/進階圖表中監視數據存放區的匯總平均 IOPS。 Azure API 和主控台主要提供 WriteIops、ReadIops、ReadThroughput 和 WriteThroughput 等類計量 ，可在資料存放區層級量測工作負載。 借助 Azure 計量，您可以使用動作來設定警示規則，進而透過 Azure 函式、Webhook 或其他動作來自動調整資料存放區的大小。