最近同事们（包括李晓村、林舒）讨论vSAN能否支持大数据应用，受到一些启发，结合vSAN的一些用户案例，以及两年前曾做过的一次分享，整合如下。

先总结一下：vSAN能支持大数据应用。性价比好不好，要看用户的痛点或刚需。

首先，我得到的教训是，不要自我设限。用户的需求是复杂多样的，很多时候，如果能细心地和用户探讨需求，很可能找到你意想不到的vSAN的优势，刚好能解决用户的某个痛点。也有些时候，用户会比厂商更清楚技术的适用场景。比如，有一个将SAP关键应用运行在vSAN上的用户，他选择vSAN作为其存储的若干原因中，有一条是因为找不到新的物理服务器能支持老版本的操作系统了，此时选择虚拟化vSphere就顺理成章了，在POC测试中，又发现vSAN让性能提升了几十倍。

下图是我们在介绍vSAN优势时的总结：七个字 - “三高两低一自动”。当然vSAN可能不仅仅是只有这6个优势。

不是所有的用户都关心高性能，或者关心低成本，或者自动化等等，但如果细心地去了解用户的真实需求，我们或许能从六大优势，或者其他你能想到的一个或者多个优势去应对。如果都没有，那就需要去寻找其他用户了。

其次，能否支持大数据应用，要看用户如何界定什么是大数据应用。最近5、6年来，有些可能原本是BI，甚至就是一个信息化系统的项目，也可能立项为大数据的应用。

下面我们从技术的角度来剖析vSAN是否适合跑大数据应用。

提到大数据，大多数朋友首先想到Hadoop。我们先来看一下Hadoop可否跑到vSAN上？

原来我曾是坚定的反对者，理由至少有两条：

一是Hadoop有三份副本（也即总共三份数据），vSAN默认FTT=1有两份副本（也即总共两份数据）。存储利用率仅有六分之一，太低。需要注意的是，当前如果需要确保任何一个物理服务器宕机，数据还能继续访问的话，vSAN的FTT至少是1（也即两份数据）。

如果FTT=0，也即vmdk在vSAN里只是一份数据的话，还是有很小的几率（小，但是会有）出现，Hadoop虚机的三份副本存放在一台主机上（如下图的主机2），这样一旦主机2宕机，数据就不能持续访问了。如果主机2的物理盘除了故障，也有可能导致数据的丢失。

二是Hadoop本身有分布式文件系统HDFS，vSAN再多一层分布式系统vSANFS。IO路径长，延迟更长。

不过，我们惊讶的发现，不只是国外，国内我们也有少量的用户，将Hadoop运行在vSAN上。原因是：标准化购买和运维，并利用虚拟化资源池实现弹性伸缩。例如，当用户如果有需要启停某个Hadoop节点，或者增减Hadoop节点时，在虚拟化资源池上就简单方便很多。

另外，Hadoop是一个庞大的集合，除了HDFS之外，还有其他很多组件。例如Map Reduce。好了，现在如果用户将MapReduce，或者其他除了HDFS以外的组件运行在vSAN上，这样算不算vSAN支持大数据应用呢？ 我觉得，应该算。

前面提到，有些项目可能是BI（商务智能），甚至只是一个简单的三层应用，例如：

教育行业 :  选课系统、科研管理系统、校园一卡通等； 公安行业：警务综合、指挥调度；财政：电子支付、税务生产系统；

消防行业：接警、监督、管理、服务；

大多数行业：OA、财务管理、人力资源管理、客户关系管理

但是他们是按照大数据项目立项的，在这种情况下vSAN当然更适合了。

下图简单列出了一些判断的条件。我们并不积极鼓励用户将HDFS运行在vSAN上，但如果用户觉得确实需要标准化采购和运维，并利用虚拟化资源池实现弹性伸缩的话，也未尝不可。

而且，在不是很远的将来，vSAN也许会考虑将Hadoop的vmdk锁定在和Hadoop的虚机为同一台物理服务器上。这样就可以设置FTT=0，存储利用率从1/6提高到1/3，并且性能也会有所提升。

---End---

想要了解更多vSAN，可以打开如下链接：

VMware SDS 之一 ： 什么是VSAN

VMware SDS 之二 ： VSAN用在哪？

VMware SDS 之三 ： VSAN的体系结构 （含VSAN 6.0、6.1版的新内容）

VMware SDS 之四： VSAN的技术细节 （含VSAN 6.0、6.1版的新内容）

VMware刚公布第四代VSAN - 超融合软件VSAN 6.2新增了哪九大特性？ （VMware SDS之五）

VMware SDS之六:  怎么玩VSAN ?

VMware SDS之七: 谁在用VSAN ?

欢迎您通过扫描关注微信公众号：“乐生活与爱IT”。

关注后，可以通过点击左下角的“文章目录”，通过输入三位数（记住！是三位数，目前第一位是0或者1）详细了解如何查看历史文章。

点击左下角“阅读原文”，可以看到《SAP HANA跑在全闪存VSAN上？性能如何呢？》