當實施軟件定義存儲等新技術的時候，用戶必須考慮訪問點、應用程序接口(API)和初始格式化，以達到取得最佳性能和容量的效果。
實施得當的話，軟件定義存儲在應用程序和物理存儲資源之間建立一個獨立于硬件并與工作負載無關的存儲應用層。與使用任何技術一樣，實施這種軟件定義抽象層的方法也有對錯之分。
方法之一是使用存儲硬件的應用程序接口(API)、將硬件廠商提供的“掛鉤”(“hooks”)用于在板的、基于控制器的軟件構建卷、將卷與陣列中以增值軟件形式提供的服務相互關聯，建立存儲虛擬化層。這種方法的問題在于：與多個廠商的基本套件的更新保持同步的成本高昂，主要體現在軟件的成本方面。如果硬件廠商更新其固件或者軟件，軟件定義存儲的廠商必須“跟上”這些更新，在這個過程中可能對消費者造成不便。
同樣地，如果市場上出現新的技術，只有存儲虛擬機管理程序的廠商將其添加至所支持的產品清單里面，消費者才可能利用上(這些技術)。支持方面的問題可能源于：硬件廠商退出存儲業務，或者被沒有將其API與存儲虛擬機管理程序的廠商共享的硬件廠商收購。底線：把多個API連接歸攏到很多存儲平臺之上無異于馴貓，使這項戰略成為莽夫之勇。
你可以利用存儲設備的安裝點作為虛擬化的點。與單獨連接每一個硬件平臺并因此依賴于存儲廠商訪問其API不同，存儲專業人員可以利用廠商必須與市場份額領先的服務器操作系統(所有人都必須使其套件與Microsoft Windows Server操作系統兼容)進行的連接。通過安裝點對存儲進行虛擬化的效果等同于通過存儲硬件API對存儲進行虛擬化，而且不太容易中斷。
一旦建立了與物理基礎設施的連接，大多數存儲虛擬化產品需要虛擬控制器控制安裝點顯示的容量。與一個卷會被格式化成一個文件系統的情況類似，存儲虛擬化軟件產品通常需要一個接管通過物理存儲的加載而顯示的容量的過程。這可能會花點時間，需要向由基礎設施顯示的每個卷或者每個驅動器上的每一個位單元(bit location)寫入0。結果得到一個存儲池，可以作為已關聯了數據保護服務和性能特性的虛擬卷被有效地進行管理和解析。這些池可以由這種卷構成，為分層存儲提供基礎。
首次對虛擬化的或者軟件定義的存儲環境的進行格式化可能需要一些時間。通常需要從每臺打算被虛擬化和被集中共用的陣列中把數據遷移出來，然后在遷移回到虛擬卷。增量完成，每次一個應用程序或者每次一個業務流程，你通常可以通過有條不紊和可靠的方式完成這項任務。在這個過程中廠商通常提供向導協助。
確保尋求沒有僅限于(或者主要地)與特定廠商的硬件或者服務器虛擬化軟件連接的軟件定義存儲的產品。在軟件定義基礎設施的業務中，不可知論受到高度重視，并意味著建筑自由和成本遏制。你應該考慮既可以作為集中式服務器又可以作為聯合資源管理器進行實施的產品。集中式服務器支持單點或多點的集群故障切換，即使在復雜的SAN基礎設施中也能夠易于管理和控制。聯合部署能力將有助于滿足虛擬化存儲服務必須靠近應用程序工作負載進行交付的要求，大多數服務器端的固態部署模式也是同樣的情況。最佳的軟件產品將通過跨越多個軟件部署的集中式配置管理工具，同時支持集中式和聯合式部署實施。
從小規模做起，增強信心后再擴張。好消息是：設計得當的軟件定義存儲的實施應該取得2-4倍的應用程序的性能的改善，就像固態I/O排隊的功能出現在磁盤式的基礎設施面前一樣。這并不神奇，高速緩存內存置于任何網絡附加存儲或者網絡化存儲設備面前的時候也是一樣的(例如，NetApp的存儲上的性能加速模塊 Performance Acceleration Module或者閃存控制器)
除了性能的改善，你還可以把數據保護和容量管理服務托付給軟件定義存儲層，而非為每臺陣列上的增值軟件簽訂昂貴的年度合同。最終，這可能不僅是為軟件定義存儲技術方面的投資埋單了。
京公網安備 11010502049343號