DS4000在LVM层面mirror的问题

taoy_2008

http://wenku.baidu.com/view/2983ebd4360cba1aa811daf1.html  DS4000做LVM Mirror

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以外，其他修改可能会带来数据不一致等一些降低可靠性的问题。

感谢：
   在这个问题的处理过程中，wildhorse和orain两位老大给了我很多建议，特此感谢。

kgdvoso

午夜幽魂

学习学习

InfoSVC

好东东
支持

aib

现在新的，都是MPIO了吧~

胖胖猪

我测试两台DS5020的lvm，确实很慢，谢谢LZ的分享

emperor

问下lz
autorecovery      no               Autorecover after failure is corrected               True
dyntrk              no                Dynamic Tracking of FC Devices                       True
这个参数有改过吗。。。。。。

xiaofeixxds

ericyan_cu

LVM mirror 性能岂不是太差。。。

月光下的幽灵谷

！！！！！！！！！！！！！！！！！！！！！！！！！！