这两天一直在测试IBM OpenPower上运行RedFlag DC5.0 for pSeries是不是能够正常连接EMCCLARiiON CX系列存储。同时也测试了基于device-mapper的device-mapper-multipath工具。具体的技术细节，大家可以看相关的连接。
下面是我的测试手记，大家look一下：
测试目的：
测试在 OpenPower环境下，通过红旗DC5.0连接上EMC CX存储，并使用系统自带device-mapper-multipath软件来测试多路径的冗余和负载均衡功能，以保证用户数据的高可用性和高可靠性。
测试方法：
为了保证用户数据的可用性和可靠性，测试方法如下：
1.可用性测试：OpenPower通过光纤交换机与EMC存储正确连接，并能在OpenPower上的红旗Linux正确识别，正确读写数据。
2.可靠性测试：通过MPIO（MultiPath IO,即多路径IO)，对EMC 存储进行数据读写，以获取相关IO传输状态的数据。并且，在数据读写过程中，分别拔掉光纤线和连接EMC 存储的当前活动控制器的光纤线，造成路径失败，以考察路径切换性能，随后再重新接入光纤线，以考察路径“愈合”性能。
测试结果
通过一天紧张的测试，达到本次测试预期目标，测试成功。
在OpenPower机型上，使用红旗Linux系统，能够做到：
1.正确访问EMC CX存储。
2.通过使用系统自带的device-mapper-multipath软件，能够以负载均衡的方案访问EMC CX存储。
3.当一条光纤或者EMC CX存储的单个控制器失效时，系统自动切换路径，并能持续读写存储设备，保证数据的可靠性。
测试环境：
服务器：OpenPower 710 (1CPU/1G Mem/73.4G)
光纤卡： Emulex lp10000 HBA卡两块
交换机：Brocade 2400 一台,McData 140M一台
存储： EMC CX500 Realease 19 (双控制器)
操作系统：RedFlag DC 5.0 for IBM pSeries
测试步骤
1.部署测试环境，主机上两块Emulex光线卡连接到光纤交换机，通过光纤交换机再连接到EMC CX存储，形成SAN拓扑结构。并划分1个100G的LUN分配给主机。
2.主机安装操作系统（测试前准备），安装最新版的device-mapper-multipath软件包。
通过device-mapper-multipath用户工具来验证多路径的负载均衡及路径失效切换功能：
使用fdisk命令能看到系统识别出来的4个磁盘设备,这是多条路径得到的设备名，实际上指向存储上的同一个LUN，这说明红旗操作系统已经正确识别到了EMC CX存储划分出来的LUN，并为下一步多路径管理作准备。命令及输出如下：
#fdisk -l
Disk /dev/sdf: 103 GB, 107374182400 bytes
64 heads, 32 sectors/track, 102400 cylinders
Units = cylinders of 2048 0* 512 = 107374182400 bytes
Disk /dev/sdf doesn't contain a valid partition table
Disk /dev/sdh: 103 GB, 107374182400 bytes
64 heads, 32 sectors/track, 102400 cylinders
Units = cylinders of 2048 0* 512 = 107374182400 bytes
Disk /dev/sdh doesn't contain a valid partition table
Disk /dev/sdj: 103 GB, 107374182400 bytes
64 heads, 32 sectors/track, 102400 cylinders
Units = cylinders of 2048 0* 512 = 107374182400 bytes
Disk /dev/sdj doesn't contain a valid partition table
Disk /dev/sdl: 103 GB, 107374182400 bytes
64 heads, 32 sectors/track, 102400 cylinders
Units = cylinders of 2048 0* 512 = 107374182400 bytes
Disk /dev/sdl doesn't contain a valid partition table
实际上这4个设备对应的是一个LUN，只是通过不同的路径看到的。
3.启动多路径管理软件
# modprobe dm-multipath （加载dm-multipath内核模块）
说明：系统启动时缺省地不加载这个模块。如果应用部署需要，可以在系统启动时定制。
# /etc/init.d/multipathd start （启动multipath daemon服务）
# multipath –v3 （装配多路径设备）
# multipath -ll （显示当前多路径拓扑结构）
3600601604b991100f4e5b5c83ef5da11
[features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 1:0:2:1 sdf 8:80 [ready ][active]
\_ 2:0:1:1 sdl 8:176 [ready ][active]
\_ round-robin 0 [enabled]
\_ 1:0:3:1 sdh 8:112 [ready ][active]
\_ 2:0:0:1 sdj 8:144 [ready ][active]
这里的设备被分成了两组，实际上就是通过两个控制器看到的设备，其中一组的状态为[active]，表示这是当前的活动控制器。接下来的对设备的读写都会通过该控制器下的/dev/sdf和/dev/sdl来进行操作。而只有当[active]控制器发生了故障或者执行了Tresspass后才会启用目前处于[enabled]状态的控制器下面的设备/dev/sdh,/dev/sdj。后面的测试会来证实这点。
4.在EMC CX存储上创建测试需要的分区
#pvcreate /dev/dm-0 ( 创建物理卷）
#vgcreate vgtest /dev/dm-0 （创建一个卷组）
Volume group "vgtest" successfully created
#lvcreate -L+50G -n lvtest1 vgtest
Logical volume "lvtest1" created
5.负载均衡测试
使用dd命令来对设备进行写操作，并同时通过iostat来查看I／0状态，命令及输出如下：
#dd if=/dev/zero of=/dev/vgtest/lvtest1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 3.47 48.51 47.52
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
sdf 756.57 6044.44 0.00 5984 0
sdh 0.00 0.00 0.00 0 0
sdj 0.00 0.00 0.00 0 0
sdl 334.34 2682.83 0.00 2656 0
通过上述输出，我们看到，在对/dev/vgtest/lvtest1读写时，实际上是通过对/dev/md-0包含的当前active的所有设备，即/dev/sdf,/dev/sdl这2条路径来完成对实际的LUN的写过程。
6.路径切换测试
首先，我们拔掉服务器上A口的光纤线，经过不到10秒，我们看到：MPIO成功地从上述“失败”的路径/dev/sdl切换到了另外一条路径/dev/sdf上。其输出样本如下：
＃iostat 1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 6.47 46.77 46.27
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.98 0.00 7.84 0 8
sdf 1709.80 13678.43 0.00 13952 0
sdh 0.00 0.00 0.00 0 0
sdj 0.00 0.00 0.00 0 0
sdl 0.00 0.00 0.00 0 0
接着，我们重新接入光纤线，这次也是不到10秒（此值可以设置），验证了路径“愈合”。其输出样本如下：
＃iostat 1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 3.48 48.76 47.26
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
sdf 504.00 4024.00 0.00 4024 0
sdh 0.00 0.00 0.00 0 0
sdj 0.00 0.00 0.00 0 0
sdl 594.00 4760.00 0.00 4760 0
同样的测试结果可以在服务器上另外一块光纤卡上重现。
7.控制器切换测试
使用同样的方法，拔掉目前处于Active的EMC CX存储控制器上的一根光纤线，能够看到下面的输出：
#iostat 1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 6.47 46.77 46.27
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.98 0.00 7.84 0 8
sdf 1609.80 13670.2 0.00 14972 0
sdh 0.00 0.00 0.00 0 0
sdj 0.00 0.00 0.00 0 0
sdl 0.00 0.00 0.00 0 0
从输出结果能够看出，路径也从失效的/dev/sdl切换到了/dev/sdf，和把掉一根连接到服务器上的光纤线上是同样的效果。
接下来，我们重新插入光纤，不到10秒种，我们可以看到下面的输出信息
#iostat 1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 3.48 48.76 47.26
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
sdf 504.00 4024.00 0.00 4024 0
sdh 0.00 0.00 0.00 0 0
sdj 0.00 0.00 0.00 0 0
sdl 594.00 4760.00 0.00 4760 0
这表明路径已经成功的愈合了。
最后，我们同时拔掉目前处于active状态的控制器连接的光纤。大约10秒钟后，输出的信息如下：
＃iostat 1
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 7.50 46.00 46.00
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
sdf 0.00 0.00 0.00 0 0
sdh 1910.00 15264.00 1552.00 15264 1552
sdj 149.00 976.00 15024.00 976 15024
sdl 0.00 0.00 0.00 0 0
同时查看CX300的信息，发现CX300已经成功的执行了Tresspass，而这个功能的实现是通过系统自带的dm-emc.ko内核模块来触发CX300来执行的，这点和EMC的PowerPath软件达到的目的基本一致。
同样的测试结果可以在第二个控制器上重现。
测试结论
根据以上的测试步骤和输出信息，能够得到以下结论：
在OpenPower机型上，安装红旗Linux DC 5.0 系统，连接EMC CX存储，可以保证以下几点：
1.红旗Linux操作系统能够正确访问EMC CX存储设备，并能正确使用。
2.通过使用红旗Linux系统自带的device-mapper-multipath软件，能够以负载均衡的MPIO方案访问EMC CX存储设备。
3.当一条光纤或者EMC CX存储的单个控制器失效时，系统自动切换路径，并能持续读写存储设备，保证数据的可靠性。
