天天看點

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不能通路。雖然這種情況比較少見,但是還是可能發生。

以上部分是通過網上查資料總結,本人沒有條件論證,是以釋出到網上,如果有不準确的請指正。

本文轉自 川流資訊 51CTO部落格,原文連結:http://blog.51cto.com/tech4fei/2044898