这两天看了几个大V的Blog，不禁倒吸一口凉气，原来VMware Virtual SAN要做成一款通用的存储。



大家知道，VMware VSAN给大家的印象就是它只在VMware vSphere环境下使用，大家都理解它就是vSphere内核的一部分。由于VMware在Hypervisor领域处于垄断地位，大家本来就很怕了，现在VMware居然要把VSAN做成一款通用的存储。这么多SERVER SAN厂商还怎么活啊？
首当其冲肯定就是EMC的ScaleIO，它相比VSAN的优势就是扩展性比较强，而且可以脱离VMware使用，支持异构的Hypervisor。可是现在，VSAN未来也是一款通用的存储平台，扩展性肯定也不是问题。双方的市场再也没有交错的地方，全面的冲突不可避免。
DELL收购EMC后，EMC对VMware的控制权转移到了DELL这边。预计VMware会更加独立，更加自由。没有了EMC联邦的约束，VSAN的通用存储平台梦想应该很快就要到来。其他SERVER SAN的好日子快结束了。
好了，不替VSAN做广告了。我们简单来理解一下为啥VMware要这么做？因为马上要进入一个后虚拟化的时代，那个时候，vSphere就不是必须的了，但存储还是必须的。
话说VMware刚做VSAN的时候，确实定位为只针对vSphere环境。因为那个时候，hypervisor如日中天，docker还是非常小众。关键是应用都是典型的传统的大型（monolithic)应用，如SQL SERVER，ORACLE，Exchange等等。很多的应用都不是为了分布式环境设计的，因此，vSphere丰富的功能，如DRS，HA，FT还有丰富的数据服务对提高这些应用的可靠性、可用性价值很大。

在这样的情况下，VSAN捆绑vSphere就带来巨大的差异化优势。
1、用户无需配置和管理存储集群，避免SAN管理里面复杂的zoning和fencing相关的配置；
2、无缝集成vSphere的管理工作流，如升级，维护，HA等等，无需单独再开发，使用也更简单；
3、所有存在的API和工作流都可以工作，只需要增加存储相关的API；
4、计算和存储集群成员的紧耦合简化管理和排错，可以重用vCenter的告警和任务管理。
也就是说，设计VSAN的时候，和vSphere紧耦合是最符合VMware当时市场和研发策略的。
但现在时代变了，Docker容器和微服务大行其道，大有取代hypervisor之势。VMware也宣布推出Photon平台，全面拥抱容器时代。
但VSAN怎么办，在新时代，可能不需要vSphere，VSAN还能用吗？
现在VM使用存储的方式是采用 Virtual SCSI (VSCSI) 磁盘的方式，主要是这样没有兼容性问题。VSAN也是仿真成hypervisor里面的SCSI控制器和设备，其他厂商也一样。但VSAN最重要的转折在于细粒度的存储策略供给和管理（SPBM)。

在VSAN里，每一个VM甚至每一个VMDK(VSCSI disk)都可以采用不同的QoS特性供给。而用户用策略去使用不同的存储资源。这种方法好处很多。不像VMFS，VSAN不是一个集群文件系统。它实际上是一个基于对象的存储系统。一个VM包含一定数量的对象。对象就像一个数据+元数据的自给单位，它包含部分或者整个文件系统，VSCSI磁盘的内容等等。从这个意义讲，VSAN和Ceph对象后端的RADOS很像。
这个太重要了。因为这说明VSAN是通用的基于对象的存储平台，因此就不仅只用作VSCSI磁盘，不仅仅只支持今天的虚拟化环境。也就是说，其实ESXi软件的VSCSI模块和VM元数据模块（VMFS文件系统）都是VSAN的接口层。值得注意的是，这个对象接口和控制平面VMware把它对外开放了，这就是今天的VASA Virtual Volumes规范。我终于知道为啥VVOLs要晚于VSAN推出了，原来是这样的啊，原来以为是VMware故意的呢。

现在的IT世界已经处于软件驱动的变革当中。第三平台的应用（或者叫原生云应用）越来越多，新的应用基本都是这个形态。这种应用的分发，扩展和资源控制都是以微服务的粒度。vSphere那种类型的资源池和DRS/HA服务不再适应于新的应用。实际上，作为管理抽象的vSphere的集群甚至不再重要。那是一种完全不同的管理模型，其物理基础架构对应用本身是可见的和可管理的，这种方式很适合DevOps模型。

微服务对存储的扩展性要求更高，如何管理？有一些原则：
1、采用鸟瞰的方式进行配置和健康管理；
2、使用大数据分析来帮助用户；
3、同时支持一站式可视化的用户界面和API（自动化）。
这就需要新的分布式，可扩展的存储管理架构。
在容器时代，每个容器都共享一个OS image，这个OS image可以利用任何驱动，如轻量级的块驱动或者文件系统驱动/客户端。开发者抽取对他们应用有意义的东西和应用打包成容器，无需向后兼容。因此也就无需必须像VM环境采用虚拟的SCSI仿真方式。
VSAN未来就可以扩展支持容器应用，支持轻量级的块驱动（也许使用NVMe协议），原生文件甚至通过REST API支持对象。
文件对于容器映像的管理特别重要。VMware已经在VMWorld 2015上演示了VSAN的分布式文件系统原型，还有马上推出的重删压缩，纠删码特性。看来VSAN已经准备好迎接容器时代了。

VMware支持容器分两步走，第一步把容器功能集成到现在的vSphere环境，这种情况现在的VSAN就可以支持。最彻底就是采用全新平台Photon Platform。我想，到了这一步，也就是VSAN独立于vSphere的时候。这个时候，VSAN完全可以作为一个独立的通用SERVER SAN产品对外进行销售，和EMC ScaleIO形成直接的竞争。不过，按照进度，这个应该在DELL完成EMC收购后了。

【学习心得】
VSAN先是作为vSphere的内核紧密集成，然后慢慢发展独立出去。华为也有虚拟化产品FusionSphere和SERVER SAN产品FusionStorage，但华为的FusionStorage一开始就是一个独立的产品，并没有把它做到FusionSphere内核里面去。VSAN的发展思路，感觉VMware走了一个弯路，但其实不是这样的。全容器时代还有点遥远，目前阶段的主要部署场景还是混合场景，存储融入Hypervisor内核，还是起到管理简单，降低TCO的作用的。因此，估计华为还是需要继续在FusionSphere和FusionStorage融合上继续投入，也不一定啥时候也学习VMware开放一个类似VVOLs的接口出来，让其他国产存储厂商也更好支持FusionSphere，构造一个国产化的数据中心架构生态圈。
今天学习笔记，纯粹是学习老外的博客的个人解读。目前还没有迹象说VSAN独立销售，未来预计也只是作为其Photon平台的一部分而已，虽然VSAN在技术上独立销售没有问题，但好像没有这个动力，就像其他超融合厂商也不单独销售其存储软件一样。