企業雲基礎設施提供存儲API不可或缺

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

傳統模式

傳統的配置過程

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

新世界

API配置過程

當我們規模擴大到更大的IT部署，特別是在基於服務的或「雲」配置下時，在配置過程中出現大量人工干預的思路就行不通了。 我們需要轉向一個「按需求存儲」的模型上，在這裡一個外部代理(使用者或業務流程軟體)可以作為一個入口請求存儲，並能即時或至少幾分鐘或幾小時內查看請求的處理情況。 這種操作只在硬體被按目的設計好後才提供。 在這之前，存儲管理員在每個配置請求時都要參與，那些請求會在一個由管理員或存儲架構師定義的組態架構內處理。

Framework

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

LUN Size

彈性/可用性

性能

安全證書

快照策略

按需LUN的容量

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

還有一些使用局限：

併發請求的最大數量

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

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

按陣列容量限制請求

按容量準則限制使用者請求

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

設計API

當然，有一個很大的問題，就是關於是否API可以替換現有的存儲。 以經典IT傳統的答案是「這取決於」。 毫無疑問，沒有本地API功能的話，新的存 儲陣列就不應該發佈。 然後，讓API迎合現有技術將取決於現有配置過程的靈活程度。 創建一個API外包並在中介軟體層建立自動化是可行的。 這也是像 iWave的Storage Automator這類產品的做法。 然而對現有的存儲產品增加這些功能代價是非常大的而且仍是一個不完善的解決方案。

存儲架構師的觀點

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