活动主题：VMware虚拟化实施过程中的最佳实践点探讨——如何配置虚拟化平台网络

<案例分享篇>

案例分享之一：网卡绑定失误导致的业务中断案例

环境介绍：

宿主机四台，每台配置两块双口万兆网卡；接入交换机两台。网络分管理网段和业务网段，每一个网卡上的双口分别上联两个不同交换机，交换机对端口设置Trunk模式，允许任何网段通过，不需要做绑定。网卡侧需要按照交叉方式绑定四个端口为两组，分别走业务和管理，交换机不需要绑定。

问题描述：
所有虚拟化环境部署完毕，在结合业务做切换测试的过程中，开发人员报告部分业务系统不可访问。

解决过程：
第一反应，先做客户端到应用系统的Ping测试。DNS解析没有问题，但是网络不可达。
第二反应，网络可能有问题，检查客户端到目标网段的网关可达性。网关全部可达。
第三反应，问题出在接入交换机和宿主机链接上，难道发生了双点故障？于是询问运维人员设备监控情况如何？运维人员说一切正常，没有发现异常。
第四反应，什么情况？监控一点直觉没有么？再问，
问：某某机柜某某交换机有没有问题？某某机柜某某服务器有没有报警？
答：回答说，没有报警，不过....。不过什么？有一个交换机在升级firmware，属于正常停机，不在异常范围之内。
问：就一个？
答：对，就一个。
第五反应，不对啊，任何单点都不可能影响到架构的高可用啊。VC登录上去查具体的机器状态，结果所有机器处于运行状态。再次确认问题出在接入交换机和宿主机之间的链接上。于是让运维人员进入机房再查网卡以及交换机状态。报告说有一台机器的其中一个网卡的两个口全部没有上联信号。
第六反应，网卡帮错了。再查，网卡绑定顺序与其他同类型的机器顺序一样啊。查MAC对应关系，结果发现这台机器的Vmware显示的网卡顺序确实与其他机器识别达到的网卡设备名顺序不一样。当初实施工程师仅仅靠着一个样本机的网卡设备文件名与物理网口的对应关系就按照一个标准实施了。

问题总结：
对于这个案例来讲，其实高可用的设计也好，网卡绑定技术也好都不是问题。问题的关键是工程师想当然认为一种型号的机器对于IO设备文件名的识别顺序是完全一致的。其实不然，不同场合下可能设备文件名的顺序会产生不一致。幸亏这个问题是在测试阶段发生。两个教训：第一、不要想当然，用事实说话。第二、实施后的检验过程非常重要，可以救你一条命。

案例分享之二：防火墙导致的宿主机失联案例

环境介绍：
多套vmware虚拟化集群组成一个VDC，分别位于不同的安全隔离区内，VC处于一个独立的安全隔离区内，每套虚拟化集群当中有若干宿主机。也就是说宿主机和VC分别属于不同的安全隔离区，分属不同的网段。

问题描述：
虚拟化基础架构部署全部完毕，运行一致良好。突然间有一天发现其中一个安全隔离区内的宿主机有一个掉线了。还没等我来的及区调查原因，这个宿主机又恢复正常了。

解决过程：
第一反应，别的先别说，不可再现的问题，先看日志吧。结果发现其中一个宿主机掉线非常频繁，其他几个宿主机偶尔都会发生掉线现象。而且现象只发生在其中一个安全隔离区内，其他隔离区内没有此现象。
第二反应，问问应用那边，看看有没有察觉到异常。结果没有。
第三反应，那不用多想了，这个离线一定是宿主机跟VC之间的通讯断掉了，没有影响到正常的业务系统。
第四反应，看看日志，第一感觉没啥有价值的线索。为啥其他集群没事儿呢，想想这个区和其他区的区别在哪里？同一个VC，只不过分属不同的安全隔离区而已，只不过这个区属于互联网区，网络层多了几层隔离而已。
第五反应，一方面，收集日志发给厂商。另外一方面，交叉测试，于是乎，交叉换网卡，还是一个德行。交换换交换机，好像好一点，但是还会出现类似问题。
第六反应，那剩下的区别就在防火墙上了，防火墙这个区用的是莫某家的，跟其他不一样。不至于吧，虽然国产，但是也经得起推敲啊。于是把网络的运维工程师以及厂商叫过来抓包，抓了好几天，问题没有重现。等吧，Vmware那边终于给回复了，说是VC和宿主机的通讯被周期性阻断了。
第七反应，多半是防火墙上的设置，找吧。对比两家厂商的防火墙设置，终于发现了一个配置“Keep Alive”,问网络厂商是不是可以像别人家的防火墙把这个开关关掉。回答说不能。靠，为什么？回答说，产品默认设置。问曰，你们有没有在别家跟虚拟化产品配合过？回答曰，配合过，没这个问题啊。啥也别说了，升级给网络后线吧。过了几天，回复了，“Keep Alive”在防火墙上可以吧UDP的关掉，TCP的不能关掉。OK，要的就是这句话，把UDP关掉之后，观察了N天，一切OK。

问题总结：
对于这个案例来讲，更多的关注点是在虚拟化架构与其他厂商设备配合过程中的问题。一个很不经意的配置可能会引起很严重的问题。大家多多交流，上下游交流，同游交流，不仅仅知道自己的一亩三分地，也同时知道他人的一幕三分地，对于实施来讲就会带来更大的专家价值。

案例分享之三：环境变迁导致的热迁移失败案例

问题描述：
这个问题跟Vmware没有任何关系哈，首先澄清。在我们对另外一款虚拟化软件进行测试的过程中，曾经发生过这么一件有趣的事情，供大家参考。Vmotion应该算是所有虚拟化软件必备的功能，它除了要保障虚拟机能正常迁移到其他机器上，另外客户端的访问不能中断。我们在测试的过程中，可能更多的关注的是虚拟机迁移前和后的转台时候有异常，对于客户端的访问似乎多少有些忽略。一次测试过程中，我发现虚拟机正常迁移到其他的宿主机上，但是客户端访问却中断了。

解决过程：
第一反应，虚拟机迁移正常，状态正常。那么问题应该出在网络连接上，于是尝试查看网关的连通性。网关没有问题。
第二反应，回过头来想想迁移前后的变化。内存拷贝过程应该没什么问题，不然机器状态会有问题。接下来就是网络的问题，迁移之后，网卡MAC映射发生变化了。
第三反应，从虚拟机内部往外ping个包试试看，客户端访问马上通了。
第四反应，不用琢磨了，网络上的ARP没有及时更新，导致交换机不知道往哪儿送数据包。
第五反应，这个动作应该由Vmotion的软件主动通知交换机，恰恰这个虚拟化软件缺少了这个功能，或者说不够完善。

问题总结：
其实这个问题跟我们工程师的实施和运维都没有太大关系，只是在提醒更多同业者在选型和测试过程中要关注的更细节。因为对于刚刚创业或者起步的新技术或者新产品来讲，经历的考验更多的是实验室环境下的各种场合。并没有经历过真正的复杂生产环境下的考验。任何简单环境下的测试结果是有一定局限性的，我们在选型的时候要充分考虑到这一点。

案例分享之四：有一个DataStore操作失误导致的写入失败案例

问题描述：
有一个DataStore始终写入失败，报错很简单，就是写入失败。

解决过程：
第一反应，先确定是宿主机问题还是存储问题。测试其他DataStore，完全正常。那就把问题缩小到这个DataStore上来。可能是挂载或者格式化的时候出现了问题，重新来呗，结果还是一样。
第二反应，重新挂，从存储上把Lun抽回去然后再分配给主机。还是一个熊样。
第三反应，查看Vmware底层日志，看似有锁信息。
第四反应，谁加的锁呢？为什么不释放呢？
第五反应，仔细询问实施工程师，原来这个DataStore并没有从Vmwware层面进行卸载就通知存储工程师将其重新分配了。他说这么干过很多次了，重来没没有出过问题。
第六反应，不用想了，Vmare对这个Datastore加了scsi锁，这个锁加在了Lun的盘头。在非正常释放Datastore的场合下，及时存储回收了，当它再次给到Vmware的时候，盘头信息并没有消除。锁依然存在，所以无法写入。
第七反应，存储上讲该存储回收再次分配。问题消除。

问题总结：
试想，如果当时工程师按照正常的流程，把磁盘从Vmware层面进行卸载，然后存储再回收，那就不会有这个问题了。对于这个案例来讲，想告诉大家的是不要想当然，999的成功不等于1000一定成功。因为我们面对的外在环境不一定相同或者相似。所以一切操作请按照正确的流程去做。

案例分享之五：VMware虚拟机响应异常故障排查案例

问题描述：
某日，根据运维同事反映，在VMware虚拟化平台上的某系统出现严重的延迟现象，在通过操作系统登陆后，进行操作的响应时间特别长，且较之前有明显的卡顿现象。针对此问题，针对该虚拟机的运行情况进行了分析。

解决过程：
首先，想到的是排查该虚拟机所在的Esxi主机的性能，发现该主机CPU利用率在20%左右，内存利用率在40%左右，IO读写延迟不超过1ms，且该Esxi主机上面的其他虚拟机都运行正常，所以基本排除了该物理主机的问题。
接着，便在Vcenter中重点对该虚拟机的配置及日志进行检查，通过登陆Vcenter管理控制台查看该虚拟机的配置，发现该虚拟机的磁盘文件下面存在大量的-delta.vmdk文件，不同于其他普通的.vmdk文件。初步将该问题定位于此，并将该问题发送给VMware工程师，经过分析，确认是过多的delta文件直接导致了系统响应异常。
那么为什么会产生这么多delta文件？一般而言，虚拟机快照会产生delta文件，VDP备份软件也会在备份之前进行虚拟机快照从而产生delta文件。而当客户操作系统内执行一个磁盘操作时，磁盘I / O重新解析磁盘文件链中的每个delta文件。这将产生额外的主机磁盘开销，从而导致性能问题。而该虚拟机的应用系统因平时变更频繁，所以运维同时在变更前都要执行快照，且长时间没有将快照删除

问题总结：
经过该问题的出现，日后在VMware化平台的维护中特别注意将重复快照的删除，否则时间久了，且存在大量的快照会影响虚拟机的性能。同时，要定期通过SSH登陆到ESXi服务器，查找是否有delta文件产生。如果文件数量过多的话可能导致更为严重的无法连接的错误，需要及时解决。

<问答环节篇>

1 数据库与虚拟化的关系

相关问题：
Q1：vmware 对 oracle rac是否有好的支持？
Q2：VMware 平台搭建的网络虚拟化环境，适合oracle rac环境吗？
Q3：vmware虚拟化后，能把以前的数据库迁移进来吗？
Q4：VMware共享存储问题？

回答提炼：
这个问题个人觉得应该分为两个方面来看。
第一，就功能层面而言。回答是肯定的，ORACLE RAC完全能够部署于虚拟化平台之上。心跳网和业务网可以通过网卡绑定不同VLAN的端口组实现。共享存储可以通过RDM或者是ISCSI方式实现。针对虚拟化环境上的RAC也会有一系列优化配置，例如：
1 将内存预留容量设置为与数据库内存（SGA+PGA）相同的大小。
2 使用大内存页。(默认)
3 启用处理器的超线程功能。
4 使用 Oracle 自动存储管理 (ASM)。
5 使用 RDM 映射。
6 使用 VMXNET3系列半虚拟化网络适配器。
7 管理网络和业务网络分离。
第二，就性能层面而言。回答是需要根据应用负载及并发量来看的。小的应用，可以搬上来运行着看。大的应用建议不要搬上来。如果数据库本身的负载很高，并发量很大，还是不建议把数据库搬到虚拟化上来。物理机器都吃不消还非得搬到虚拟化上，性能肯定会有问题。实在想迁的话建议一些小的数据库迁移上来。如果仅仅是考虑DB的灵活性，不妨试试ORACELE11G的Server Pool特性或者是ORACLE 12C的PDB特性。

2 虚拟化网络相关配置上如何优化配置

相关问题：
Q1：vmware 在做网络虚拟化时，如何规划？有哪些注意事项？
Q2：端口组以及网卡的参数有没有最佳实践？
Q3：VMOTION FT等网络如何规划？网口bond时物理交换机如何配置？
Q4：网络虚拟化的过程需要特别注意什么细节问题？
Q5：mware桌面虚拟化环境网络如何规划？

回答提炼：
A1：
从规划上来讲，需要注意以下几个部分：
1 网络高可用。包括网卡、物理节点、物理交换机等资源的冗余交叉设计，保证任何单点故障都不会影响业务功能。这里面涉及到数目的搭配，链路设计，策略选择等。
2 管理网络和业务网络隔离，业务网络再通过端口组隔离。业务网络用分布式交换机，管理网络用标准式交换机。合理评估管理和业务的带宽设置。
3 交换机、端口组、网卡上的参数配置及策略选择。

就配置细节上讲，需要注意以下内容的配置优化：
1 交换机上开TRUNK模式。
2 网卡无论怎么绑定，交换机上都不需要做特殊捆绑。
3 网卡负载均衡模式选择端口路由方式，虽然不是绝对的负载均衡，但是是相对安全可靠的绑定方式。
4 安全模式没有特殊要求保持Reject。
5 选择合适的MTU，尤其对于数据库应用。

A2：
从设计上来说.要做到虚拟可用.物理冗余。虚拟可用就是虚拟层面.可以提供给虚拟层以上的Guest OS或应用网路连通性物理冗余就是在物理层面要避免单一物理连路断开后.引起上层的网络不可连通.
一、物理层面：
原则:连路的冗余:包括线路冗余,板卡冗余,芯片冗余.
从VC管理上.我们可以使用低速率的网卡.比如主板自带的网卡.为了保证冗余性.可以与PCI网卡做冗余.
4/5的高速率卡.我们要用做真正的生产业务.比如NFS的网络连接.用于VM存储和关键业务的保护机制的使用.(vmtotion或FT等)
这样.我们在现有的设备中.就做到了管理网络的冗余(使用不同芯片低速网卡),生产网络冗余(使用不同PCI上高速网卡.)
二、虚拟层面:
原则:网络可达.速率最大化
管理网络使用物理网卡做冗余vmnic0/2,在使用上管理网络不会有太多的数据流量.可以选择网卡的绑定类型为主备(active-standby)模式就可以.
VMkernel网络.这个虚似网络是很重要的网络.在做FT功能和虚机的VMOTION的时候很关键.会最小程度影响在线业务.可以使用AS模式或IP-HASH模式.Customer Network.这里是虽然用于了两个不同板卡上的1G网卡. 但从业务情况上来看.1G网络会成生VM用于生产环境的瓶颈.这个地方的设计是不合理的.
如果是在现有的情况下设计.我们可以做以下改进
1.可以再配两块10G网卡做物理冗余.来承载业务网流量.
2.把vmkernel网络和Customer network都合在一起,然后使用.
3.退而求其次,我们可以把Customer Network和vmkernel物理网卡交换.这种场景用于VMOTION不常使用,FT功能开启数量极少.
在VSS或VDS中.对物理网卡的绑定有多种.但常用的有主备模式.和IP HASH模式(交换机支持并要做一定的设置).

3 关于VLAN

相关问题：
Q1：VMware ESX/ESXi网络中vlan实现方式有哪些？请详细描述及应用场景？
Q2：vmware虚拟网络端口组中关于逻辑VLAN是如何与物理背板交换机映射的？
Q3：VMWARE 虚拟化的VLAN的使用建议？
Q4：vmware网络虚拟化实现的原理是什么，可以具体解释一下吗？

回答提炼：
A1：
不管是在虚拟化环境还是在物理网络环境，VLAN都是必不可少的。它可以实现网络隔离，也就是根据VLAN区分出不同的网段。交换机上的安全规则也是基于VLAN来区分的。如果不用VLAN，那么网络就无法实现逻辑隔离。比如你的办公业务和你的生产业务，比如说你的数据库网关和APP网段，比如说你的外联网段和你的互联网段等等。

具体操作，物理交换机上打的实实在在的VLAN标签，并且配置成TRUNK模式。网卡连接到物理交换机上。把物理网卡添加到虚拟交换机里面，然后创建不同的端口组，并且把端口组的VLAN标签按照交换机允许通过的VLAN打上Vlan号。虚拟机的网卡捆绑到某个端口组上，实际的网络流量就会通过物理网卡、交换机等出去。虽然虚拟机网络划分为不同的网段，来自不同的端口组配置，但是都是通过同样的物理网卡把数据包送到网络交换机实现网络交换。

A2：
vmware虚拟机交换机支持csico发现协议cdp，通过在物理交换机上配置为trunk模式，vmware是虚拟交换机上就能发现vlan标签，当然就识别了。
搞的方式：
1 vmware主机上联交换起trunk，vmware本身支持cisco发现协议，可以发现相关vlan id，在vmware虚拟交换机上配置相应的vlan id即可。
2 傻瓜式使用方法，就是上联交换机就一个vlan，下连主机也不用考虑vlan情况，插上就那个段用就行了。

A3：
VLAN是网络隔离，广播包只在同一个VLAN内，在二层上, 不同VLAN无法通信。
在二层加入了VLAN TAG.是和完整的二层传输帧是一样的.和交换机上配置了VLAN的感觉是一样一样的。

4 虚拟化平台的高可用以及资源调度

相关问题：
Q1：VMware的虚拟化平台网络可以做到类似F5的负载均衡吗？
Q2：vsphere FT的网络要求？
Q3：vmware容灾体系设计？
Q4：VMware网络虚拟化平台的高可用性如何保证？
Q5：VM虚拟化在系统层面及物理层面的安全性如何保证？也需要双机热备么?
Q6：vmware drs开启问题？

回答提炼：
A1:
对于计算节点高可用来讲，除了在资源数量上要保证其冗余性之外，策略设置也非常重要。可以参考以下几个点：
1 Admission Control Policy：对于生产环境来讲，一般认为选择（Host Failure the cluster tolerates =1）比较合适，当然如果你的资源非常空闲，可以适当调大。
2 对于每一台物理机上的虚拟机根据其重要程度不同，设置其启动的优先级（高中低）。
3 当一台物理机上的虚拟机远超过集群当中的物理机数量时，可以考虑设置虚拟机HA互斥分离规则。
4 生产环境当中尽量把DRS的策略设置的不要太激进。尤其是前段具有负载均衡设备的时候建议把DRS打成建议模式。

对于存储来讲，必须保证集群内所有节点看到的外部存储视图是一样的，完全共享的，才能很好保证其HA及DRS功能。另外说到存储，有以下几个点：
1 卷属性里面，把Storage IO Control 选项Disable。不建议vwmare层干预底层IO，反而有尤其性能故障的风险。
2 将卷的多路劲策略设置为（Round Robin）。

A2:
对于DRS来讲，建议，可以采用半自动化，激进的情况下可以全自动下阀值设置为保守，先观察一段时间看看。

A3：
对于FT，由于FT是通过vLockstep技术确保虚拟机处于同步状态，因此带宽最好比较大，最低1Gb/s，最好用10Gb/s，并且做网卡绑定;

A3：
VMware提供了VMware HA和FT两种高可用，但只能做到esxi主机级别的故障监测和恢复。一般会从应用级别上来做高可用，根据不同的业务角色，使用相应的群集或负载均衡，对于后端数据库角色，一般会部署在物理机上，如果非要在虚拟机上可以考虑veritas公司的infoscale系列中的群集软件（原vcs），可以与VMware的vmotion和其他管理手段有联动，也可以不需要裸设备等支持来避免脑裂，还支持不同优先级的应用按指定顺序启停。同类群集基本只能做到基础的功能。

5 关于虚拟化资源迁移

相关问题：
Q1：关于迁移exchange邮件服务器？
Q2：如何将VMWARE配置好的环境，完整迁移到物理机器，不用重做系统与配置？
Q3: vmware在做p2v迁移配置中，如何提高迁移的成功率？
Q4: VMWARE 跨数据中心在线迁移解决方案?
Q5: 云环境下的vmware虚拟机迁移问题？

回答提炼：
对于V2P，
通过VMWARE转换工具，将物理机器应用环境转成VMWARE镜像，导入到ESXI里。就不知，经过几年，VMWARE的研发工程g师，有没有开发出类似工具，将在虚拟机配置好的，测试好的应用业务环境，迁移到物理机器上面，其实，个人觉得这个也是有前景的。因为，工程师出于谨慎，为了不破坏机器环境，会习惯在虚拟机配好，测试好应用环境后，才在物理机器搭建环境，但有时，不想再花时间，重新配置一次，测试一次环境，就会倾向于将应用环境从虚拟机迁移到物理机器。迁移完，只需改一下IP就行。CPU ,内存，主机设置也不需再配置。

对于P2V，
参考converter来做P2V.
1.网络要通信好
2.物理机的OS要启动.一般物理机都是跑业务的.比如DB之类的.要停掉业务.使用使系统处于基本静止的状态去做转化.

对于Vmotion以及跨地域的Vmotion，
跨数据中心在线迁移是个大的解决方案，要想实现在线迁移，基础架构当中以下几点是需要要考虑的：
1 网络上要实现2层打通，否则没法Vmotion到灾备中心。
2 存储是否要实现跨数据中心共享。否则VMDK很难无缝热迁移。
3 上层的网络架构要能正确实现引流，否则机器迁移过去了，客户端访问引不过去。
以上每一件事情都是个巨大的工程，牵涉到各个方面的集成配置和科学设计。

6 关于虚拟机资源性能优化

相关问题：
Q1：如何评估一台vmware虚拟机的性能？
Q2：虚拟化资源如何合理分配？
Q3：如何根据不同业务需求，规划分配一台vmware虚拟机？？
Q4： 在现实的环境上，大多数都很关心服务器的性能，在使用虚拟机的过程中如何保证虚拟的系统性能达到真实物理机的性能？?

回答提炼：
关于性能评估，
我们一般采用压测对比方式。测试网络和IO都会有很多开源的工具（iperf,iometer等等），和测试一般Linux系统没什么区别，只不过需要调整虚拟机的各种CPU、内存设置策略对比着测试看。如果要部署应用的话，还得需要依靠应用的压力测试来看。要不然就根据自己的业务需求开发集成一套自己的测试工具。

关于规划使用，
1、提前评估应用的资源使用量以及一段时间内扩容的量，否则两眼一抹黑，客户要多少就给多少，很容易不够；
2、统计应用已用资源使用量，尽量不超配太多；
3、看看是否有对虚拟机做了资源预留，是否有必要，这个很容易浪费空闲资源；

关于资源配置，
这个过程大致会分为：1 根据合适的模板部署虚拟机。2 分配合理的CPU、内存、网卡资源。3 根据具体应用特点调整合理的参数设置。
在模板这块儿，可以根据自己的应用特点部署一个相对通用的基础模板，比如说Linux6.6 + Weblogic。可以把中间件以及操作系统的通用参数设置好部署成模板，当然这个也可以通过后台脚本的方式将其部署为动态模板组合方式。在硬资源的分配方面完全是要靠对应用的了解和运维经验了。没法儿固定。在后期模板无法解决的参数调整方面，可以根据具体环境参数修改虚拟机的某几个位置上的参数，同样可以实现脚本化。用Python或是Expect很容易实现交互式批量任务。

关于科学计算的话，
数据库服务器处理能力分析,根据工程设计规范中的主机处理能力公式：
主机处理能力（TPMC）按下列公式计算：
P──主机处理能力，单位为每分钟处理的交易量（TPMC）； ──预测近期年的日均交易量，单位为笔，取日均交易量的1.5倍； ──忙日集中系数，一般取2～4，取4； ──忙时集中系数，一般取0.2～0.25，取0.25； K1──平均交易复杂度，一般取4～10，取10； J1──主机处理能力保留系数，取0.7。

7 与平台技术选型相关

相关问题：
Q1：vmware现在这么贵前景如何？
Q2：VMWare虚拟化平台与FasionComputer虚拟化之间各自的优缺点是什么？
Q3：vsan和当前炒的比较火热的超融合区别？
Q4：IBM+VMware虚拟化实施过程比微软、华为、思科等虚拟化构建上有哪些优势？

回答提炼：
产品的比较还得自己亲自去体验，可以提供几个建议的比较方向：
1 从产品功能点上来讲，其实很多IAAS厂商的产品基本没有大的差异。
2 从产品的性能上来讲，几个产品的差异就会很明显的显现出来。比如说IO的性能，计算资源的性能，备份速度的差异等等。具体数字还得自己去比较。
3 从产品功能的稳定性上来讲，也会有很大差异，有的产品是经历了各种复杂网络及存储环境考验，修复了各种BUG才走到今天的成熟产品。有的产品可能经历的考验还比较少，在面对复杂网络环境和存储环境的时候不免会出现一些诡异的事情。需要反复测试，在不同的环境反复测试。
4 从产品的兼容性和扩展性上来讲，要看其对相关环境资源的兼容性如何，接口如何等。

就虚拟化具体POC测试的细节，以下几个细节测试值得注意：
1 复杂网络环境下的Vmotion、HA、DRS功能测试。
2 内存复用功能的反复压力测试。
3 虚拟机的性能测试。
4 备份恢复功能和性能的测试。
相信做完以上测试，会有一个清晰的结论。

其实个人感觉超融合本身会包含类似VSAN这样的软件定义存储技术。每一家的超融合产品都会有计算虚拟化、存储软件定义、网络虚拟化等等这方面的东西。但是就存储的软件定义而言，各家会有一些区别：
1 有的可以在计算节点IO下沉之前做到数据的压缩。
2 有的可以直接用闪盘做缓存。
3 有的利用infiniband可以实现系统内的超高带宽，尤其适合数据库。
4 有的在存储侧实现数据复制是以块儿为单位的，有的是对象存储复制。
5 有的是把存储的软件层做到每一个节点的系统层，有的需要依赖单独的虚拟机。
总之各有各的亮点。VSAN目前是被集成到了EMC的超融合产品VXrail里面了，而且有所改进。