共用方式為

檢查清單：Azure VM 上的 SQL Server 最佳作法

  • 發行項

適用於：Azure VM 上的 SQL Server

本文提供一系列最佳做法與指導方針的快速檢查清單，以將 Azure 虛擬機器 (VM) 上 SQL Server 的效能最佳化。

如需完整的詳細資料，請參閱此系列的其他文章：VM 大小、儲存體、安全性、HADR 設定、收集基準。

啟用適用於 Azure VM 上 SQL Server 的 SQL 評定，將會根據 Azure 入口網站之 SQL VM 管理頁面上的已知最佳做法和結果來評估 SQL Server。

如需最佳化 SQL Server VM 效能和自動化管理的最新功能影片，請觀看下列 Data Exposed 影片 (英文)：

概觀

在 Azure 虛擬機器中執行 SQL Server 時，請繼續使用相同的資料庫效能微調選項，這些選項適用於內部部署伺服器環境中的 SQL Server。 不過，公用雲端中關聯式資料庫的效能優劣取決於許多因素，例如虛擬機器的大小和資料磁碟的設定。

通常必須在最佳化成本與最佳化效能之間做出取捨。 此效能最佳做法系列著重於取得 Azure 虛擬機器上 SQL Server 的「最佳」效能。 如果工作負載需求不高，則不一定要遵循每個最佳化建議。 評估以下建議時，請考量您的效能需求、成本和工作負載模式。

手動將 SQL Server 安裝至 Azure VM

如果您打算在 Azure VM 上手動安裝 SQL Server，請考慮下列事項：

  • 請確定您有可供安裝的產品金鑰。
  • 避免 不支持的 組態，例如：
    • 每個 NUMA 節點有超過 64 個虛擬核心。
    • 具有8 KB扇區大小的記憶體。
    • Azure Virtual Machine Scale Sets.
  • 如果它們還不存在，請在啟動安裝媒體之前，先建立 SQL Server 安裝和數據文件的資料夾。
  • 將安裝媒體複製到本機磁碟驅動器，而不是直接從掛接的 ISO 進行安裝。
  • 安裝之後，請使用 SQL Server IaaS 代理程式擴充功能註冊 SQL Server VM，以自動化管理工作。
  • Place the tempdb database on the local SSD ephemeral storage when possible.

VM 大小

本節中的檢查清單涵蓋了適用於 Azure VM 上 SQL Server 的 VM 大小最佳做法。

  • 識別工作負載效能特性，以判斷適合您企業的 VM 大小。
  • 如果您要移轉至 Azure，請使用資料 移轉小幫手 和 SKU 等工具來尋找現有 SQL Server 工作負載的正確 VM 大小，然後使用 Azure Data Studio 進行移轉。
  • Use Azure Marketplace images to deploy your SQL Server VMs as the SQL Server settings and storage options are configured for optimal performance.
  • 使用具有 4 個或更多 vCPU 的 VM 大小。
  • 使用記憶體最佳化的虛擬機器大小，使 SQL Server 工作負載達到最佳效能。
    • Edsv5 系列和 Msv3 和 Mdsv3 系列提供 OLTP 工作負載建議的最佳記憶體對虛擬核心比率。
    • Mbdsv3 系列 VM 為 Azure VM 上的 SQL Server 工作負載提供最佳效能。 針對任務關鍵 OLTP 和數據倉儲 SQL Server 工作負載，請先考慮此系列。
    • Ebdsv5 系列提供高 I/O 輸送量到虛擬核心的比例，以及 8：1 的記憶體與虛擬核心比率。 此系列可為 Azure VM 上的 SQL Server 工作負載提供最佳的效能價格。 針對大部分的 SQL Server 工作負載，請先考慮這些 VM。
    • M 系列系列提供在 Azure 中記憶體配置最高的 VM。
    • Mbsv3 和 Mbdsv3 系列 VM 提供高記憶體配置，以及 M 系列系列中最高的 I/O 輸送量與虛擬核心比率，以及至少 8：1 的一致記憶體與虛擬核心比率。
  • 使用較低層級的 D 系列、B 系列或 Av2 系列開始開發環境，並隨著時間成長您的環境。
  • 請檢查 VM 支援性，以避免不支持的設定。

謹慎

SQL Server isn't supported on VM sizes that deploy with an uninitialized ephemeral disk. 若要深入瞭解，請檢閱 VM 部署和 SQL Server 失敗。

Storage

本節中的檢查清單涵蓋了適用於 Azure VM 上 SQL Server 的儲存體最佳做法。

  • 在選擇磁碟類型之前，請先監控應用程式，並判斷 SQL Server 資料、記錄及 檔案的存放頻寬和延遲需求 。
  • If available, configure the tempdb data and log files on the D: local SSD volume when you deploy a new virtual machine, or after you've installed SQL Server manually. SQL IaaS 代理程式延伸模組會處理重新佈建時所需的資料夾和權限。
  • 若要將儲存效能最佳化，請規劃使用最高可用的未快取 IOPS，並利用資料快取來增強資料讀取效能，同時避免限制虛擬機器和磁碟的效能上限。
  • 使用 Ebdsv5 或 Ebsv5 系列 SQL Server VM 時，使用 進階 SSD v2 以取得最佳價格效能。 您可以使用 Azure 入口網站透過進階 SSD v2 部署 SQL Server VM (目前為預覽狀態)。
  • 如果您的工作負載需要超過 160,000 IOPS，請使用 Premium SSD v2 或 Azure Ultra 磁碟。
  • 將資料、記錄與 tempdb 檔案放在不同的磁碟機上。
    • 針對資料磁碟機，使用進階 P30 和 P40 或較小型磁碟來確保快取支援的可用性。 在使用 Ebdsv5 VM 系列時，使用進階 SSD v2，它為需要高 IOPS 和 I/O 輸送量的工作負載提供更好的價格效能。
    • For the log drive plan for capacity and test performance versus cost while evaluating either Premium SSD v2 or Premium SSD P30 - P80 disks
    • Place tempdb on the temporary disk (the temporary disk is ephemeral, and defaults to D:\) for most SQL Server workloads that aren't part of a failover cluster instance (FCI) after choosing the optimal VM size.
      • 如果對 tempdb 來說，本機磁碟機的容量不足，請考慮調整 VM 的大小。 如需詳細資訊，請參閱資料檔案快取原則。
    • For failover cluster instances (FCI) place tempdb on the shared storage.
      • 如果 FCI 工作負載嚴重相依於 tempdb 磁碟效能，則以進階設定的方式將 tempdb 放在本機暫時 SSD (預設 D:\) 磁碟機，此磁碟機並非 FCI 儲存體的一部分。 這項設定需要客製化監控和行動，以確保本機暫存 SSD（預設 D:\）磁碟機處於隨時可用狀態，因為此磁碟機的任何故障都不會觸發 FCI 採取行動。
  • 使用儲存空間來分割多個 Azure 資料磁碟，以將 I/O 頻寬增加高達目標虛擬機器的 IOPS 和輸送量限制。
  • 將資料檔案磁碟的主機快取設定為唯讀。
  • 將記錄檔磁碟的主機快取設定為 [無]。
    • 請勿在包含 SQL Server 資料或記錄檔的磁碟上啟用讀取/寫入快取。
    • 在變更磁碟的快取設定之前，請一律停止 SQL Server 服務。
  • 將數個不同的工作負載移轉至雲端時，Azure 彈性 SAN 可以成為符合成本效益的合併儲存體解決方案。 不過，使用 Azure 彈性 SAN 時，達到 SQL Server 工作負載所需的 IOPS/輸送量通常需要超額佈建容量。 雖然通常不適合單一 SQL Server 工作負載，但將低效能工作負載與 SQL Server 結合時，您可以取得符合成本效益的解決方案。
  • 請考慮使用標準儲存體處理開發和測試工作負載，以及長期備份封存。 不建議使用標準 HDD/SSD 進行生產工作負載。
  • Credit-based Disk Bursting (P1-P20) should only be considered for smaller dev/test workloads and departmental systems.
  • 若要將儲存效能最佳化，請規劃可用的最高未快取 IOPS，並將資料快取用作資料讀取的效能增強功能，同時避免限制/調節虛擬機器和磁碟的性能。
  • 將您的資料磁碟格式化，以針對位於暫存 D:\ 磁碟機以外之磁碟機上的所有資料檔案使用 64 KB 的配置單位大小 (預設值為 4 KB)。 SQL Server VMs deployed through Azure Marketplace come with data disks formatted with allocation unit size and interleave for the storage pool set to 64 KB.
  • 在與 SQL Server VM 相同的區域中設定儲存體帳戶。
  • 停用 Azure 異地備援儲存體 (異地複寫) 並在儲存體帳戶上使用 LRS (本地備援儲存體)。
  • 啟用 SQL 最佳做法評估，以識別可能的效能問題，並評估您的 SQL Server VM 是否已設定為遵循最佳做法。
  • 使用儲存體 IO 使用率計量來檢閱和監視磁碟和 VM 限制。
  • 從防毒軟體掃描中排除 SQL Server 檔案，包括資料檔案、記錄檔和備份檔案。

安全性

本節中的檢查清單涵蓋了適用於 Azure VM 上 SQL Server 的安全性最佳做法。

SQL Server 特徵和功能提供在資料庫層級保護數據的方法，這些方法可與基礎結構層級的安全性功能結合。 這些功能一起為雲端式和混合式解決方案的基礎結構層級提供 深度 防禦。 此外，透過 Azure 安全性措施，您可以加密敏感性資料、保護虛擬機器免於病毒和惡意程式碼的威脅、保護網路流量、識別和偵測威脅、符合合規性需求，並提供單一方法來管理及報告混合式雲端中的任何安全性需求。

  • 使用適用於雲端的 Microsoft Defender 來評估和採取動作，以改善您資料環境的安全性態勢。 Azure 進階威脅防護 (ATP) 等功能可以跨混合式工作負載使用，以改善安全性評估，並讓您能夠回應風險。 Registering your SQL Server VM with the SQL IaaS Agent extension surfaces Microsoft Defender for Cloud assessments within the SQL virtual machine resource of the Azure portal.
  • 利用適用於 SQL 的 Microsoft Defender 來探索及減輕潛在資料庫弱點，以及偵測可能對 SQL Server 執行個體和資料庫層造成威脅的異常活動。
  • 弱點評定是適用於 SQL 的 Microsoft Defender 的一部分，可探索並協助補救您 SQL Server 環境的潛在風險。 它可讓您查看安全性狀態，並包含解決安全性問題的可行步驟。
  • 使用 Azure 機密 VM 來強化對待用資料的保護，並防止主機操作員存取待用資料。 Azure 機密 VM 可讓您放心地將敏感性資料儲存在雲端，並符合嚴格的合規性需求。
  • 如果您使用的是 SQL Server 2022，請考慮使用 Microsoft Entra 驗證來連線到 SQL Server 執行個體。
  • Azure Advisor 會分析您的資源設定和使用量遙測，然後建議可協助您改善 Azure 資源成本效益、效能、高可用性和安全性的解決方案。 在虛擬機器、資源群組或訂閱層級使用 Azure Advisor 來協助識別並套用最佳做法，以最佳化您的 Azure 部署。
  • 當您的合規性與安全性需求要求您使用加密金鑰來進行端對端資料加密 (包括加密暫時性磁碟 (本機連結的暫存磁碟)) 時，請使用 Azure 磁碟加密。
  • 預設使用 Azure 儲存體服務加密將受控磁碟在靜止狀態下加密，加密金鑰由 Microsoft 管理，儲存在 Azure。
  • 如需受控磁碟加密選項的比較，請檢閱受控磁碟加密比較圖表
  • 您應該在虛擬機器上關閉管理連接埠 - 開啟遠端管理連接埠會使您的 VM 暴露在網際網路型攻擊的高風險層級之下。 這些攻擊會嘗試對憑證發動暴力破解，來取得機器的系統管理員存取權。
  • 開啟 Azure 虛擬機器的 Just-In-Time (JIT) 存取
  • 透過遠端桌面通訊協定 (RDP) 使用 Azure Bastion。
  • 使用 Azure 防火牆來鎖定連接埠並僅允許必要的應用程式流量，這是一項受控防火牆即服務 (FaaS)，可根據原始 IP 位址授與/拒絕伺服器存取。
  • 使用網路安全性群組 (NSG) 來篩選 Azure 虛擬網路中的 Azure 資源往返流量
  • 使用應用程式安全性群組，將具有類似連接埠篩選需求及類似功能的伺服器分組在一起，例如網頁伺服器和資料庫伺服器。
  • 針對網頁伺服器和應用程式伺服器，請使用 Azure 分散式阻斷服務 (DDoS) 保護。 DDoS 攻擊旨在耗盡網路資源，讓應用程式變慢或沒有回應。 DDos 攻擊通常會以使用者介面為目標。 Azure DDoS 保護會在不必要的網路流量影響服務可用性之前先予以清理
  • 利用 VM 擴充功能可協助解決反惡意程式碼、預期狀態、威脅偵測、預防及補救，以解決作業系統、電腦和網路層級的威脅：
  • 利用 Azure 原則來建立可套用至您環境的商務規則。 Azure 原則會根據 JSON 格式中定義的規則比較這些資源的屬性，以評估 Azure 資源。
  • Azure 藍圖可讓雲端架構設計師和中央資訊技術人員定義一組可重複使用的 Azure 資源，其中實作並遵循組織的標準、模式和需求。 Azure 藍圖與 Azure 原則不同。
  • 使用 Windows Server 2019 或 Windows Server 2022 使 Azure VM 上的 SQL Server 符合 FIPS 規範。

SQL Server 功能

The following is a quick checklist of best practices for SQL Server configuration settings when running your SQL Server instances in an Azure virtual machine in production:

Azure 功能

The following is a quick checklist of best practices for Azure-specific guidance when running your SQL Server on Azure VM:

HADR 設定

本節中的檢查清單涵蓋了適用於 Azure VM 上 SQL Server 的 HADR 最佳做法。

高可用性和災害復原 (HADR) 功能，例如 Always On 可用性群組，而容錯移轉叢集執行個體會依賴基礎 Windows Server 容錯移轉叢集技術。 請檢閱修改 HADR 設定的最佳做法，以更妥善地支援雲端環境。

針對您的 Windows 叢集，請考慮下列最佳做法：

  • 盡可能將 SQL Server VM 部署至多個子網路，以避免依賴 Azure Load Balancer 或分散式網路名稱 (DNN)，將流量路由傳送至 HADR 解決方案。
  • 將叢集變更為較不積極的參數，以避免因為暫時性網路失敗或 Azure 平台維修而發生非預期的中斷。 若要深入了解，請參閱心跳和閾值設定。 針對 Windows Server 2012 和更新版本，請使用下列建議值：
    • SameSubnetDelay：1 秒
    • SameSubnetThreshold: 40 heartbeats
    • CrossSubnetDelay：1 秒
    • CrossSubnetThreshold: 40 heartbeats
  • 將您的 VM 放置在可用性設定組或不同的可用性區域中。 若要深入了解，請參閱 VM 可用性設定。
  • 每個叢集節點都會使用單一 NIC。
  • Configure cluster quorum voting to use 3 or more odd number of votes. 請不要將投票指派給災害復原區域。
  • 請仔細監視資源限制，以避免由於資源限制而造成非預期的重新啟動或容錯移轉。
    • 確定您的作業系統、驅動程式和 SQL Server 都是最新組建。
    • 針對 Azure VM 上的 SQL Server 最佳化效能。 若要深入了解，請檢閱本文中的其他小節。
    • 減少或分散工作負載，以避免資源限制。
    • 移至限制較高的 VM 或磁碟，以避免侷限。

針對 SQL Server 高可用性群組或容錯移轉叢集執行個體，請考慮下列最佳做法：

  • 如果您經常遇到非預期的失敗，則請遵循本文其餘部分所述的效能最佳做法。
  • If optimizing SQL Server VM performance doesn't resolve your unexpected failovers, consider relaxing the monitoring for the availability group or failover cluster instance. 不過，這麼做可能無法解決問題的基礎來源，而且可能會透過降低失敗的可能性來掩蓋徵兆。 您可能還是需要調查並解決基礎根本原因。 針對 Windows Server 2012 或更高版本，請使用下列建議值：
    • 租用逾時：使用此方程式來計算租用逾時最大值：
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      從 40 秒開始。 如果您要使用先前建議的寬鬆 SameSubnetThreshold 和 SameSubnetDelay 值，則請不要超過 80 秒的租用逾時值。
    • 指定期間內的失敗次數上限：將此值設定為 6。
  • 使用虛擬網路名稱 (VNN) 和 Azure Load Balancer 連線至您的 HADR 解決方案時，請在連接字串中指定 MultiSubnetFailover = true，即使您的叢集只橫跨一個子網路也是一樣。
    • 如果用戶端不支援 MultiSubnetFailover = True，則您可能需要設定 RegisterAllProvidersIP = 0 和 HostRecordTTL = 300，以在較短的時間內快取用戶端認證。 不過，這麼做可能會對 DNS 伺服器造成額外的查詢。
  • 若要使用分散式網路名稱 (DNN) 連線至 HADR 解決方案，請考慮下列事項：
    • 您必須使用支援 MultiSubnetFailover = True 的用戶端驅動程式，且此參數必須在連接字串中。
    • 連線至可用性群組的 DNN 接聽程式時，請在連接字串中使用唯一的 DNN 連接埠。
  • 針對基本可用性群組使用資料庫鏡像連接字串，以略過負載平衡器或 DNN 的需求。
  • 在部署高可用性解決方案之前，請先驗證 VHD 的磁區大小，以避免發生不一致的 I/O。 若要深入了解，請參閱 KB3009974。
  • 如果 SQL Server 資料庫引擎、Always On 可用性群組接聽程式或容錯移轉叢集執行個體健康情況探查設定為使用 49,152 與 65,536 之間的連接埠 (TCP/IP 的預設動態連接埠範圍)，則請新增每個連接埠的排除。 這樣做將讓其他系統無法動態指派相同的連接埠。 下列範例針對連接埠 59999 設置排除：
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

效能疑難排解

以下是可協助您進一步對 SQL Server 效能問題進行疑難排解的資源清單。

相關內容

考慮為 Azure VM 上的 SQL Server 啟用 SQL 評定。

請檢閱 Azure 虛擬機器上的 SQL Server 概觀中其他「SQL Server 虛擬機器」的相關文章。 如果您有 SQL Server 虛擬機器的相關問題，請參閱常見問題集。