近來，軟件定義存儲領域頻頻出現“收購”現象，新產品的發布消息也絡繹不絕。這不禁讓人發問，“軟件定義存儲”這個在2013年被頻繁提及的IT熱詞，究竟會對我們產生怎樣的影響?
雖然各大廠商都在宣傳“軟件能幫助數據中心存儲擺脫硬件主導的束縛”，但用戶始終還是需要搭建硬件平臺來運行軟件，輔助軟件定義存儲的工作。盡管眼下已經有趨勢表明軟件定義存儲開始向商用模式遷移，它們與傳統模式之間的差異仍值得我們注意。工作負載以及不同的基礎設施和基礎設施模式給實際效果造成的影響也不盡相同。
如今越來越多的產品推出了共享式DAS存儲架構，意在從基礎設施中移除SAN并降低整體復雜程度。不過其對復雜性的降低效果還有待商榷，它所起到的更多是一個轉化的作用。實際上它并沒有真正地移除SAN，只是對其進行改進。
用戶對于存儲廠商以各種形式演示的無共享集群架構已經見怪不怪，通常此類產品都屬于軟硬件集成的“打包”型解決方案。不過隨著終端用戶對部署自有硬件能力的需求愈發強烈，也催生了前所未有的新型機制。
一旦用戶擺脫了供應商對底層基礎設施的嚴格掌控，相應的存儲軟件必須更具智能化。而終端用戶執行團隊則需要學會像供應商的硬件團隊那樣審視設施、斟酌方案。
舉例來說，數據中心的東-西向流量模式就變得非常重要。IT運維人員可能會發現自己需要部署低延遲存儲網絡;全新的SAN網絡不再遵循北-南模式而轉向服務器-服務器(即東-西)模式。從傳統角度看，這些工作原本是虛擬化技術人員才需要關注的內容。
再者就是了解性能與故障方面的問題：我們在保護本地DAS時是該利用RAID還是將其改造為分布式RAIN(即獨立節點冗余陣列)模式?如果大家有意將數據中心內的所有存儲資源共同匯聚成一套龐大的資源池，那么單一節點發生故障會給全局體系帶來何種影響?又會不會給整個資源池的性能造成拖累?
任何與分布式存儲模式打過交道的技術人員一定都有這樣的體會：性能低下甚至出現故障的節點所帶來的影響遠遠超乎我們的想象。有時候，其表現與當初的令牌環網很類似，單一的接口配置不當就會致使整套體系的性能陷入泥潭。與此相比，重復IP地址造成的影響甚至可以忽略不計。
那么單一的計算或存儲節點發生故障會造成哪些影響?多個計算/存儲節點出現故障又是怎樣的情況?
在過去，這些問題都應由存儲硬件供應商負責，本地存儲團隊的實施階段也無需用戶介入。但現在的軟件定義存儲，需要我們制定一系列決策，思考如何保護數據、理解副本機制帶來的影響等。
從理論上說，我們都希望自己的數據與處理機制間的距離越近越好。然而數據本身有持續性，需要長期占用空間。除非我們能創造出一套足以準確幫助計算機制尋找數據位置的動態基礎設施，否則遷移工作也就在所難免。
此外，供應商們也需要進一步改進其硬件設備。而在這種復雜環境下的存儲系統運行機制，可以說是謎樣又晦澀難懂。為了與之相協調，軟件復制功能與大規模商用基礎設施也必須在當下的基礎上更進一步，否則根本無法支撐起廣泛的實踐應用。
不過我們也看到多家廠商也在頻頻出新招，推出開源或閉源的解決方案，存儲大型客戶對此也表現出了極大的興趣。存儲變革將走向何方?讓我們拭目以待吧。
京公網安備 11010502049343號