本文内容非商业用途可无需授权转载，请务必注明作者及本微信公众号、微博 @唐僧_huangliang，以便更好地与读者互动。
本文内容要点：
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
超融合存储设计漫谈
》
《
揭秘
VDI
存储测试：
4
节点
SDS
模拟
12000
虚拟桌面
》
在上一篇评测发表之后，有朋友提到如果只用
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
注
：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。
进一步交流
技术
，
可以
加我的
QQ/
微信：
490834312
。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）
尊重知识，转载时请保留全文，并包括本行及如下二维码。感谢您的阅读和支持！《企业存储技术》微信公众号：
HL_Storage
长按二维码可直接识别关注
历史文章汇总
：
http://chuansong.me/account/huangliang_storage
