EMC PowerPath多路径控制软件的部署和最佳实践(4)

另外在support.emc.com的文档中还包括了Powerpath CLI and System Messages Reference Guide，对于其他的一些管理任务，比如伪设备名的改变，批量导入导出，通道优先级变化，以及一些故障处理技巧方面都比较有用。

后面我会分享一些Unix操作系统上最常见的现象以及解决方法。

powerpath进程后台应该有定时检测IO链路是否alive的restore操作吧？

系统繁忙时，insf -e的操作最好不要做。 保不准系统就hang了，俺这里的HPUX发生过哦

这两个功能国内应该基本没啥企业在用。

数据迁移有大把的方法，而Powerpath Migration Enabler很明显应该只能支持EMC存储之间，估摸着限制还不少。

不过这个功能用PP做还真是手到擒来，管理所有链路的IO，做同步岂不是容易得很。

说的太棒了，前段时间就因为没有注意到failover mode而吃了大亏，折腾了一个晚上。 期待最后那句的内容分享。

关于PPVE for Windows Hyper-V不是很确定，超出我的范围了...

但是查了一下\Installation and Administration Guide\，里面只提到PP/VE for Hyper-V需要一个独立的License。而没有更多的说明，所有的产品文档和软件都是放在一起的，看来只是一个许可证的区别而已。

先说说AIX吧。

想了一下，AIX上Powerpath最常见的部署问题恐怕还是在连接Clariion/VNX存储时的failover mode配置。在使用Powerpath的情况下，failover mode这个值只能配置为3或者4。3是PNR(Passive Not Ready)，4是ALUA。

大致解释一下这两个的区别：

PNR / Passive Not Ready的模式下，对于一个LUN的访问只能通过它当前所属的控制器（SP）来进行，如果通过另外一个（Passive）控制器进行读写的话，就会得到一个\Unit Not Ready\的错误，errpt里面会出现一个DISK OPERATION ERROR。对于其他的操作系统来说，这样的模式是要求failover mode配置为1的。

ALUA是非对称的访问，对于主机来说两个控制器都可以接受读写请求的，但后端处理上会不一致。这样的情况下，无论从那个控制器都不应该会看到\Unit Not Ready\的错误。

5.3及以前版本的时候，如果这个值设置为1（大部分其他操作系统的要求），Powerpath可以识别设备，但是通道切换到时候会出现问题，过程不平稳，并且errpt里面会报一堆的错误。

从5.5（或者是某个小版本）开始，如果这个值配的不正确，那么powermt display dev=all就显示不出任何的设备了。这可能是因为Powerpath软件对这个值的检查条件增强了。我们遇到过多次客户升级这个软件之后说设备都不见了，然后发现其实是一个错误配置用了很久很久...

除此之外还有一些客户在初次安装EMC ODM的时候会比较困惑，那么多的文件集选哪些个安装呢？大致总结一下：

版本： AIX 7.1 需要使用 ODM 6.0.0.0，AIX 5及AIX 6需要安装ODM 5.3.0.X 文件集：对应不同的阵列以及不同的连接类型

Powerpath -> EMC..rte & EMC...rte

MPIO -> EMC..rte & EMC..MPIO..rte

（这里的文件集名字主要是列出关键字，准确的名字在smitty里面可以看到选择。）

例如，将AIX用iSCSI连接到Clarion或者VNX阵列上，需要安装的文件集是：

Powerpath -> EMC.CLARiiON.rte

EMC.CLARiiON.iscsi.rte

MPIO -> EMC.CLARiiON.rte

EMC.CLARiiON.MPIO.iscsi.rte

想将ODM里面全部的文件集都装上是不能成功的，因为MPIO的文件集和PP的是冲突的，只能装一个。

连接Symmetrix阵列的安装过程出现问题的好像不是很常见。

我也是查看了相关文档发觉pp for WIN和PP/VE for hyper-v在安装上没差别，差别就是许可证。。 谢谢！

PowerPath使用周期性路径测试以确认路径是否能正常工作。路径测试是PowerPath通过发送一系列I/O以确认路径的可用性。如果测试失败，PowerPath关闭该路径并停止向其发送I/O。

PowerPath继续周期性地检测故障路径，以确认其是否恢复。如果路径通过测试，PowerPath将恢复对该路径的使用并重新发送I/O。在轻量负载或小型配置的情况下，路径在修复后会在一小时内自动恢复使用。对于大型配置，修复后恢复所有路径使用可能花费数小时，因为

周期性自动恢复任务被更高优先级任务抢占。路径的故障切换以及恢复流程对于应用程序来说是透明的。当路径恢复后，存储，主机，应用程序将继续保持可用性。

测试正常工作路径将花费几毫秒，测试故障路径可能花费数秒，具体取决于故障类型。 谢谢A.Y的分享，真的对我工作很有帮助哦。 Solaris

在Solaris上安装Powerpath，必须将系统自带的多路径管理软件MPxIO完全禁用。在Sparc平台上的 /kernel/drv/fp.conf 里面这个选项已经被默认禁用了：

mpxio-disable=yes

从Powerpath for Solaris 5.5开始，要求在/kernel/drv/iscsi.conf 中也要将这个选项禁用，否则Powerpath无法识别Clariion或者VNX的设备。这个配置文件一般是针对iscsi连接的，但是Powerpath在这里的要求不论是光线还是iscsi连接都必须满足。

(在Solaris 11中这两个文件的配置方法稍有不同)

另外一个很常见的问题是，如果使用了non-leadville驱动（非Solaris自带的SCSI以及HBA驱动），那么EMC要求对于SCSI设备做Persistent Binding.

Persistent Binding简单的说，就是对一个HBA能发现的存储端口指定一个Target ID，作为磁盘设备cXtYdZ中的t字母后面的编号Y。同时需要在sd.conf 中指定某一个Target编号上，系统可以配置的LUN 地址，也就是d字母后面的编号Z，同时也是分配设备时指定的Host ID (Clariion：Storage Group中的HLU，Symmetrix：map设备时指定的LUN）

Persistent Binding不做的话，操作系统有可能识别不到设备，或者每次重启之后设备的Target ID会变化，从而导致Powerpath无法配置设备。

Linux

在Linux上安装Powerpath还是比较简单的，需要注意的是

- 自带的DM-MPIO软件要禁用，比如在/etc/multipath.conf中blacklist中加入 \- 有些HBA驱动默认支持的最大LUN地址有限制，可能需要增加一些模块参数在/etc/modprobe.conf 中，或者分配设备的时候选择小一点的地址

除此之外，有一些配置，大部分客户不会去做，并且确实在大部分环境中也没见造成问题。如果遇到了Boot-from-SAN，LVM命令报警等问题，文件系统挂载等，可以从下面几点去检查一下：

- /etc/fstab

有些客户会选择在启动操作系统的时候自动挂载一些文件系统，并且要求自检。如果/etc/fstab中包括一些/dev/emcpowerX设备，那么有可能会遇到无法启动，自动进入单用户模式的情况。

这是因为在文件系统自检的时候，Powerpath的模块还没有加载，emcpowerX设备还没有生成，强制fsck通不过。在/etc/fstab中涉及到emcpowerX设备的记录中，添加上_netdev选项可以解决这个问题。

- /etc/lvm/lvm.conf

这个配置中有一个 filter 选项，用于控制LVM接受哪些设备来作为物理卷。默认的配置是所有设备都可以被接受，那么同一个LUN就会有N个sd设备加上1 …… 此处隐藏：2158字，全部文档内容请下载后查看。喜欢就下载吧 ……