Dell Compellent的一些缺陷

最近學習Dell Compellent系列存儲，做了一些筆記。
總體來說這個是一個企業存儲，適合各種應用場景，不過，通過網上查一些資料，發現該系列存儲白壁微瑕，總結下來主要在以下幾個方面：
RAID Scrub（RAID糾錯）
數據寫入到磁盤過程中，或者存儲在磁盤后有可能發生畸變。所以，所有的存儲都會運行后臺進程進行數據糾錯。這就是RAID Scrub機制：控制器定期讀磁盤數據塊，利用檢校數據檢查磁盤數據塊的正確性，如果發現數據塊錯誤，存儲將自動進行糾正。進行糾錯的過程中，磁盤的讀的IO將非常高。而Dell Compellent的RAID Scrub后臺進程的運行優先級高于業務端，也就是說，無論業務多繁忙，都需要優先進行RAID Scrub。很多時候，業務IO請求和RAID Scrub進程會有沖突，這個時候業務IO的延時就會很大。而且，Dell Compellent的RAID Scrub進程的運行時間用戶無法干預，這個是Dell Compellent性能表現不佳的重要原因。
數據分層（Data Progression）
數據分層是一個很好的提高性能的機制，但是Dell Compellent的數據分層也存在一個重要缺陷。啟用按需（on-demand）分層策略后，當HDD的某些數據被主機大量訪問，這些數據就會變成熱點數據，熱點數據塊會被遷移到SSD，但是遷移過程中，主機端也在等待這些數據的訪問結果，由于分層遷移的優先級高于業務端訪問，主機端的訪問只能等待遷移結束。
多路徑機制
存儲前端控制器多路徑機制在一定程度上決定存儲的讀寫性能和可靠性，現有的前端控制器多路徑機制大致可分為A/A-S(Active/Acivie-Symmetric)、ALUA和A/P(Active/Passive)三大類。
A/A-S(Active/Acivie-Symmetric)機制，對于特定的LUN來說，在它的路徑中，多個存儲控制器的目標端口均處于主動/優化(Active/optimized)狀態。多個控制器之間通過PCIe或Infiniband等實現高速互聯的通訊，從主機側發送一個IO到控制器端后，多個控制器可同時參與IO處理；存儲系統會自動負載均衡，當一個控制器繁忙或業務壓力較大時，存儲系統不需要主機端多路徑負載均衡軟件參與就可以自動實現負載均衡。這種機制在高端存儲中較多使用。
對于ALUA(Active/Active-Asymmetric)機制來說，特定的LUN在控制器的路徑組中，只有一個控制器的目標端口組處于主動/優化(Active/Optimized)狀態，其他控制器的目標端口組處于主動/非優化(Active/Unoptimized)狀態。某個時刻一個特定LUN只屬于某一個優選控制器，在多路徑的配合下，IO從優選控制的IO組(Active/Optimized)下發IO，多路徑不會發送該LUN的IO到其他控制器，一般通過將LUN A歸屬控制器A，將LUNB歸屬給控制器B實現兩邊的負載均衡，歸屬操作可以手動或自動完成。這種機制在中高端存儲中使用。
還有一種是A/P(Active/Passive)機制，一般只用在低端雙活存儲陣列中。現在這種架構已經很少見了。對于特定的LUN來說，在對應存儲的路徑中只有一個控制器的目標端口處于主動/優化(Active/Optimized)狀態，其他控制器的目標端口處于備用或平時不工作狀態，其負載均衡處理方式與ALUA類似(即根據優選控制器來決定)，但是由于多路徑和存儲互不相識(多路徑不知道那些路徑是優選路徑)，IO很難選到合適的路徑，IO的下發可以說這完全取決于上層多路徑的心情，解決方案是提供自研多路徑來配合陣列選路，通過私有協議實現IO到優選路徑的匹配。而Dell的Compellent就是使用該種機制，這也就帶來了性能的問題。在一個4條路徑的物理環境中，能夠發現LUN的路徑只有2條。
如果有一種情況：Compellent存儲上的所有主機端口故障，但是控制器還繼續工作，那么這個時候，屬于該控制器的LUN將全部不能訪問。因為這時候控制器正常，存儲不會將LUN切換到另外的控制器。同時因為不支持ALUA機制，主機端也不能通過另外的控制器訪問這些LUN。有個簡單的辦法就可以測試這種狀況，就是把Compellent一個控制器上的主機端口線纜全部拔出。這個時候就有部分LUN不能訪問。雖然這種情況比較少見，但是還是可能發生。

以上部分是通過網上查資料總結，本人沒有條件論證，所以發布到網上，如果有不準確的請指正。