【专家问答】PowerPath在Unix平台上的常见问题及处理

本帖暂时锁定，将于下周一（10月21日）活动正式开启前解锁。届时欢迎大家积极提问和参与讨论。

活动开启，贴子已解锁，欢迎大家提问和讨论。

大家好，我是Evan Gao，大家在Unix/Linux平台上使用PowerPath时，如果遇到任何问题或者有任何疑问，都可以在这里提出，我将尽力为大家解答。

下面首先为大家介绍几种标题中提到的PowerPath在使用过程中常见的问题和相应的解决思路：

• PowerPath认不到LUN或者认到LUN但是少路径的问题

这类问题也非常常见。由于在主机上PowerPath是运行在HBA之上的，所以PowerPath能看到一个LUN及其Path，必须以主机HBA能看到这个LUN和它的path为前提，因此如果发生PowerPath认不到LUN或者认到LUN但是少路径的问题，我们首先需要去确定的是主机HBA是否已经看到LUN和所有的path，每个OS厂商都会提供一下命令来作检查，如Linux底下的fdisk –l, lsscsi(可能需要单独安装)，Solaris底下的format，HP-UX下的ioscan，AIX底下的lsdev等等。EMC提供一个可以在各Unix操作系统上执行使用的小软件inquiry(inq)，用户可以从emcgrab里面的tools/bin目录下获得，也可以从下面这个FTP上下载相应的版本：

ftp://ftp.emc.com/pub/symm3000/inquiry/

软件下载后，对其添加可执行权限就可以运行来检查目前主机上看到的LUN的具体情况了(可以加-hba/-et/-btl/-sym_wwn/-clar_wwn参数，具体可以加-h或者-help查看帮助)。

这个时候，如果我们发现主机HBA都看不到LUN，就要考虑我们给主机划LUN这个操作是否有问题，或者划完LUN后在主机端的扫描操作是否正确（如AIX上的cfgmgr，HP-UX上的ioscan等等），还有就是如果是Solaris并且使用non-leadville driver的话，还需要去检查persistent-binding的配置。

在主机HBA能看到所有LUN和path后，通常在powerpath级别我们只要手动执行”powermt config”去扫描一下即可认到相应的LUN和path。

如果主机HBA能看到所有的LUN和path，但是PowerPath里面还是看不到LUN或者Path，那么可能还需要检查以下几种情况：

1. 存储是否被PowerPath管理(执行powermt display options查看存储是否在”managed”状态)，LUN是否之前被手动unmanaged过（执行powermt display unmanaged检查）以及在划LUN后是否执行过"powermt config"在PowerPath上扫描过
2. 如果是CLARiiON/VNX存储，failover mode配置是否正确。由于failover mode配置错误导致主机能看到LUN但是PowerPath看不到LUN的问题很常见，尤其是AIX系统（在AIX上，针对不同情况，failover mode需要配成3或者4）,这个时候我们需要参照EMC的文档要求在存储端把failover mode修改成正确的值，然后重启主机，这样一般情况下PowerPath就能看到LUN和path了。（关于failover mode的配置，可以参考EMC的KB文档emc99467：https://support.emc.com/kb/31521）
3. PowerPath的配置是否有错误，如AIX上的ODM软件包缺少或者安装错误（错误的版本、安装成MPIO的软件包等等情况），Solaris底下没有安装按照要求彻底关闭自带的MPxIO等等都会导致PowerPath无法管理LUN，请参考相关文档（如ODM安装包的readme文件和相关的Powerpath安装指导）进行检查。
4. 安装了不正确的PowerPath安装包也会导致该问题，所以在安装PowerPath之前请确认操作系统被PowerPath支持，从EMC官方下载相应的安装文件并按照文档要求进行安装。

如果以上这些都检查过了但是还是有问题，就需要打EMC 800找support开一个case进一步分析了。

• Powermt命令显示异常，如policy显示为BasicFailover，路径mode显示为unlic、asb:iopf等等问题

通常情况下，我们安装了powerpath并正确配置了license，所有的path都应该显示成active/alive，policy针对具体的存储型号也会为自动配置成SymmOpt/CLAROpt/Adaptive等等，如果我们在powermt display dev=all的输出中看到了Policy是BasicFailover或者path mode为unlic的话，可能是由于没有正确配置license或者license是在powerpath管理LUN以后再添加进去的。

所谓basic failover，是客户没有安装license的时候的一种故障切换（failover）的policy，它只能在一个HBA口上针对后端两个存储端口发生的故障提供切换功能，打个比方，如果客户有两个HBA口，分别连到连到了两个不同的存储端口，这个时候应该有4条path，但是只有两条是active/alive的（一个HBA口到两个后端存储口），其他的都是unlic的，即使再添加新的path，也都会显示成unlic。所谓unlic，就是没有被license的path，这种path是不能被用来做故障切换的。同时需要注意的是，basic failover这种policy下，也是没有负载均衡的功能的。

解决这种问题，首先确定license已经安装好 （可以使用powermt check_registration检查，使用emcpreg命令添加/删除license）。如果license没有问题但是还有一部分path是unlic 的，可能是由于这个path被识别的时候license还没有被安装，这个时候可以根据存储型号执行powermt set policy=co|so|ad（co=CLAROpt, so=SymmOpt, ad=Adaptive），这样policy更改的同时就会把相应的path也变成active模式了。

还有一种常见的问题就是有path显示成asb:iopf的问题，这个是某些新版本PowerPath的一个特性，asb这里的意思是auto-standby，IOPF的意思是IPs per failure，意思是如果一条路径上发生间歇性的IO错误并且平均值达到一定阀值以后，PowerPath就会认为这条path不够稳定并把这个路径置成autostandby模式，这个时候，PowerPath会优先使用其他active的path，除非没有active的path可以用了，不然PowerPath是不会使用standby的path的。

一旦客户发现有path被置成了asb:iopf，就要考虑去检查SAN环境看这条链路是否稳定了。可以通过powermt命令去关闭/开启这个autostandby功能或者修改其阀值，也可以将一条asb:iopf的路径手工置成active，具体请看powerpath文档或者下面这篇KB：

https://support.emc.com/kb/16228

• PowerPath命令(powermt)输出中发现有dead的路径

在使用PowerPath时，我们可以执行”powermt display dev=all”命令去检查所有LUN的路径(path)的状态，如果这时看到了有路径的”state”是"dead"的，那么说明PowerPath无法使用这条path来发送I/O请求并将其置为"dead"，一般情况下这都是由光纤链路问题(绝大数情况)、LUN发生改变(在存储端把这个LUN从主机移除等)或者一些其他软件问题导致。这个时候我们需要根据当时的情况进行排查，如没有对LUN和主机端进行任何的修改但发生了dead path，这个时候可能需要和交换机厂商一起去查一下交换机的情况，如zoning，端口状态等等。

在物理链路问题修复后，PowerPath会通过周期性的路径检测(path test)去自动检测那些被置为dead的path，如果发现path已经恢复，就会再次将它置为alive，这样PowerPath就可以通过该path发送I/O了，客户也可以手动执行”powermt restore”或者”powermt check”和”powermt config”去恢复或者重新扫描路径。

大家如果对以上的内容有疑问，或者有其他使用问题的话，欢迎在这里提出，谢谢！

• PowerPath报启动或者加载失败，相关命令（如powermt）无法正常执行

如果是Linux系统的话，在第一次安装PowerPath并且还没有重启主机的情况下，需要手动启动PowerPath服务（/etc/init.d/PowerPath start）去加载相应的模块和功能（重启后会自动加载，不需要再手工启动），否则powerpath命令是无法执行的，在其他Unix系统上，PowerPath会自动载入到系统内核，这个时候如果相关命令无法执行的话，通常情况下我们需要首先去检查系统的兼容性，看该系统是否被powerpath支持、是否安装了正确的powerpath版本和安装包以及安装过程是否遇到了问题，如果兼容性什么的都没有问题，可以尝试卸载并按文档要求重新安装PowerPath，如果还是有问题，就需要找EMC开case进一步分析了。

• PowerPath生成的Pseudo设备名重启后发生变化，或者设备名在cluster多节点之间不同步

在Unix上我们在对PowerPath的配置进行任何的修改之后，需要执行“powermt save”命令去保存PowerPath的最新配置(一般保存到/etc/powermt_custom或者/etc/powermt_custome.xml文件中)，主机在重启过程中PowerPath会自动执行powermt config去配置PowerPath和powermt load去载入之前保存的配置文件。如果客户对powerpath的配置做过修改但是没有进行过保存的话，就很有可能导致PowerPath载入了老的配置文件从而出现Pseudo设备名发生变化的情况（当然这里也不排除一些特定版本的powerpath在一定环境下也会发生类似问题的情况，这种情况下客户就需要找EMC开case看自己使用的PowerPath是否有该问题了），所以在对PowerPath做过修改后，请执行"powermt save"去保存最新的配置。

一般在cluster环境下，客户给每个节点分配的LUN是一样的，通常PowerPath给各个LUN分配的pseudo设备名是一样的，当然可能因为种种原因，如之前某台节点分过LUN，后来被移除后有残留的PowerPath设备文件存在等等，可能会导致cluster个节点之间的pseudo设备名不一致，从而进一步导致cluster的使用问题。针对这种情况，PowerPath自带一个命令“emcpadm”，该命令可以去手动修改一个LUN的pseudo设备名，或者更简单的把某一台节点的LUN和pseudo名的mapping关系export出来并拷贝到另外一台节点上import进去（不要手工修改该文件）。该命令具体的使用方法可以执行emcpadm help和man emcpadm参考帮助文档。

谢谢补充。

这两个命令都是shell脚本，不仅仅能收集FC有关的设备诊断信心，还能收集很多其他的信息，如主机名、uptime、model、内存信息、文件系统信息、软件信息，ioscan输出等等等等，非常有用，由于是诊断命令，输出量会非常大。

另外还有一个命令fcmsutil在HP-UX上也非常有用，在我们的排错中，一般用它也检查HBA的状态以及HBA卡认到的存储端口的状态，该命令的输出会被包含在emcgrab中。

能否来个powerpath unix configuration common examples. 这样整个专栏就更完整。

请教前辈，一般做VG的时候是应该使用powerpath生成的伪设备名还是应该使用通过OS识别出的路径呢？

hp-ux的fcddiag或tddiag很有用。其中也包跨了ioscan output.

一般来说是用伪设备名。

在一些特殊情况下，例如linux下使用lvm，需要在配置文件里加过滤器，避免系统直接使用sd*

这是一个非常好的问题，Lei Liu

EMC始终建议客户使用PowerPath生成的伪设备名(pseudo)而不是OS识别出来的路径，不管是做VG，还是用在应用上面，甚至是用来做裸设备。但是如果客户已经配置并使用了OS路径而不是伪设备名，一般也没有关系，在Linux/Solaris/HP-UX上，只要PowerPath能正常工作，它都会截获IO并实现负责均衡以及故障切换的功能，但是需要注意的是，在AIX上，我们必须使用伪设备名（hdiskpowerxxx）而不是OS路径（hdiskxxx），由于AIX操作系统的设计原因，直接发到hdisk设备上的IO不能被PowerPath截获从而进一步实现负载均衡以及故障切换。

另外，谢谢Yuan.Han的回复，在Linux下面EMC建议客户配好LVM filter (/etc/lvm/lvm.conf)，这样客户在跑pvscan,vgdisplay等等命令的时候就不会显示一些”Found duplicate PV"的报错，同时也能避免一些如PPME运行中的错误。