释放NVMe闪存的性能 –NVMe over Fabrics在Oracle RAC中的应用实测

释放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

clip_image002

而iSER,可以理解为iSCSI+RDMA,也是一种高速存储访问协议,具体的介绍可以参阅https://en.wikipedia.org/wiki/ISCSI_Extensions_for_RDMA

NVMeoF和iSER都是需要RDMA支持的,RDMA(远程内存直接访问)可以通过NIC直接访问远端主机而不需要本地的CPU参与,是实现高带宽、低延时网络的关键技术。

clip_image003

从理论上讲,虽然这次比较的两种协议都使用了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块

测试环境架构图:

clip_image005

环境搭建及测试

过程主要是以下几步:

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)
clip_image007

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)

clip_image009

测试结果

测试主要采用Oracle数据库中的DBMS_RESOURCE_MANAGER.CALIBRATE_IO工具,测试在不同情况下的跑分,以及FIO的IO跑分。测试多次,最后结果为平均值。

DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测试 IOPS:

clip_image011

DBMS_RESOURCE_MANAGER.CALIBRATE_IO 测试 MAX_MBPS:

clip_image013

FIO测试结果(8K块,详细命令行见前文):

clip_image015

从测试结果看,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。

Comments are closed.