当实施软件定义存储等新技术的时候，用户必须考虑访问点、应用程序接口（API）和初始格式化，以达到取得最佳性能和容量的效果。

　　实施得当的话，软件定义存储在应用程序和物理存储资源之间建立一个独立于硬件并与工作负载无关的存储应用层。与使用任何技术一样，实施这种软件定义抽象层的方法也有对错之分。

　　方法之一是使用存储硬件的应用程序接口（API）、将硬件厂商提供的“挂钩”（“hooks”）用于在板的、基于控制器的软件构建卷、将卷与阵列中以增值软件形式提供的服务相互关联，建立存储虚拟化层。这种方法的问题在于：与多个厂商的基本套件的更新保持同步的成本高昂，主要体现在软件的成本方面。如果硬件厂商更新其固件或者软件，软件定义存储的厂商必须“跟上”这些更新，在这个过程中可能对消费者造成不便。

　　同样地，如果市场上出现新的技术，只有存储虚拟机管理程序的厂商将其添加至所支持的产品清单里面，消费者才可能利用上（这些技术）。支持方面的问题可能源于：硬件厂商退出存储业务，或者被没有将其API与存储虚拟机管理程序的厂商共享的硬件厂商收购。底线：把多个API连接归拢到很多存储平台之上无异于驯猫，使这项战略成为莽夫之勇。

　　你可以利用存储设备的安装点作为虚拟化的点。与单独连接每一个硬件平台并因此依赖于存储厂商访问其API不同，存储专业人员可以利用厂商必须与市场份额领先的服务器操作系统（所有人都必须使其套件与Microsoft Windows Server操作系统兼容）进行的连接。通过安装点对存储进行虚拟化的效果等同于通过存储硬件API对存储进行虚拟化，而且不太容易中断。

　　一旦建立了与物理基础设施的连接，大多数存储虚拟化产品需要虚拟控制器控制安装点显示的容量。与一个卷会被格式化成一个文件系统的情况类似，存储虚拟化软件产品通常需要一个接管通过物理存储的加载而显示的容量的过程。这可能会花点时间，需要向由基础设施显示的每个卷或者每个驱动器上的每一个位单元（bit location）写入0。结果得到一个存储池，可以作为已关联了数据保护服务和性能特性的虚拟卷被有效地进行管理和解析。这些池可以由这种卷构成，为分层存储提供基础。

　　首次对虚拟化的或者软件定义的存储环境的进行格式化可能需要一些时间。通常需要从每台打算被虚拟化和被集中共用的阵列中把数据迁移出来，然后在迁移回到虚拟卷。增量完成，每次一个应用程序或者每次一个业务流程，你通常可以通过有条不紊和可靠的方式完成这项任务。在这个过程中厂商通常提供向导协助。

　　确保寻求没有仅限于（或者主要地）与特定厂商的硬件或者服务器虚拟化软件连接的软件定义存储的产品。在软件定义基础设施的业务中，不可知论受到高度重视，并意味着建筑自由和成本遏制。你应该考虑既可以作为集中式服务器又可以作为联合资源管理器进行实施的产品。集中式服务器支持单点或多点的集群故障切换，即使在复杂的SAN基础设施中也能够易于管理和控制。联合部署能力将有助于满足虚拟化存储服务必须靠近应用程序工作负载进行交付的要求，大多数服务器端的固态部署模式也是同样的情况。最佳的软件产品将通过跨越多个软件部署的集中式配置管理工具，同时支持集中式和联合式部署实施。

　　从小规模做起，增强信心后再扩张。好消息是：设计得当的软件定义存储的实施应该取得2-4倍的应用程序的性能的改善，就像固态I/O排队的功能出现在磁盘式的基础设施面前一样。这并不神奇，高速缓存内存置于任何网络附加存储或者网络化存储设备面前的时候也是一样的（例如，NetApp的存储上的性能加速模块Performance Acceleration Module或者闪存控制器）

　　除了性能的改善，你还可以把数据保护和容量管理服务托付给软件定义存储层，而非为每台阵列上的增值软件签订昂贵的年度合同。最终，这可能不仅是为软件定义存储技术方面的投资埋单了。