释放NVMe闪存的性能 –NVMe over Fabrics在Oracle RAC中的应用实测
概述
众所周知,Oracle RAC的架构是Share Disk,共享存储的性能对系统整体表现来说至关重要,而共享存储系统性能又受多方面因素影响,其中比较重要的一点就是存储网络性能。在应用闪存的场景下,如果存储网络性能不足,再好的闪存也发挥不出威力,用一位客户的话说就是“茶壶煮饺子,有货倒不出。“,而存储网络的性能也不只是取决于硬件条件,还会受协议的影响。
我们通过实测来比较一下不同协议在Oracle数据库系统中的性能表现,本次比较的协议是NVMe over Fabrics和iSER。两种协议测试中用到服务器和网络硬件、OS、数据库软件完全一样,区别只在协议相关的软件和配置,看看结果有什么不同。
NVMe over Fabrics(简称NVMoF)是一种新的存储访问协议,相关的技术细节可以参阅:http://www.nvmexpress.org/wp-content/uploads/NVMe_Over_Fabrics.pdf。
而iSER,可以理解为iSCSI+RDMA,也是一种高速存储访问协议,具体的介绍可以参阅https://en.wikipedia.org/wiki/ISCSI_Extensions_for_RDMA。
NVMeoF和iSER都是需要RDMA支持的,RDMA(远程内存直接访问)可以通过NIC直接访问远端主机而不需要本地的CPU参与,是实现高带宽、低延时网络的关键技术。
从理论上讲,虽然这次比较的两种协议都使用了RDMA技术,但是显然NVMeoF比iSER更适合使用NVMe闪存的场景,2016年某闪存厂商使用fio测试结果,NVMeoF协议在访问远端NVMe闪存时,可以达到和本地访问一样的速度,显然iSER做不到这一点。和闪存厂商的测试不同,我们这次主要感兴趣的是在Oracle RAC系统中,两种协议的表现。
测试环境
能使用的资源有限,服务器只有3台,配置不高,好在主要看对比值。
项目 | 项目值 | 备注 |
服务器 | CPU:E5-2620 v3*1
内存:32G |
3台 |
NIC | Mellanox ConnectX-3 VPI 双口卡 | 使用以太模式,带宽为40Gb,一个端口连存储,一个端口用来做“心跳” |
OS | RedHat Enterprise Linux 7.2 | |
Oracle数据库 | 12.1.0.2 RAC | |
OFED | Mellanox OFED 3.4.2 | |
iSER Target | SCST 3.2 | |
NVMeoF Target | Linux 内核自带 | Linux 4.8.17 |
NVMe闪存卡 | Intel P750 1.2T | 2块 |
测试环境架构图:
环境搭建及测试
过程主要是以下几步:
1. 安装OS,OFED(Mellanox OFED可选,也可以使用RHEL自带的驱动及工具,Mellanox的OFED安装后会自动配置启用RDMA),过程略。安装后配置如下:
主机名 | 管理IP地址 | 存储链路IP | 备注 |
“el72h1” | 192.168.0.17 | 10.10.10.17 | 计算节点1 |
“el72h2” | 192.168.0.18 | 10.10.10.18 | 计算节点2 |
“el72h3” | 192.168.0.19 | 10.10.10.19 | 存储节点 |
两个计算节点的/etc/hosts文件内容:
# Public Network
192.168.0.17 el72h1.hthorizon.com el72h1
192.168.0.18 el72h2.hthorizon.com el72h2
# Private Interconnect
10.1.1.1 el72h1-priv.hthorizon.com el72h1-priv
10.1.1.2 el72h2-priv.hthorizon.com el72h2-priv
# Public Virtual IP (VIP) addresses
192.168.0.27 el72h1-vip.hthorizon.com el72h1-vip
192.168.0.28 el72h2-vip.hthorizon.com el72h2-vip
# Single Client Access Name (SCAN)
192.168.0.29 rac-cluster-scan.hthorizon.com rac-cluster-scan
2. 编译新内核:目前RHEL 7.2 的内核是3.10,而NVMe over Fabrics在Linux 4.8以上的内核中才有。Target端可以用Intel SPDK提供的Target程序代替,这样Target端不必升级Linux Kernel 到4.8以上,但是host(initiator)端目前好像只能用Linux 4.8以上内核才行。(如果谁知道还有别的选择,请一定告诉我)这个编译内核的步骤就不详细写了,网上都有教程。
3. 在3台机器的其中一台(el72h3)上安装SCST 3.2,安装iSCSI-SCST,过程略过,先用在这台机器上建3个10G大小的文件,
# fallocate –l 10g /home/disk01
然后用fileio的handler创建3个虚拟盘,用来存放OCR和Voting Disk,这样就可以把RAC先装起来。
SCST配置文件内容:
HANDLER vdisk_fileio {
DEVICE file1 {
filename /home/disk01
nv_cache 1
}
DEVICE file2 {
filename /home/disk02
nv_cache 1
}
DEVICE file3 {
filename /home/disk03
nv_cache 1
}
}
TARGET_DRIVER iscsi {
enabled 1
TARGET iqn.2017-10.tgt1 {
allowed_portal 10.10.10.19
QueuedCommands 128
LUN 0 file1
LUN 1 file2
LUN 2 file3
enabled 1
}
}
4. 安装RAC过程省略,存放OCR设备的DG是DATA。
5. 在el72h3配置NVMeoF Target,过程省略。如果用Linux内中中的nvmet,配置信息保存成json格式文件,内容如下:
{
“hosts”: [],
“ports”: [
{
“addr”: {
“adrfam”: “ipv4”,
“traddr”: “10.10.10.19”,
“treq”: “not specified”,
“trsvcid”: “4420”,
“trtype”: “rdma”
},
“portid”: 1,
“referrals”: [],
“subsystems”: [
“nvmet2”,
“nvmet1”
]
}
],
“subsystems”: [
{
“allowed_hosts”: [],
“attr”: {
“allow_any_host”: “1”
},
“namespaces”: [
{
“device”: {
“nguid”: “00000000-0000-0000-0000-000000000102”,
“path”: “/dev/nvme0n1”
},
“enable”: 1,
“nsid”: 1
}
],
“nqn”: “nvmet2”
},
{
“allowed_hosts”: [],
“attr”: {
“allow_any_host”: “1”
},
“namespaces”: [
{
“device”: {
“nguid”: “00000000-0000-0000-0000-000000000101”,
“path”: “/dev/nvme1n1”
},
“enable”: 1,
“nsid”: 1
}
],
“nqn”: “nvmet1”
}
]
}
如果使用intel SPDK,nvmf.conf文件内容如下:
[Global]
ReactorMask 0xffffffff
[Nvmf]
MaxQueuesPerSession 256
MaxQueueDepth 512
InCapsuleDataSize 4096
[Subsystem1]
NQN nqn.2016-06.io.spdk:cnode1
Core 3
Mode Direct
Listen RDMA 10.10.10.19:4420
NVMe 0000:10:00.0
[Subsystem2]
NQN nqn.2016-06.io.spdk:cnode2
Core 5
Mode Direct
Listen RDMA 10.10.10.19:4420
NVMe 0000:06:00.0
(安装配置SPDK的方法详见www.spdk.io)
6. Host(initiator)端连接 Target端,为了操作方便,可以先安装nvmecli,这是个开源软件,下载后编译安装。
搜索Target端:
# nvme discover –t rdma –a 10.10.10.19 –s 4420
Discovery Log Number of Records 2, Generation counter 10
=====Discovery Log Entry 0======
trtype: rdma
adrfam: ipv4
subtype: nvme subsystem
treq: not specified
portid: 1
trsvcid: 4420
subnqn: nvmet2
traddr: 10.10.10.19
rdma_prtype: unrecognized
rdma_qptype: unrecognized
rdma_cms: unrecognized
rdma_pkey: 0x0000
=====Discovery Log Entry 1======
trtype: rdma
adrfam: ipv4
subtype: nvme subsystem
treq: not specified
portid: 1
trsvcid: 4420
subnqn: nvmet1
traddr: 10.10.10.19
rdma_prtype: unrecognized
rdma_qptype: unrecognized
rdma_cms: unrecognized
rdma_pkey: 0x0000
连接Target:
[root@el72h1 disks]# nvme connect -t rdma -a 10.10.10.19 -s 4420 -n nvmet1
[root@el72h1 disks]# nvme connect -t rdma -a 10.10.10.19 -s 4420 -n nvmet2
[root@el72h1 disks]# nvme list
Node SN Model Namespace Usage Format FW Rev
—————- ——————– —————————————- ——— ————————– —————- ——–
/dev/nvme0n1 f1bb7eb3dcfdb716 Linux 1 1.20 TB / 1.20 TB 512 B + 0 B 4.8.17
/dev/nvme1n1 c57e3999e0865988 Linux 1 1.20 TB / 1.20 TB 512 B + 0 B 4.8.17
远程的NVMe设备Model是“Linux”,而FW Rev直接就是Linux的内核版本。
如果Target端用的是SPDK,使用 ”nvme list” NVMe设备信息如下,和本地查看得到的信息一样:
[root@el72h3 ~]# nvme list
Node SN Model Namespace Usage Format FW Rev
—————- ——————– —————————————- ——— ————————– —————- ——–
/dev/nvme0n1 CVCQ514600BF1P2BGN INTEL SSDPEDMW012T4 1 1.20 TB / 1.20 TB 512 B + 0 B 8EV10135
/dev/nvme1n1 CVCQ5146005Q1P2BGN INTEL SSDPEDMW012T4 1 1.20 TB / 1.20 TB 512 B + 0 B 8EV10135
7. 使用FIO测试。(NVMeoF)
# fio –rw=randread –bs=8k –numjobs=4 –iodepth=128 –runtime=60 –ioengine=libaio –direct=1 –time_based –name task1 –filename=/dev/nvme0n1
# fio –rw=randwrite –bs=8k –numjobs=4 –iodepth=128 –runtime=30 –ioengine=libaio –direct=1 –time_based –name task1 –filename=/dev/nvme0n1
8. 使用ASMCA创建磁盘组NVME,外部冗余,使用两个PCI SSD。
9. 使用DBMS_RESOURCE_MANAGER.CALIBRATE_IO测试(NVMeoF)
10. Drop DG NVME (后面的iSER的fio测试会损坏磁盘组,磁盘组删不删都一样需要重建)
11. 在el72h3使用iSCSI-SCST配置iSCSI Target(因为启用了RDMA,系统会使用isert)
12. 两个计算节点连接iSCSI target,initiator使用的是RHEL7.2自带的initiator工具
13. 使用FIO测试。(iSER)fio命令行参数和NVMeoF一样,只是filename不同,iSER会生成SCSI设备,/dev/sd[X],而NVMeoF不会生成SCSI设备,而是直接生成NVMe块设备 /dev/nvme[X]n[X]。
14. 使用ASMCA创建磁盘组DATA1,外部冗余,使用两个PCI SSD。
15. 使用DBMS_RESOURCE_MANAGER.CALIBRATE_IO测试(iSER)
测试结果
测试主要采用Oracle数据库中的DBMS_RESOURCE_MANAGER.CALIBRATE_IO工具,测试在不同情况下的跑分,以及FIO的IO跑分。测试多次,最后结果为平均值。
DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测试 IOPS:
DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测试 MAX_MBPS:
FIO测试结果(8K块,详细命令行见前文):
从测试结果看,NVMeoF的性能的确可以说是和本地访问一样,但是,如果NVMe设备多的话,会达到网络带宽上限,比如数据库内的DBMS_RESOURCE_MANAGER.CALIBRATE_IO测试,是使用2块NVMe 闪存,理论吞吐量应该还要大,4.2G的max_mbps 应该是达到存储端40GbE链路的带宽上限了。
感想及后续
l 从测试结果看,NVMe over Fabrics的确不错,我认为会有越来越多的解决方案应用这项技术,包括基于分布式存储的Oracle数据库系统。但是,要想在生产环境中应用这项技术,个人认为还有很长的路要走,还有很多问题要解决。比如:对linux内核版本要求太高,Oracle的某些功能在这样的内核版本下是不被支持的,比如ACFS。
l 在做数据库测试时,SPDK nvmf Target和Linux Kernel的 nvmet Target跑分基本没区别,但是在做fio测试时,延时情况SPDK要明显优于Linux Kernel,接近本地fio的指标。另外,从Target端CPU上占用上看,两者也有明显不同,Linux Kernel nvmet Target最高时是~80% sys,idle 15~20%,而SPDK这边最高时是~50% user,idle 45~50%。从理论上讲,SPDK是优于Linux Kernel的,从fio测试结果也证明了这一点,在我这种配置低,闪存少的测试中,两者差别不大,可能需要在更大规模的测试中,SPDK的优势才能体现得更明显。
l Swingbench或SLOB测试对系统CPU资源有一定要求,测试设备配置太低,这次没有测。
l 本次测试没有启用jumbo frames,启用以后性能还能好些。后续有时间会做这个测试。
l 如果有时间,还想对比测试一下SRP和NVMeoF。