在老式的存儲產品上很容易挑出毛病，特別是在公共和私有云部署整合的時候。然而當實施云框架時究竟需要什么是值得討論的，因為存儲被部署的方式與存儲操作的傳統(tǒng)模式是截然不同的。在本文中我們將要探討為什么傳統(tǒng)的存儲管理方式需要改變，它將如何影響硬件的使用方式。這就引發(fā)了一個關于API的討論，還有就是它們在高效進行云部署時是不可或缺的。

傳統(tǒng)模式

在過去的十年左右，存儲管理的傳統(tǒng)模式包括多個存儲管理員，使用GUI，CLI和/或腳本來處理商業(yè)用戶的存儲需求。這個過程是高度人工的，在需求者，存儲管理員和其他諸如計費，變更控制，容量管理和工作調度的中間人之間有許多關聯(lián)。這使得整個過程非常的人員密集和毫無意外的延長交付時間。許多最終用戶還會有這種經歷，就是他們具體需求的要求被告知他們只能有一些“現(xiàn)成的”東西——比如一個標準LUN大小和帶有一個特定RAID保護的存儲。這樣做的原因很明顯：首先大型陣列的配置取決于規(guī)劃和確定的設計，通常在硬件安裝時建立。一旦確定并投入使用，它就不能再改變了(或至少在沒有顯著影響和成本時改變)。其次，這也是行得通的，就是把需求降低到一個更小的子集，好讓配置過程更為容易。還有死板的配置，許多傳統(tǒng)的陣列都把LUN的創(chuàng)建和配置當成是一個罕見的任務。許多請求會被打包和批量執(zhí)行，這樣肯定不能輕松應對并發(fā)請求。盡管可以通過使用CLI和腳本來自動化一些配置過程，但這并不能解決創(chuàng)造即需型模型的實際需要。

新世界

當我們規(guī)模擴大到更大的IT部署，特別是在基于服務的或“云”配置下時，在配置過程中出現(xiàn)大量人工干預的思路就行不通了。我們需要轉向一個“按需求存儲”的模型上，在這里一個外部代理(用戶或業(yè)務流程軟件)可以作為一個入口請求存儲，并能實時或至少幾分鐘或幾小時內查看請求的處理情況。這種操作只在硬件被按目的設計好后才提供。在這之前，存儲管理員在每個配置請求時都要參與，那些請求會在一個由管理員或存儲架構師定義的配置框架內處理。

Framework

我們所說的Framework是什么意思?它就是在分配發(fā)生時建立一套參數。這可能包括：

LUN Size

彈性/可用性

性能

安全證書

快照策略

按需LUN的容量

架構師來選擇滿足要求的特定硬件組件。

還有一些使用局限：

并發(fā)請求的最大數量

每小時配置請求的最大數量

暫停或拒絕陣列配置請求的能力

按陣列容量限制請求

按容量準則限制用戶請求

設置框架還需要自主異步工作能力;就是說，接受，處理和告知請求無需請求者與陣列一直保持會話。一旦請求完成，請求者就會被一個回調機制或人工告知請求是否完成。顯然需要對監(jiān)測框架進行整合，以便跟蹤硬件和性能問題。

設計API

當然，有一個很大的問題，就是關于是否API可以替換現(xiàn)有的存儲。以經典IT傳統(tǒng)的答案是“這取決于”。毫無疑問，沒有本地API功能的話，新的存儲陣列就不應該發(fā)布。然后，讓API迎合現(xiàn)有技術將取決于現(xiàn)有配置過程的靈活程度。創(chuàng)建一個API外包并在中間件層建立自動化是可行的。這也是像 iWave的Storage Automator這類產品的做法。然而對現(xiàn)有的存儲產品增加這些功能代價是非常大的而且仍是一個不完善的解決方案。

存儲架構師的觀點

隨著新的存儲平臺的發(fā)展，本地API支持是一種必然。存儲管理員只需簡單的部署基礎設施并把它連接到更高的框架內，配置過程就會完全自動化。提供的這一級別功能的供應商將成為最有吸引力的服務供應商——使獲取和管理存儲的成本盡可能廉價。我們將看到一個存儲管理方式的轉變，也許再也不用存儲管理員了。