DoSTOR存儲分析 如何解決存儲系統的“熱點”問題

導讀：在存儲架構中，一個"熱點"并不是就如同它字面上的意思。實際上，很大程度上恰恰相反：它是指磁盤系統中非?；钴S的一部分，其特征是冗長的輸入/輸出請求等待時間，以及相應的數據等待時間。存儲架構中的熱點是不受歡迎的，而存儲架構工程師和管理者非常努力研究如何減少熱點的數量并削弱它們的影響。

關鍵詞：RAID 磁盤 延遲時間 SCSI FC

DoSTOR存儲分析 11月5日國際報道：熱點對于大部分應用來說都是一個麻煩。一個應用在多個設備之間發出請求，就必須受到物理上的輸入/輸出請求的限制。如果請求的延遲時間很長，而且數據索引的延遲時間也很長，那么應用程序的反應時間取決于SQL所建請求的最大延遲時間。結果當然是性能大大下降。

那么如何才能夠對付這些討厭的熱點呢？當然，幾乎所有的人都會說最好的解決熱點的方法就是分散化數據，那么你就要用掉更多磁盤驅動器。但是我認為，基于各種原因，這是非常錯誤的做法。我將在這里探討這種方法的利弊，并提供另一個解決這種問題的方法。記住，并不是所有人都相信的事情就一定是對的。地球不是平的。

簡要回顧熱點的歷史

追溯到上個世紀90年代初，當時開放系統上的RAID（獨立磁盤冗余陣列技術）還處于萌芽期，但是已經有一些使用于IBM主機上。EMC是RAID的領導者，而Veritas磁區管理也開始受到廣泛使用。在我看來，正式由于這兩個產品而產生了我們所謂的存儲架構的"熱點理論"。在那個時候，也許該理論就是這種問題的正確解決方案，但是我們現在有了其他工具來提供更好的解決方案。讓我們看看當時的解決方法以及為什么這種方法是可行的。

當時開放系統上的文件系統是標準的UNIX文件系統，這種文件系統占據很小的分配空間，而且文件系統的元數據區域和數據區域混在一起。從主機角度來看，IBM MVS占主導地位，其文件系統是記錄導向型的。這意味著大部分的UNIX文件系統的數據并不一定都要按順序分配，而MVS的分配基礎是記錄，因此數據庫也不是按順序分配的。這個時期，許多UNIX系統的數據庫用戶使用裸設備。

從存儲硬件角度來看，希捷公司推出了SCSI驅動器，給業界造成了轟動，他們替代了IP-3和其他類型的驅動器。下表顯示了SCSI驅動器的進步。

對照現在的進步： 

對照的幾個關鍵點是：

• 讀取整個磁盤驅動器所需時間從125秒增加到2400秒，是原來的19.2倍。
• 尋道加延遲時間從20.0毫秒減少道了7.69毫秒，原來所需時間是現在的2.7倍。
• 存儲密度增加了600倍。
• 帶寬增加了31.25倍。

磁盤雖然從2004年到現在變快了一些，但是幅度不大。綜合以上所述事實，結論是讀取整個磁盤的數據所需的時間大大增加了。舉個例子，比如現在有一個8KB大小的數據庫需要輸入/輸出。在1991年，按平均的尋道和延遲時間來計算，需要大約0.004秒來讀取該數據。今天，只需要0.0008秒就可以了，是原來的五分之一。這意味著當進行小量輸出/輸出請求時，尋道和延遲時間很可能左右整體的性能水平。這無需奇怪，因為磁盤驅動器本來就是一個機械裝置。這里有兩點：

• 在UNIX系統下啟動RAID、磁區管理軟件和文件系統時，將數據分散到多個設備是提高性能的唯一方法，這是因為相對于尋道＋延遲時間的進步，磁盤變慢了。
• 在早些時候，RAID高速緩存還很小，因此不能使用積極的預讀和后寫式工作模式。

因此，過去的情況就是：磁盤傳輸速率相對于尋道和延遲時間來說要快一些，文件系統將數據分成很小塊，磁區管理和RAID分配都不大（小于128K），積極的預讀模式不現實，而數據庫和應用程序也都相當小。因此，解決問題的唯一辦法就是將它們分成越小越好；在當時這是完全合理和唯一可行的方法。這種情況一直持續到大概2001年或2002年。此后我們看到：

• 可以按順序分配數據的文件系統，大的順序分配超過32MB；
• 中端產品的RAID高速緩存的大小超過2GB，而企業產品則超過64GB；而且
• 在切換到另一個設備之前，磁區管理可以按GB規模進行分配

我們看到磁盤驅動器也在發生變化，傳輸速率的提升幅度遠遠超過尋道和延遲時間的減小幅度。

解決熱點問題

任何一個精于存儲的人士都知道這里沒有萬靈藥，但是存儲架構的熱點理論卻被視為存儲的十大戒律之一。我并不是說這個理論是錯的，但是我覺得這種方法有問題。比如說我有一個文件系統和磁區管理，分配64MB或以上的順序分配數據。甚至還有一個RAID-5 8+1，也就是說，每個磁盤一個512KB的條帶，那么將有16個順序分配。想想這個?，F在的希捷硬盤驅動器，每個驅動器都擁有16MB的高速緩存。假設所有都是隨機的，那么進行磁盤預讀不會幫助提升性能。而且，每次尋道和延遲過程中平均可以傳輸的數據量為讀558KB，寫608KB。這也就是數據傳輸在每次輸入/輸出請求時所損失的性能。

在考慮順序分配之前，還有一個問題必須關注，即輸入/輸出請求是否是順序的，這個問題甚至我也不能做出百分之百的回答。熱點理論認為輸入/輸出請求是隨機的。我相信它并不百分百適用于所有情況，但是我也不能給出適用和不適用的比例分別是多少。我知道在HPC（高性能計算）領域，大部分應用的輸入/輸出請求是順序的。我知道備份過程中的輸入/輸出請求經常是順序的。我也知道一些數據庫訪問是隨機的，但是我也知道我所實際看到和跟蹤過的數據庫有時會按順序讀取索引一段時間，然后是突然變化，接著繼續按順序讀取。我在許多不同類型的數據庫上看到這種情況出現過很多次，但不是所有數據庫都是這樣。如果是RAID-1的輸入/輸出請求是按順序的，那么分配就可以是按順序的，如果此時請求也是順序的，那么預讀模式就可以大大提高性能，最大的好處是，你用不著那么多硬件了，因為磁盤的效率提高了。

現在熱點專家們聲稱他們的方法是提高存儲架構性能的唯一方法，但如果你采取進一步行動，分析你的數據訪問模式，并通過文件系統和磁區管理來合理地分配你的數據，那么你就可以獲得更好的性能，而不用那么多硬件，并具有更好的進退空間。如果發展到基于對象的存儲的階段–我希望如此–那么通過對象技術就可以讓系統智能地分辨數據訪問模式并調整預讀和后寫工作模式。無論未來如何，我都認為人們需要重新思考這個問題，并摸索其他可以利用現有技術來解決問題的方案。