存儲統一從理論上來看是不錯的。直連存儲(Direct-attached storage，DAS)的效率低是出了名的，有些陣列的使用率只有40%。
為一個甲骨文數據庫提供10000IOPS意味著需要集合數十塊15000轉的硬盤，除了數據庫的容量能夠達到數TB的情況外，大多數情況下都要浪費很多存儲空間。
替代方案是使用共享存儲，可能需要用到虛擬化技術和自動精簡配置來分配物理磁盤容量以提高效率，或者還可能利用閃存或高速緩存來提升性能。
除了減少浪費，共享存儲還可以提供其他的優點，比如減少管理點的數量。
但是如果你的某位客戶或某個應用不能正常工作怎么辦呢?如果它表現異常，不能發揮出共享存儲的“共享”特點怎么辦?
在很多系統中，很容易出現某一款應用占用大量存儲空間的現象，這樣留給其他應用的存儲空間就非常有限了。
要素
NetApp的產品、解決方案和聯盟營銷主管約翰羅拉森(John Rollason)表示：“服務質量比人們所說的更重要。它看似小事，但是如果沒有它，共享存儲的很多價值就不復存在了。”
“如果你的共享存儲平臺上沒有服務質量，你就無法在用戶移動到虛擬化環境時保證整體服務質量。 虛擬化也會讓I/O變得更加隨意。”
Virtual Instruments的EMEA地區解決方案顧問主管亞歷山大德安娜(Alex D'Anna)稱，最常見的一個例子是當應用不是用于共享，而且有不同的訪問方式時的情況。
他說：“真正有趣的使用案例是對服務需求很大的應用。” 他引用了一個客戶的真實案例。盡管那位客戶擁有大量的SAN容量，但他在安裝關鍵SAP應用時仍然遇到了很多問題。
德安娜稱：“SAP可以協助你生產，但是你還需要數據倉儲和業務分析工具來輔助預測。我們認為最神奇的是客戶擁有完全不同的讀寫方式，數據倉儲完全把8Gbps的光纖通道SAN都占用光了。”
他補充說，一旦你進入云中，這個難題就被放大了。他說：“使用云存儲，人們想要的是降低準備的要求。 我們是在共享最終將占據主流地位的假設之上工作的。在平臺上，你需要知道正在發生什么情況。”
“例如，當出現性能問題的時候，人們會要求將它們推后到專用存儲區去。但是在云中，你就不能那么做了。”
填飽饑餓的應用
富士通產品營銷高級主管弗蘭克賴卡特(Frank Reichart)也有同感。他說：“服務質量是存儲統一的必要條件。 不可能不談這一點。”
他說：“如果你什么都不做，那么需要大部分性能的服務器就會得到它，如果那是你的商業情報系統，那么對響應時間有很高要求的生產系統就會受到影響。 服務質量還會妨礙到受控于服務級協定的組織，如果你不能設置服務質量，那么使用簡單應用的用戶就遭殃了。”
商業情報問題是個大問題，因為越來越多的商業情報用戶想查詢生產數據，因為他們想了解建立一個專用數據倉庫的成本和拷貝數據所需的時間。
試圖使用那部分存儲資源的其他人也許會受到影響，因為他們不能馬上獲得結果
這并不是特例。大量的數據庫查詢可能也會輕易地耗盡所有的I/O資源，從而影響到上網和收發電子郵件等活動。 談到共享存儲上的VDI啟動風暴的影響，試圖使用那部分存儲資源的其他人也許會受到影響，因為他們不能馬上獲得結果。
這些問題都可能被公共云運營商遇到，它們的存在和收益與共享資源的能力息息相關。
而且這也越來越適用于IT部門，因為它們與公共云運營商一樣，也必須為多個內部客戶服務，而它們的收入卻越來越少。
那么存儲開發商怎么做才能處理好這個問題并且保證提供公平和適當的訪問通道，而不用強迫你通過大把花錢增加存儲空間來解決問題呢?
首先明顯要添加服務質量機制，為所有的應用分配優先等級。阻止流氓應用或客戶。 其中一種簡單的做法是限制某些應用的I/O速率，讓它們不能把所有的資源都占用。
Debriefing Software的首席技術官杰斯珀馬蒂森(Jesper Matthiesen)說，那也可以很簡單。他說：“我并不認為帶寬節流是件好事，因為如果有存儲容量的話，你就應該去使用它。”
另一種方法同時也是很多領先的開發商比如富士通、NetApp和NexGen等所選擇的方法是，執行最低而不是最高的應用數據處理水平。
額外的部分
我的想法是，一旦對存儲性能的總需求超過了系統能夠提供的水平，那么系統就會按照先來后到的順序去授權I/O要求，系統會確保每一臺服務器都得到最低水平的IOPS。之后，它就會將剩余的性能分配給擁有最高優先權的工作負載。
添加閃存在實現存儲服務質量上同樣重要，因為當高速緩存中的項目被存在閃存中的時候，就有更多的IOPS能夠分配給優先等級高的應用了。
最后的要素是自動化。賴卡特說：“實際上，設置服務質量的各項參數是一件完全不同的事。”
他說：“通常，那些指標會是響應時間，但是要想將響應時間降低到5毫秒以下，對于數據庫來說那會是一件非常復雜的任務。你可能不得不設置20種不同的參數。 盡管那樣，它也是個活動的目標，因為一旦你設置好你想要的服務質量，另一個應用就會闖進來，然后你就不得不從頭再來一次。”
他繼續說：“你想要的是自動化或半自動化的系統，它應該能夠自動優化，那樣管理員就只需要定義各項條件，然后讓系統完成剩余的工作就行了。它還需要更多的報告和監控功能，比如哪些LUN在使用哪些存儲資源，哪個應用在哪一級存儲層上運行。”
“或者，人們也許可以放棄統一或尋找獨立的解決方案，但那些解決方案顯然效率低下，而且會導致過分預備。”
那意味著在規劃容量和建模時要特別小心你的存儲系統已經生成的所有性能數據。
從為物理工作負載容量建模開始，然后給主機建模，比如你可以說一臺數據庫服務器需要一定數量的I/O。
然后你就可以開始定義監控政策，將高性能主機遷移到高性能存儲層級或將低性能主機遷移到低性能存儲層級。
比較好的做法是將你的主存儲器分成不同的層級，通常分為高、中和低性能3個層級。然后，你就可以為每個層級定義服務級協議，包括存儲可以占用多少I/O，在延時上應該有什么樣的限制，它應該提供何種水平的可用性等等。
前方危險
如果一切順利，你就會想讓系統去完成盡可能多的重復性工作，幸運的是，這些都可以用工具來自動完成。
但是馬蒂森警告說，雖然這些工序中的某些工序可以而且應該能夠自動完成，但是所用的工具卻是強大并且可能也是危險的。權力越大，責任越大，當然風險也越大。
例如，將一個主機從一個層級移動到另一個層級可能會涉及到數百MB的數據移動，需要使用大量的I/O資源，而移動那么多數量的數據將會對其他的系統造成影響。
馬蒂森說：“你必須小心處理，因為這是貴公司的核心。移動數據有可能造成巨大的影響。 因此必須慎之又慎。”
“對配置進行重要變更仍然需要人類的知識，因為它需要了解業務以及具有技術上的見解。”
京公網安備 11010502049343號