儲存革命？另眼看謎樣的軟體定義程式儲存

標籤：解決方案   軟體   供應商   辦公   搬遷   

   最近，軟體定義程式儲存領域頻頻顯露出來“從各處買進”現象，新產品的宣布訊息兒也川流不息。這禁不住讓人發問，“軟體定義程式儲存”這個在2013年被次數多提及的IT熱詞，到底會對我們萌生怎樣的影響?

　　固然各大廠商都在宣傳“軟體能幫忙數值核心儲存脫離硬體主導的約束限制”，但使用者始末仍然需求建造硬體平台來運行軟體，匡助軟體定義程式儲存的辦公。儘管眼下已經有發展方向表明軟體定義程式儲存著手向商用標準樣式搬遷，他們與傳統標準樣式之間的差別仍值當我們注意。辦公負載以及不一樣的基礎裝置和基礎裝置標準樣式給實效果導致的影響也不盡相同。

　　現在越來越多的產品推出了共用式DAS儲存架構，意在從基礎裝置中移除SAN並減低群體複雜程度。然而其對複雜性的減低效果還要等待商討，它所起到的更多是一個轉化的效用。其實它並沒有真正地移除SAN，只是對其施行改進。

　　使用者對於儲存廠商以各種方式演習的無共用叢集架構已經責備不怪，一般此類產品都歸屬軟硬體整合的“打包”型解決方案。然而隨著終端使用者對部署自有硬體有經驗的需要愈發猛烈，也催產了前所未有的新式機制。

　　一朝使用者脫離了供應商對底層基礎裝置的嚴明掌控，相應的儲存軟體務必更具智能化。而終端使用者執行團隊則需求學會像供應商的硬體團隊那樣子仔細看裝置、酌量方案。

　　舉例來說，數值核心的東-西向流量標準樣式就變得十分關緊。IT營運擔任職務的人有可能會發覺自個兒需求部署低延緩儲存網路;全新的SAN網路不再遵循北-南標準樣式而轉向伺服器-伺服器(即東-西)標準樣式。從傳統角度看，這些個辦公原本是虛擬化技術擔任職務的人才需求關心注視的內部實質意義。

　　再者就是理解效能與故障方面的問題：我們在儘力照顧本地DAS時是該利用RAID仍然將其改造為散布式RAIN(即獨立節點冗餘陣列)標準樣式?假如大家有意將數值核心內的全部儲存資源並肩萃聚成一套極大的資源集區，那末純一節點發生故障會給整個的局面：胸懷～整體體系帶來何種影響?又會不會給整個兒資源集區的效能導致牽累?

　　不論什麼與散布式儲存標準樣式打過打交道的技術擔任職務的人一定都有這麼的體驗領會：效能低下甚至於顯露出來故障的節點所帶來的影響遠遠超乎我們的假想。有時，其表達與當時的靈位環網非常大致相似，純一的介面配備布置不合適便會以致完套整體體系的效能陷於泥坑。與此相形，重複IP地址導致的影響甚至於可以疏忽不計較。

　　那末純一的計算或儲存節點發生故障會導致哪一些影響?多個計算/儲存節點顯露出來故障又是怎樣的事情狀況?

　　在以往，這些個問題都應由儲存硬體供應商負責，本地儲存團隊的實行階段也無須使用者加入。但如今的軟體定義程式儲存，需求我們制定一系列決策，深刻思考怎麼樣儘力照顧數值、瞭解副本機制帶來的影響等。

　　從理論上說，我們都期望自個兒的數值與處置機制間的距離越近越好。不過數值本身有連續不斷性，需求長時期佔用空間。錯非我們能發明出一套完全可以正確幫忙電腦制尋覓數值位置的動態基礎裝置，否則搬遷辦公也就在所難以避免。

　　這個之外，供應商們也需求進一步改進其硬體設施。而在這種複雜背景下的儲存系統運行機制，可謂是謎樣又淫穢不易懂難懂。為了與之相協調，軟體複製功能與大規模商用基礎裝置也務必在當下的基礎上更進一步，否則根本沒有辦法支撐起廣泛的實踐應用。

　　然而我們也看見多家廠商也在頻頻出新招，推出開源或閉源的解決方案，儲存大型客戶對此也表達出了莫大的興緻。儲存變法將走向何方?讓我們拭目以待吧。

儲存革命？另眼看謎樣的軟體定義程式儲存