虚拟SAN对驱动器槽的利用使其看起来是个可行的存储选项，但它带来了额外的流量负担，可能产生消极影响。
在产品常常吹嘘过头的存储市场中，虚拟SAN最该挨鞭子。基于超融合系统的理念，虚拟SAN被吹捧成一种解决所有SAN与存储设备痛点的方式。当然，我们还是得檫亮眼睛，探究其所宣称的是否属实，虚拟SAN价值主张能否在数据中心占有一席之地。
围绕着虚拟SAN的最初讨论基于对虚拟集群中的每台服务器上的驱动器槽的使用。为每台服务器添加10TB逻辑驱动，你就能获得PT级的驱动容量，无需购买存储设备。
表面上，这样做很理智，但细节经不起推敲。数据必须与集群中所有其他服务器共享。这意味着每台服务器必须支持的额外LAN存储流量是原始I/O负载的两倍。额外的负载是个问题，尤其是在网络本来就很紧张的虚拟环境中。
让我们调查一下以前使用驱动器槽的基本前提。我们了解到云供应商使用极简硬件，并且目前市面上售卖的服务器只包括一个驱动器槽，甚至为了节省成本一个都没有。某种意义上，这表示即使虚拟SAN避免了购买存储单元的成本，那再去购买驱动槽设备的成本也不低啊。
将虚拟SAN软件与传统存储方式进行对比也有问题，由于我们迁移到小型模块化存储设备，而不是大型阵列。这些阵列为存储量身定制，一般包含12个驱动、一个存储界面交换机与一个头处理器。使用虚拟SAN的额外服务器成本可能超过等同效果设备的成本，尤其是买的是廉价或初创厂商的设备是更是如此，相当划不来。
用户在快速进化的存储市场更应该谨慎。随着25GbE的袭来，LAN速度增加了2.5倍，同时远程直接内存访问的延迟降低70%，显著减少服务器存储操作的开销。但这就够了么?
虚拟SAN可以列出一些技术参数。首先，到服务器的存储I/O是不对称的。读写速率通常是8:1，这意味着在一个完全双网的以太网环境中，出站流量使用带宽，否则就浪费了。
另一个争论是实例需要一个本地永久存储设备来运营。因此，本地实例存储通过云厂商提供。为什么不将这种存储作为虚拟SAN使用呢?这又让我们回到了带宽争论这个话题。如果虚拟环境的目标是在出现故障时使用自动化的恢复路径，从而提供编排的话，在对本地磁盘上复制数据需要在另一台服务器上进行，以便消除单点故障。
这种复制抵消了在虚拟SAN争论中本地实例存储的价值。
统一管理是针对虚拟SAN的又一争论。事实是多数存储管理关乎设置LUN，并发现坏掉的驱动，在处理虚拟SAN时也是如此。有个通用平台是能让存储与服务器管理团队融合在一起，但在由诸如iSCSI与对象存储等以太网协议掌控的世界中，两个团队的独立更具有政治与行政意义。
当然，底线是别将虚拟SAN看作是与传统存储一样好的选项，必须搞清楚它的价值主张，符合平台与方法论的发展。
