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以外， 其他修改可能会带来数据不一致等一些降低可靠性的问题
本文出自 “O Record” 博客，请务必保留此出处http://evils798.blog.51cto.com/8983296/1420838
DS4000在LVM层面mirror的问题,布布扣,bubuko.com
原文地址：http://evils798.blog.51cto.com/8983296/1420838
