在合理实施的情况下，软件定义存储能够在应用和物理存储资源之间建立硬件独立和负载无关的存储应用层。与任何技术实现一样，在实施软件定义存储抽象层时也有正确和错误的方式。
一种建立存储虚拟化层的方式是通过存储硬件的应用编程接口，利用厂商在其机载的、基于控制器的软件所提供的“钩子”，它作为一种增值软件用来创建卷以及将卷与阵列上的服务相连接。像这样的方式面临的问题是，与多厂商提供的底层工具包保持同步的成本很高，也就是软件成本。如果一家硬件厂商在其固件或软件做了更改，那么软件定义存储厂商必须赶上这些变化，这过程也可能给消费者带来不便。
同样的，如果一种新技术出现在市场中，消费者可能还不能够去利用它，直到一家存储虚拟化管理厂商将它添加到自己的支持产品列表中。当硬件厂商甩掉存储业务或者被一家不分享API给存储虚拟化厂商的硬件厂商收购，支持问题就会出现。总之，争论多存储平台的API连接并没有太大意义。
你可以利用存储设备的安装点作为虚拟化的挂载点。并非分别连接到每一硬件平台——由此对允许访问其API的存储厂商心存感激——存储专业人士可以与占据市场领先的操作系统建立厂商联系（每个人都需要让他们的工具包与微软WindowsServer OS兼容）。经过安装点的虚拟化存储和在存储硬件API上实现的虚拟化存储一样有效——并且更不容易中断。
一旦到物理基础设施的连接被建立，大多数存储虚拟化产品就需要虚拟控制器来控制容量。就像卷会被文件系统格式化一样，存储虚拟化软件产品一般也需要这样一个过程来接管物理存储上的容量。这可能会花费时间，结果就会出现一个存储池，它能够被有效管理并解析出关联有数据保护服务和性能特征的虚拟卷。存储池就由这些卷组成，为分层存储提供基础。
初次格式化虚拟的或是软件定义的存储环境可能会花些时间。它通常需要迁移即将被虚拟化和池化的阵列数据，然后再回到虚拟卷上。逐步完成，一次一个应用或者一次一个业务流程，你通常会以一种系统可靠的方式完成它。厂商通常会提供这些流程的指南。
要了解寻找软件定义存储产品并非主要与一个特定厂商的硬件或者服务器虚拟化软件相关。在软件定义基础设施的商业中，无关性被高度赞扬，这是一种架构自由和成本控制。你应该考虑产品的实施支持，无论是作为一个中央服务器还是一个联合资源经理。中央服务器，支持集群故障转移将使能在复杂SAN基础设施中的管理和可控，通常在大多数服务器端固态部署模型中，联合部署的能力将满足虚拟存储服务需要交付应用负载的需求。最好的软件供应将支持这两方面的实现。
一开始尝试并随着信心的增加扩展。一个设计合理的软件定义存储实施方案会看到应用性能提升2-4倍。除此之外，你可以将数据保护和容量管理服务委托给软件定义存储层，而无需每年购买昂贵的阵列增值软件。也许有一天，你在软件定义存储技术上的投资回报可能超出预期。
本文转自d1net（转载）
