VMware一直在推动把关键业务也跑到VMware VM上。VMware说，他们支持目前的主流数据库，包括Oracle。

根据Oracle的官方声明，Oracle不喜欢用户跑在VMware VM上。如果用户非要用，出了问题怎么办?Oralce说，是自己的问题会解决，但如果是VMware的问题，就不管了。特别针对ORACLE RAC，ORACLE明显说明没有义务支持。

由于支持扯皮的问题，大部分的用户都没有把ORACLE应用虚拟化，特别是金融的客户。还有虚拟化后，性能肯定下降一些，本来一台物理服务器性能就不够。加上ORACLE的License按照物理CPU收费的，要充分利用CPU的资源。

但也有很多VMware的粉丝把Oracle跑在VM上，特别是很多企业的开发测试环境。因为VM的部署更灵活，运维也更方便。少数企业也把ORACLE应用虚拟化用在生产环境上，因为不是所有的数据库都要求很高的性能，或者不是一直要求在峰值运行。

为了推广VMware VSAN，近日VMware在其Blog公布了ORACLE跑在VSAN上的一些测试结果，我们简单来看看。

介绍一下测试环境，VMware用了全闪存的VSAN配置：

Four Intel S2600WT2 systems were used, each with 2 x ES-2699 v3 processors @ 2.3 GHz, 18 cores per socket and 128 GB of RAM.

A 400 GB Intel DCS3700 PCIe flash card was used for caching in each server, complemented by 3 480 GB Intel DCS3500 SATA SSDs used for capacity.

Oracle 11.2.0 RAC was used, running on vSphere 6 on Oracle Linux Server.

首先测试单实例的性能。VMware说没有进行调优，测试结果还不错，平均每分钟7万笔左右的交易。

然后VMware测试了4个节点RAC的性能表现，可以做到每分钟40万笔交易，大约是4倍单实例性能的93%。而且时延只有12ms，这个是从应用层面看的，还算不错。

VMware还一个节点一点节点增加，看性能的变化曲线。测试发现性能几乎是线性增长的。

然后，VMware测试计划停机，即vMotion的表现。在4节点RAC的环境下，把一个节点迁移到另外一个物理机上的时间。

测试结果还不错，19秒就可以把完成vMotion，还是很快的。

但如果是非计划宕机呢?还是在4节点的RAC环境下，VMware模拟一个节点掉电，132s后，另外一台VM起来，然后再花了119s，掉电的实例恢复正常。整个过程大约需要4分多钟时间。

我们看到，VMware VSAN和ORACLE RAC确实可以协调工作，而且性能也还不错。但全闪存配置，应该成本也不低。加上出了问题ORACLE不一定支持，你愿意为了VM的灵活性而采取这种方案吗?