本文内容要点：
1、 在Windows+S2D超融合上搭建Oracle RAC
2、 SwingBench压力工具的I/O和CPU负载
3、 计划内维护——虚拟机迁移测试
4、 破坏性测试1：存储节点Reset
5、 破坏性测试2：RAC+存储节点Reset
6、 Orion OLAP测试：意料中的单虚机10GB/s+带宽
接前文：《4节点近160万IOPS：SDS/超融合测试不能只看数字》
《12万邮箱ESRP测试：Exchange超融合存储设计漫谈》
在上一篇评测发表之后，有朋友提到如果只用4个节点（超融合）VDI是无法支撑1万2千个虚拟桌面的。没错，所以我们写“SDS”就是设计的计算——存储节点分离式架构。
同时我也承认，像VMware VSAN、微软S2D这种操作系统/HyperVisor内置的SDS/Server SAN，当前大多数用户采用超融合部署方式，并且节点数普遍不是太多。
能否支持Oracle RAC集群，如今对几家主流大厂的超融合方案已经不是难题了。在开始介绍本文的验证测试之前，我们再次查阅了Oracle网站上的支持信息。
http://www.oracle.com/technetwork/database/virtualizationmatrix-172995.html
Supported Virtualization and Partitioning Technologiesfor Oracle Database and RAC Product Releases
Unix, Linux, & Windows Operating Systems
截取的这个表格，只包含OS和虚拟化技术的认证，应该还不包括S2D存储功能。
与前面三篇评测相同，我们是在Windows Server 2016 DataCenter系统上搭建的微软S2D（Storage SpacesDirect）存储和Hyper-V集群。至本文截稿之日，WS 2016虚拟机+Oracle 12c R2（12.2）已经出现在甲骨文的支持列表中，早些时候还只有WS 2012的信息。因此我们也先后尝试过在2种虚拟机OS版本上安装RAC，总体上都还比较顺利。
准备工作：Oracle 12cR2 RAC搭建
虽然上图中写了VHD Set不支持Windows 10之前的（虚拟机）操作系统，但我们测试中分配给Windows Server 2012 R2的ASM磁盘是正常使用的。
需要注意的是，在S2D的CSV（集群共享卷）上创建Oracle ASM使用的磁盘镜像时，应该选择VHD Set而不是VHDX，因为这些磁盘需要同时挂载多个虚拟机到共享访问。
为不同节点上2个RAC虚拟机分配的Oracle ASM数据磁盘，分别来自Owner在多个节点上的CSV。在网络不是瓶颈的情况下（测试环境为100Gb RDMA以太网），这样做有利于性能。
上面是单个数据库虚拟机的配置信息。由于我们使用的Dell PowerEdge R630服务器上是2颗10核（20线程）CPU和128GB内存，这次就为虚拟机分配了40个虚拟处理器和64GB内存。关于磁盘（SSD）的配置情况我还会陆续交待。
注：物理Server后面的数字代表管理网口IP
为了帮助大家更好地理解，我们画了上面的示意图，其中简略了微软S2D的一些层次结构。
（1） 每个CSV上的VHD Set磁盘文件，其数据块打散分布在4台服务器上的28个SSD。
（2） 虚拟机访问数据时会经过CSV当前的Onwer节点，如果它们正好在同一节点，会享受到超融合的本地读优化。在最常用的2节点RAC方案中，为了使S2D的CSV存储开销平均分布到4个节点，我们配置了“完全互连”的磁盘组，也就是2个VM对应3-4个CSV。
（3） 在Oracle RAC安装、SwingBench与可用性（破坏）测试部分，我们使用了来自3个节点CSV的ASM磁盘；后面的Orion测试则用上了全部4个节点Onwer的CSV。
如上图，由于S2D本身已经是3副本保护，所以在创建ASM磁盘组时选择“外部冗余”就可以了。
SwingBench压力工具的I/O和CPU负载
由于本文主要目的在于可用性验证，装好Oracle RAC集群后我们几乎没有做任何调优，在SwingBench中选择了一个简单的事物开始压测。双节点的TPS（每秒交易数）有时能达到16000，TPM（每分钟交易数）超过93万。
记得我们之前在《Optane P4800X评测(2)：Oracle 170万TPM意味着什么？》一文中调优后测出有实用意义的TPS为单机13000，不过那套DellPowerEdge R830服务器是4路10核Xeon E5-4610 v4 1.8GHz CPU。另外跑的事物类型也不相同，没必要直接对比。
除了TPS/TPM我们还要关注S2D集群上的存储负载。在上述测试中两个Oracle虚拟机的IOPS请求加在一起也没有超过2万，此时的压测显然是CPU成为了瓶颈。
2台R630服务器上的CPU都跑满了，并且Xeon E5-2640v4还Turboboost到2.57GHz的频率。根据我们以前对S2D的了解，每节点的CPU至少能支撑40万以上4KB读IOPS，所以当前的压力绝大部分来自于RAC数据库。
倒不是说Oracle就不能把压力加到存储上。我们换了一个压力模型，2个节点总IOPS达到了23万（如下图）。不过此时TPS看上去并不养眼，应该是因为复杂长事物中的I/O操作较多吧。
Oracle OLTP应用的典型I/O大小就是8KB。对于超融合用户来说，可以评估下这个IOPS是否能满足自己应用的需求。
计划内维护——虚拟机迁移测试
在Oracle RAC集群正常运行的情况下，我们首先对其中一个虚拟机手动“Live Migration”到另一个节点。
Windows超融合集群上的Oracle RAC虚拟机节点，在18-19秒完成迁移。如果不是CPU满载，或者分配的内存容量较小还会更快。
我们看到TPS最低点在8000左右，此时恰好是1个Oracle数据库节点的性能。
如上图，在虚拟机迁移的瞬间TPS有个下降后很快恢复；而TPM数值统计的是过去一分钟，因而没有明显的波动。
破坏性测试1：CSV存储节点Reset
模拟破坏性测试，我们是通过Dell服务器iDRAC带外远程管理界面来操作的。
接下来就要做Windows+S2D集群的节点冷重启（Power Cycle）测试了。这里面还要分为两种情况：
（1）被重启/关机的服务器上没有Oracle RAC虚拟机，只提供S2D的存储资源，也就是其中一个CSV的Onwer。
（2）模拟故障的服务器上同时还运行RAC虚拟机。
先来看第一种情况。
由于分布式存储的冗余配置，无论多副本还是纠删码保护都应该能通过这个测试。
如上图，当组成ASM磁盘组的一个VHD Set对应CSV Onwer节点离线时，Oracle IO会hang住10多秒然后恢复，就像传统存储阵列的多路径故障切换Timeout那样，数据库连接会话不中断。S2D集群应该也有一个默认的超时设置，因为如果我们手动切换/切回（Fail over/Fail back）CSV Onwer基本上是即刻完成的。
原来Onwer在46节点的Cluster Virtual Disk，在故障后自动切换到了48节点。
等46节点重启恢复之后，我们想把CSV Onwer切回来也只是点两下鼠标的事，在这个实验中只涉及到少量数据的Rebuild，还没有触发Rebalance重平衡。
破坏性测试2：RAC+存储节点Reset
这部分的操作，会触发一个12c RAC虚拟机节点在Hyper-V故障转移集群中的另一台服务器上自动启动（HA接管）。我们记录了一下时间，WindowServer 2012 R2虚拟机OS启动只用时31秒，至故障发生后3分23秒Oracle ASM实例启动完成，5分25秒整个数据库恢复正常。
就此我咨询了一下数据库专家朋友，Oracle启动时间受版本影响比较大，我们测试的是12c（12.2），如果换成10g或者11g应该会快很多。
Orion单虚机10GB/s+带宽：别忘了100GbE RDMA
下面使用Oracle Orion I/O压力工具来测试下OLAP（数据仓库/分析型负载）存储性能。
由于带宽测试使用1MB大数据块，从S2D存储底层到虚拟机上层都不会有多大CPU的开销，这一点与IOPS测试不同。
最后我们又简单测试了一下带宽，发现只要1个虚拟机就能基本达到11GB/s顺序读的峰值。每个VHD Set磁盘建立在不同节点Onwer的CSV上，相当于用Orion模拟了ASM条带化的效果。
具体来说，就是11,007 MB/s中有大约3/4来自跨节点访问，而本次测试环境的网络比较牛（见下图），这些都不是问题。
在实际生产环境，推荐使用性价比较高的25Gb网络，同时网卡支持RDMA，双端口NIC Teaming能提供50Gb带宽，可满足高负载业务需求。
由于是2个100G网口Active-Active连接，虚拟机中的网卡速度显示为200.0 Gbps。
在顺序写测试中，我们同样遇到了SSD性能随时间下滑的正常情况。也就是说S2D集群配置的盘“还不够快”，否则在第一篇测试中也不会顺序写只达到2626MB/s。如果只是看峰值写入带宽，超过3700MB/s的情况我也见到过。
至此，本次微软S2D系列测试告一段落，感谢朋友们的大力支持！
特别鸣谢
上海维赛特网络系统有限公司副总工程师 高翔（Sean）
上海戴尔客户解决方案中心 Tony Wang
