DS4000在LVM层面mirror的问题
方案:
两台DS4000,通过两台SAN交换机,交叉连接到两台P55A服务器,两台DS4000上的之间LUN在AIX LVM上建立mirror关系。
环境:
DS4700×2;P55A(HBA×2)×2;B16×2。
过程:
B16上划分zone,4700上做RAID、LUN,P55A识别一切正常。
P55A的AIX建立VG、LV、FS,将分属两台4700的LUN所对应的hdisk加入,并且做mirror,一切顺利。
测试方案:
用户提出的其中一个测试方案是在其中一台DS4700彻底下线的时候,
另一台可以立即顶上,也就是把一台DS4700关掉,或者把两根光纤全部拔掉,
通过这种方法确认LVM mirror可以保证数据的多份镜像,并且在需要的时候可以立即顶上。
测试方法:
拔光纤的同时,用time touch testfile来计算文件系统挂起时间。
问题:
在彻底断掉一个DS4700的两根光纤后,发现time touch testfile返回结果大约为15分钟,
也就是说当其中一个DS4700彻底挂掉以后,需要15分钟FS才能恢复工作。用户对这个挂起时间严重不满意,
并且表示这个时间应该是在秒级,也就是说正常使用应该是几乎没有感觉的。
分析:
内置的SCSI disk如果在LVM mirror后,拔盘测试确实可以非常快的结束挂起(但是没有掐过表),
所以这个问题应该存在FC和SCSI之间不同的地方。
可能相关的属性如下:
server1/>lsattr -El hdisk6
PR_key_value none Persistant Reserve Key Value True
max_transfer 0x100000 Maximum TRANSFER Size True
queue_depth 10 Queue Depth True
reassign_to 120 Reassign Timeout value True
reserve_policy single_path Reserve Policy True
rw_timeout 30 Read/Write Timeout value True
server1/>lsattr -El fcs0
init_link al INIT Link flags True
lg_term_dma 0x800000 Long term DMA True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
pref_alpa 0x1 Preferred AL_PA True
sw_fc_class 2 FC Class for Fabric True
server1/>lsattr -El dar0
aen_freq 600 Polled AEN frequency in seconds True
autorecovery no Autorecover after failure is corrected True
balance_freq 600 Dynamic Load Balancing frequency in seconds True
held_in_reset none Held-in-reset controller True
hlthchk_freq 600 Health check frequency in seconds True
load_balancing no Dynamic Load Balancing True
switch_retries 5 Number of times to retry failed switches True
server1/>lsattr -El fscsi0
dyntrk no Dynamic Tracking of FC Devices True
fc_err_recov delayed_fail FC Fabric Event Error RECOVERY Policy True
sw_fc_class 3 FC Class for Fabric True
server1/>lsattr -El fcs0
init_link al INIT Link flags True
lg_term_dma 0x800000 Long term DMA True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
pref_alpa 0x1 Preferred AL_PA True
sw_fc_class 2 FC Class for Fabric True
解决:
1,首先从OS中可能影响FS性能的参数下手,修改/sbin/rc.boot文件中syncd设为10。
没有效果
2,修改逻辑卷中跟mirror有直接关系的两个参数
qorume off
MWC off
3,修改fc的参数
chdev -l fscsi0 -a fc_err_recov=fast_fail
前面三步执行完后,挂起时间缩短到5分钟左右。
4,修改阵列的参数
chdev -l dar0 -a switch_retries=0
这四步完成后,挂起时间缩短到大约90秒
5,再修改其他参数也没有明显的效果。
到此,用户对我的耐性到达极点,IBM派人处理,2天后,IBM也只是能做到90秒左右的挂起时间,并且出说明函给用户。
总结:
DS4000在LVM mirror镜像可以进一步保证数据的可靠性,但是在挂起时间方面不太理想,
虽然经过调整后时间大大缩短,但是除了第一步sync的和第三步中修改fc的fast_fail以外,
其他修改可能会带来数据不一致等一些降低可靠性的问题
转载于:https://blog.51cto.com/evils798/1420838