使用 SQL Server 的多個 PVSCSI
關於 SQL Server 虛擬化，一直在嘗試查找資訊是否對將數據設備與日誌設備分離到不同的準虛擬 SCSI (PVSCSI) 適配器有積極的性能影響，類似於此處所做的。
在客戶端上存在這樣一種情況，即添加了一個額外的 PVSCSI，並將日誌設備分離到新的 PVSCSI，從而顯示出可觀的性能提升。然而，仍然存在疑問，是由於這種分離還是僅僅由於現在存在額外的 PVSCSI。
眾所周知，日誌磁碟通常是按順序寫入的，而數據磁碟的讀/寫則遵循更隨機的模式，將這兩種不同類型的文件放在不同的磁碟上會帶來性能優勢。
但是控制器呢？將這些不同的模式保存在單獨的 PVSCSI 控制器中是否也有好處？
有人對此有任何見解嗎？
提前致謝
我將分兩部分回答：首先“為什麼關於分離順序和隨機的傳統答案通常不適用。”
然後我將討論在 Windows 物理磁碟上分離文件的潛在好處，以及添加額外的 vHBA 並在它們之間分配物理磁碟。
期望在 Windows 物理磁碟級別分離隨機和順序磁碟 IO 的好處通常假設 HDD 設備用於數據儲存。它通常還假設單獨的 Windows 物理磁碟意味著單獨的 HDD 設備。這個想法是，一些 HDD 組主要處理順序磁碟 IO，並且磁碟磁頭移動非常有限（例如，承載單個繁忙 txlog* 的 HDD），而一組單獨的 HDD 處理隨機磁碟 IO。
這些假設在今天很少成立——尤其是在虛擬機中。首先，除非 VM 的 Windows 物理磁碟是 RDM，否則其中的多個可能位於單個數據儲存中 - 或者多個數據儲存可能位於單個 ESXi 主機 LUN 上。因此，來賓中分離的內容可以在 ESXi 主機級別混合。
但是，假設使用了 RDM，或者每個客戶物理磁碟都在自己的數據儲存上，在自己的 ESXi LUN 上。即使這樣，來賓中單獨的順序和隨機 io 也經常在陣列中混合，因為提供給 ESXi 主機的 LUN 可能來自同一個磁碟設備池。現在幾乎每個儲存陣列都這樣做 - 要麼是專門的，要麼是作為簡化管理和提高陣列效率/資源使用率的選項。
最後，今天如此多的儲存要麼是全快閃記憶體，要麼是混合快閃記憶體+HDD。無需擔心頭部移動，flash 不關心隨機順序的分離……甚至不關心 IO 編織。
所以……這些都是將順序與隨機分開的原因可能並不是那麼有益。接下來，為什麼在物理磁碟之間傳播文件和在 vHBA 之間傳播物理磁碟仍然可以提高性能。
*我在此 HDD 範例中特意提到了單個事務日誌。當幾個單獨的順序磁碟 IO 流（例如 8 個繁忙的事務日誌）發生在同一個 HDD 上時——除非幾乎所有活動都在 SAN 記憶體中——順序 IO 軌道之間的持續磁頭移動會導致 IO 編織。這是一種特定類型的磁碟磁頭抖動，會導致“比隨機更糟糕”的磁碟延遲。發生在 RAID5 和 RAID10 上，儘管 RAID10 在這方面只能容忍比 RAID5 在顯著退化之前稍微多一點的變化。
現在 - 考慮到關於如何將順序與隨機分開可能無濟於事的冗長討論 - 如何在物理磁碟上傳播文件仍然有幫助？在 vHBA 之間傳播物理磁碟有何幫助？
這都是關於磁碟 IO 隊列的。
在 perfmon 報告的“目前磁碟隊列”中，任何 Windows 物理磁碟或邏輯磁碟一次最多可以有 255 個未完成的磁碟 IO。從物理磁碟隊列中未完成的磁碟 IO 中，storport 最多可以將 254 個傳遞給微型驅動程序。但微型驅動程序也可能同時具有服務隊列（向下傳遞到下一個較低級別）和等待隊列。可以告訴 storport 將其傳遞的數字從 254 降低。
在 VMware Windows 客戶機中，pvscsi 驅動程序的預設“設備”隊列深度為 64，其中設備是物理磁碟。因此，儘管 perfmon 可以在單個物理磁碟的“目前磁碟隊列長度”中顯示多達 255 個磁碟 IO，但一次最多只能將其中的 64 個傳遞到下一個級別（除非更改預設值）。
有多少磁碟 IO 可以未完成一次繁忙的事務日誌？好吧，事務日誌寫入的大小可以達到 60kb。在大規模 ETL 期間，我經常會看到每次寫入 txlog 的大小為 60kb。txlog 寫入器一次最多可以有 32 個 60kb 的未完成寫入到一個 txlog。那麼，如果我在同一個物理磁碟上使用預設的 VMware 設置有一個繁忙的暫存 txlog 和一個繁忙的 dw txlog 怎麼辦？如果兩個 txlog 都達到最大 32 個未完成的 60kb 寫入，則該物理磁碟的隊列深度為 64。現在……如果物理磁碟上還有平面文件作為 ETL 源怎麼辦？嗯……在讀取平面文件和寫入 txlog 之間，他們必須使用等待隊列，因為一次只能輸出 64 個。對於具有繁忙 txlog 的數據庫，無論是物理伺服器還是虛擬伺服器，我建議將 txlog 放在其自己的物理磁碟上，物理磁碟上沒有其他內容。這可以防止在該級別排隊，並且還消除了對多個文件交錯內容的任何擔憂（如今這是一個非常非常少的問題）。
一次可以有多少磁碟 IO 未完成到行文件（從 SQL Server 的角度來看，不一定要送出到較低級別）？SQL Server 本身並沒有真正的限制（無論如何我已經找到了）。但是假設文件位於單個 Windows 物理磁碟上（我不建議為 SQL Server 使用條帶化動態磁碟，這是另一個話題），這是有限制的。這是我之前提到的255。
憑藉 SQL Server 預讀和非同步 IO 的魔力，我看到 4 個並發查詢，每個查詢都在串列驅動器中執行，總“目前磁碟隊列長度”超過 1200！由於 255 的限制，這甚至不可能將所有行文件內容都放在一個物理磁碟上。它針對一個有 8 個文件的主文件組，每個文件都在自己的物理磁碟上。
所以預讀可能非常激進，並且會給 IO 隊列帶來壓力。它們可能非常激進，以至於其他行文件讀取和寫入最終都在等待。如果事務日誌與行文件位於同一物理磁碟上，則在同時預讀讀取和 txlog 寫入期間，很容易等待發生。即使該等待不在“目前磁碟隊列長度”級別，它也可能在設備隊列中等待（pvscsi 預設為 64）。
對行文件的備份讀取也可能非常激進，尤其是在調整緩衝區計數以最大化備份吞吐量的情況下。
在考慮隔離 txlog 時，還需要注意另一種 SQL Server io 類型：查詢溢出到 tempdb。當查詢溢出發生時，每個溢出的工作寫入 tempdb。有很多並行工作人員同時溢出？這可能是一個相當大的寫入負載。讓繁忙的 txlog 和重要的行文件遠離它真的很有幫助:-)
現在，可以更改 pvscsi 驅動程序的預設設備隊列深度。它預設為 64，並且可以設置為 254，這是 storport 將傳遞的最高值。但要小心改變這一點。我始終建議將客戶機設備隊列深度與底層 ESXi 主機 LUN 隊列深度對齊。並設置每個陣列最佳實踐的 ESXi 主機 LUN 隊列深度。使用 EMC VNX？主機 LUN 隊列深度應為 32。來賓使用 RDM？偉大的。將客戶機 pvscsi 設備隊列深度設置為 32，使其與 ESXi 主機 LUN 隊列深度對齊。EMC VMAX？通常在 ESXi 主機級別為 64，在客戶機中為 64。Pure/Xtremio/IBM FlashSystem？有時主機 LUN 隊列深度會設置為高達 256！然後將 pvscsi 設備隊列深度設置為 254（最大可能）。
這是一個帶有說明的連結。 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
該連結還談到 requestringpages - WhatAreThose?? 它們確定 pvscsi 適配器本身的隊列深度。每個頁面在適配器隊列深度中提供 32 個插槽。預設情況下，對於 256 的適配器隊列深度，requestringpages 為 8。對於 1024 個適配器隊列深度插槽，它可以設置為高達 32。
假設一切都是預設的。我有 8 個物理磁碟，上面有行文件，SQL Server 有點忙。8 個中平均有 32 個“目前磁碟隊列長度”，沒有一個高於 64（所有內容都適合各種設備服務隊列）。太棒了 - 這給了 256 OIO。它適合設備服務隊列，適合適配器服務隊列，因此所有 256 個都可以從來賓進入 ESX 主機級別的隊列。
但是……如果事情變得有點忙，那麼平均為 64 個，其中一些物理磁碟的隊列高達 128 個。對於那些有超過 64 個未完成的設備，超額處於等待隊列中。如果超過 256 個在 8 個物理磁碟上的設備服務隊列中，則在等待隊列中出現超額，直到適配器服務隊列中的插槽打開。
在這種情況下，添加另一個 pvscsi vHBA 並在它們之間分佈物理磁碟會使適配器隊列的總深度翻倍，達到 512。更多的 io 可以同時從客戶機傳遞到主機。
通過保持一個 pvscsi 適配器並增加 requestringpages 可以實現類似的效果。去 16 會產生 512 個插槽，而 32 會產生 1024 個插槽。
如果可能，我建議在深入（增加適配器隊列深度）之前先擴展（添加適配器）。但是……在許多最繁忙的系統上，必須同時做到：在客戶機上放置 4 個 vHBA，並將 requestringpages 增加到 32。
還有很多其他的考慮。諸如 sioc 和自適應隊列深度限制（如果使用 vmdks）、多路徑配置、超出 LUN 隊列深度的 ESXi 適配器配置等。
但我不想過分歡迎:-)
朗尼·尼德施塔特@sqL_handLe