Skip to main content
NetApp database solutions
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

需要考慮的因素

貢獻者 kevin-hoke
PDF

本節介紹在雲端使用Azure NetApp Files和 SQL Server 時應考慮的不同問題。

虛擬機器效能

選擇正確的虛擬機器大小對於公有雲中關聯式資料庫的最佳效能非常重要。 Microsoft 建議您繼續使用適用於本機伺服器環境中的 SQL Server 的相同資料庫效能調整選項。使用 "記憶體優化"適合 SQL Server 工作負載最佳效能的 VM 大小。收集現有部署的效能數據，以便在選擇正確的執行個體時識別 RAM 和 CPU 使用率。大多數部署在 D、E 或 M 系列之間進行選擇。

筆記：

  • 為了獲得 SQL Server 工作負載的最佳效能，請使用記憶體最佳化的 VM 大小。

  • NetApp和 Microsoft 建議您在選擇具有適當記憶體與 vCore 比率的執行個體類型之前確定儲存效能需求。這也有助於選擇具有適當網路頻寬的較低實例類型，以克服虛擬機器的儲存吞吐量限制。

虛擬機器冗餘

為了提高冗餘度和高可用性，SQL Server VM 應該位於同一 "可用性集"或不同 "可用區域"。建立 Azure VM 時，您必須在設定可用性集和可用性區域之間進行選擇；Azure VM 不能同時參與兩者。

高可用性

為了實現高可用性，配置 SQL Server AOAG 或 Always On 故障轉移群集實例 (FCI) 是最佳選擇。對於 AOAG，這涉及虛擬網路中 Azure 虛擬機器上的多個 SQL Server 執行個體。如果資料庫層級需要高可用性，請考慮設定 SQL Server 可用性群組。

儲存配置

可以使用 SMB 檔案共用作為儲存選項進行部署。從 SQL Server 2012 開始，系統資料庫（master、model、msdb 或 tempdb）和使用者資料庫可以與伺服器訊息區塊 (SMB) 檔案伺服器一起安裝作為儲存選項。這適用於 SQL Server 獨立版和 SQL Server FCI。

註 SQL Server 資料庫的檔案共用儲存應支援持續可用屬性。這提供了對文件共享資料的不間斷存取。

Azure NetApp Files提供高效能檔案儲存以滿足任何嚴苛的工作負載，並且與區塊儲存解決方案相比，它降低了 SQL Server TCO。使用區塊存儲，虛擬機器對磁碟操作的 I/O 和頻寬施加了限制；僅對Azure NetApp Files應用網路頻寬限制。換句話說， Azure NetApp Files不適用任何 VM 級 I/O 限制。沒有這些 I/O 限制，在連接到Azure NetApp Files的較小 VM 上執行的 SQL Server 的效能可以與在更大的 VM 上執行的 SQL Server 一樣好。 Azure NetApp Files透過降低運算和軟體授權成本來降低 SQL Server 部署成本。有關使用Azure NetApp Files進行 SQL Server 部署的詳細成本分析和效能優勢，請參閱 "使用Azure NetApp Files進行 SQL Server 部署的優勢"。

好處

使用Azure NetApp Files for SQL Server 的優點包括：

  • 使用Azure NetApp Files允許您使用更小的實例，從而降低計算成本。

  • Azure NetApp Files也降低了軟體授權成本，從而降低了整體 TCO。

  • 磁碟區重塑和動態服務等級功能透過調整穩定狀態工作負載的大小並避免過度配置來優化成本。

筆記：

  • 為了提高冗餘度和高可用性，SQL Server VM 應該位於同一 "可用性集"或以不同的方式 "可用區域"。如果需要使用者定義的資料文件，請考慮文件路徑需求；在這種情況下，選擇 SQL FCI 而不是 SQL AOAG。

  • 支援以下 UNC 路徑： "\\ANFSMB-b4ca.anf.test\SQLDB 和 \\ANFSMB-b4ca.anf.test\SQLDB\" 。

  • 不支援環回 UNC 路徑。

  • 對於大小調整，請使用來自本地環境的歷史資料。對於 OLTP 工作負載，使用平均時間和峰值時間的工作負載以及磁碟讀取/秒和磁碟寫入/秒效能計數器將目標 IOPS 與效能要求進行匹配。對於資料倉儲和報告工作負載，使用平均時間和峰值時間的工作負載以及磁碟讀取位元組數/秒和磁碟寫入位元組數/秒來匹配目標吞吐量。平均值可以與體積重塑功能結合使用。

建立持續可用的共享

使用 Azure 入口網站或 Azure CLI 建立持續可用的共用。在入口網站中，選擇「啟用連續可用性」屬性選項。對於 Azure CLI，使用 az netappfiles volume create with the smb-continuously-avl`選項設定為 `$True。要了解有關創建新的、支援持續可用性的捲的更多信息，請參閱 "建立持續可用的共享"。

筆記：

  • 為 SMB 磁碟區啟用持續可用性，如下圖所示。

  • 如果使用非管理員網域帳戶，請確保帳戶已指派所需的安全權限。

  • 在共用層級設定適當的權限並設定適當的檔案等級權限。

  • 無法在現有的 SMB 磁碟區上啟用持續可用屬性。若要將現有磁碟區轉換為使用持續可用的共用，請使用NetApp Snapshot 技術。有關更多信息，請參閱"將現有 SMB 磁碟區轉換為使用連續可用性" 。

此圖顯示輸入/輸出對話框或表示書面內容

表現

Azure NetApp Files支援三種服務等級：標準等級（每 TB 16MBps）、進階（每 TB 64MBps）和超級等級（每 TB 128MBps）。配置正確的磁碟區大小對於資料庫工作負載的最佳效能非常重要。使用Azure NetApp Files，磁碟區效能和吞吐量限制基於以下因素的組合：

  • 卷所屬容量池的服務級別

  • 分配給卷的配額

  • 容量池的服務品質 (QoS) 類型（自動或手動）

有關更多信息，請參閱 "Azure NetApp Files的服務級別" 。

此圖顯示輸入/輸出對話框或表示書面內容

性能驗證

與任何部署一樣，測試虛擬機器和儲存至關重要。對於儲存驗證，應該使用諸如 HammerDB、Apploader 或任何具有適當讀取/寫入組合的自訂腳本或 FIO 等工具。但請記住，大多數 SQL Server 工作負載（即使是繁忙的 OLTP 工作負載）也接近 80%–90% 的讀取和 10%–20% 的寫入。

為了展示效能，對使用高級服務等級的捲進行了快速測試。在此測試中，磁碟區大小從 100GB 動態增加到 2TB，而應用程式存取沒有任何中斷，且沒有資料遷移。

此圖顯示輸入/輸出對話框或表示書面內容

這是使用 HammerDB 對本文所述部署進行即時效能測試的另一個範例。在本次測試中，我們使用了一個具有 8 個 vCPU、500GB Premium SSD 和 500GB SMB Azure NetApp Files區的小型執行個體。 HammerDB 設定了 80 個倉庫和 8 個使用者。

下圖顯示，當使用同等大小的磁碟區（500GB）時， Azure NetApp Files每分鐘能夠提供 2.6 倍的交易數量，同時延遲降低 4 倍。

透過調整為具有 32x vCPU 和 16TB Azure NetApp Files磁碟區的更大實例，執行了額外的測試。每分鐘交易量顯著增加，且延遲始終保持在 1ms。 HammerDB 本次測試配置了 80 個倉庫和 64 個使用者。

此圖顯示輸入/輸出對話框或表示書面內容

成本最佳化

Azure NetApp Files允許無中斷、透明地調整磁碟區大小，並且能夠在零停機時間和不影響應用程式的情況下變更服務等級。這是一項獨特的功能，允許動態成本管理，避免使用峰值指標執行資料庫大小調整。相反，您可以使用穩定狀態工作負載，從而避免前期成本。透過磁碟區重塑和動態服務級別更改，您可以幾乎即時地按需調整Azure NetApp Files磁碟區的頻寬和服務級別，而無需暫停 I/O，同時保留資料存取。

可以使用 LogicApp 或 Functions 等 Azure PaaS 產品根據特定的 webhook 或警報規則觸發器輕鬆調整磁碟區大小，以滿足工作負載需求，同時動態處理成本。

例如，假設一個資料庫需要 250MBps 才能實現穩定狀態運作；但是，它還需要 400MBps 的峰值吞吐量。在這種情況下，應使用 Premium 服務等級內的 4TB 磁碟區進行部署，以滿足穩定狀態的效能要求。為了處理峰值工作負載，請在特定時間段內使用 Azure 函數將磁碟區大小增加到 7TB，然後縮小磁碟區大小以使部署更具成本效益。此配置避免了儲存的過度配置。