释放NVMe闪存的性能 nvme闪存速度

释放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台，配置不高，好在主要看对比值。

测试环境架构图：

三、环境搭建及测试

过程主要是以下几步：

1.安装OS，OFED（Mellanox OFED可选，也可以使用RHEL自带的驱动及工具，Mellanox的OFED安装后会自动配置启用RDMA），过程略。安装后配置如下：

两个计算节点的/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链路的带宽上限了。

五、感想及后续

• 从测试结果看，NVMe over Fabrics的确不错，我认为会有越来越多的解决方案应用这项技术，包括基于分布式存储的Oracle数据库系统。但是，要想在生产环境中应用这项技术，个人认为还有很长的路要走，还有很多问题要解决。比如：对linux内核版本要求太高，Oracle的某些功能在这样的内核版本下是不被支持的，比如ACFS。

• 在做数据库测试时，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的优势才能体现得更明显。

• Swingbench或SLOB测试对系统CPU资源有一定要求，测试设备配置太低，这次没有测。

• 本次测试没有启用jumbo frames，启用以后性能还能好些。后续有时间会做这个测试。

• 如果有时间，还想对比测试一下SRP和NVMeoF。