emcpowerpath多路径控制软件的部署和最佳实践 1.docx
《emcpowerpath多路径控制软件的部署和最佳实践 1.docx》由会员分享,可在线阅读,更多相关《emcpowerpath多路径控制软件的部署和最佳实践 1.docx(14页珍藏版)》请在冰豆网上搜索。
emcpowerpath多路径控制软件的部署和最佳实践1
EMCPowerPath多路径控制软件的部署和最佳实践
好消息,EMC中文论坛里新一期的“专家问答”活动已开启。
EMCPowerPath一款常用于在各类主机和存储系统间进行多路径控制、管理和优化的软件,实现负载均衡和故障切换。
从12月10日(周一)开始为期两周的时间里,我们将和大家一起讨论和分享有关EMCPowerPath多路径控制软件的部署和最佳实践 的话题和心得。
以往所有已完成的“专家问答”活动可参考这个汇总贴。
沙发,哈
请问powerpath最多只可以做两条冗余的路径吗?
应该是每个逻辑单元(LUN)最多可以支持32个通道(Path),但是随着通道数量的增加,Powerpath需要消耗的系统资源也会随之增加。
因此综合考虑冗余和计算性能的话,很少有用户会配置如此多数量的通道。
谢谢偶这边是配置两路的一般运作的时候是负载均衡的吗?
还是只是用一路主的另外的备用呢?
Powerpath会自动的做负载均衡。
但需要注意的是,负载均衡不等于RoundRobin算法,虽然这也是选择之一。
Powerpath的负载均衡的考虑因素要复杂很多,不仅有I/O数量,还有I/O大小,队列深度,响应时间,等等,Powerpath会对每个I/O请求选择一条最优的通道,即使和上一个I/O请求是同一个。
powerpath在vmware上需不需要安装,谢谢,貌似vmware自带多路径软件!
!
!
VMware对存储的管理是通过ESX来实现的。
ESX的VMKernel有自带的故障切换和多路径管理,但仍然可以安装PowerPath/VE以实现ESX所连接存储的特有属性。
在VMWare(ESX以及ESXi)上的Powerpath软件为Powerpath/VE,具体的安装方法是不一样的。
并且管理工具(rpowermt)和许可证的管理方式也不同。
Powerpath/VE的管理由rpowermt命令控制,这个命令可以安装在一台windows或者Linux操作系统上,通过TCP/IP网络对Vmware进行管理。
许可证也有几种,不像传统的Powerpath都是单机的。
安装配置方式根据许可证的类型(Served,Unserved)也有不同,过程相对要复杂一点。
上述详细情况请参考一下Powerlink或者Supportzone上面的文档。
哦,那安装好powerpath之后,vmware自带的多路径功能是不是要屏蔽掉?
VMWare有一个claimrule的功能,可以配置使用特定的软件来管理某一类阵列的设备。
安装Powerpath/VE之后,EMC的阵列就会被Powerpath/VE管理了,没有被PP接管的设备才会被NMP接管。
哦,自动切换的,很方便!
!
那么powerpath是要单独收费的嘛?
vmware的pp很贵!
记得好像AX、CX的连个sp应该是active-standby?
,针对同一个lun的访问,如果两台链路一个到spa,一个到spb,这种情况下powerpath应该提供的是链路冗余(主备,并不负载分担)的功能?
是不是负载分担应该是在多个lun的时候分布于不同spowner的时候宏观上看到的是负载分担?
还是别的理解?
但是实际上,有VMWARE的基本上没什么人再买powerpath吧?
AX、CX的连个sp应该是active-standby
对于主备模式,powerpath负载均衡的作用在于多条连接activeSP的路径,对于passiveSP是不发挥作用的。
如果只有一条链路连接到activeSP,就没有loadbalance这一说,但仍然有failover的功能。
再在A.Y的基础上补充一点关于各种操作系统自带的MutiPath工具介绍。
让大家再全方位的了解一下各个操作系统的多路径控制软件。
基本上每个操作系统都会提供Native的MutiPath软件。
主要有以下几种:
WindowsServer
WindowsServer从2003版本开始,微软开发了MPIOFramework,开始支持第三方存储阵列,使用DeviceSpeicificModules(DSMs)作为Framework的插件。
Powerpath也是基于这个插件解决方案之一。
WindowsServer2008以后开始自带MPIO软件(由MS基于DSM开发),添加了基本的LoadBalacing和Failover策略。
我在之前也些过关于WindowsMPIO的介绍,有兴趣可以看一下:
WindowsNativeMPIO存储多路径软件详解与应用
Redhat
DeviceMapperMultipathing(DM-MPIO)是Redhat默认的多路径控制解决方案。
它支持多数厂商的存储阵列,也包括EMC的存储。
DM-MPIO是通过multipath.conf.default文件来进行配置,默认情况下该文件针对不同的存储阵列自动创建,比如VNX会被设置成ALUAMode。
RoundRobin会被设置成SymmetrixVMAX和VNX的默认模式。
同时RoundRobin也是Redhat5和6的默认运作模式。
VMwarevPshere
ESX和ESXi提供了扩展的多路径模块,叫做NativeMultipathingPlugin(NMP)。
通常来说,VMwareNMP对多数存储阵列进行支持(参考VmarestorageHCL)。
NMP关联一组物理到存储阵列的物理链路,然后提供Failover等功能。
NMP模块还提供了可选的路径选择插件,SATPs(StorageArrayType Plguins)和PSPs(Path Selection Plugins)。
SATPs支持不同存储阵列的路径。
PSPs支持根据I/O负载来选择路径管理。
HP-UX
在HP-UX11iv2或者更早的版本,HPStorageWorksSecurePath提供了LoadBalancing和Failover功能。
在HP-UX11iV3(11.31)之后,NativeMultipathing被包括在操作系统之中。
默认的load-balancing策略是RoundRobin。
AIX
AIX的的多路径解决方案是path-controlmodule)PCM。
支持的规则也是Failover和RoundRobin策略。
Solaris
Solaris的MPxIO是Solaris中原生的多路径控制软件。
同样支持两个LoadBalancing策略,Failover和RoundRobin。
最后可能大家有疑问,Powerpath和这些多路径控制解决方案相比的优势是什么。
主要还是两点:
1.针对EMC的存储更好的优化故障切换和负载均衡。
2.性能上的优势,就像A.Y说的,同样条件下可以提升30%。
A.Y.编写:
很多操作系统都自带多路径软件的,比如Linux上有DM-MPIO,AIX上有PCM/MPIO,Solaris上有MPxIO。
这些操作系统也可以使用这些软件来控制对EMC阵列的多路径访问。
但是Powerpath与其他厂商的软件相比,和EMC的阵列配合的更好。
按照Powerpath的产品说明,与VMWare的自带NMP相比,Powerpath能带来~30%的I/O性能提升。
powerpath的一个命令<忘记了>有的时候会显示路径dead这个怎么解释呢?
powermtdisplaydev=all可以看链路!
死的链路应该就是掉线啦!
重新扫描一下试试
"powermtdisplaydev=all"可以显示所有通道的状态,我们会看到有deadpath是因为Powerpath无法使用这个通道来发送I/O请求。
最常见的原因是因为链路问题,但也可能是因为设备配置的改变(比如LUNMasking的改变),以及其他一些软件原因。
遇到这样的情况,可以使用"powermtrestore"命令来尝试进行恢复;或者使用"powermtcheck"命令。
两者的区别是“check”命令如果不能将通道的状态恢复,就会删除dead的通道。
如果上述命令不能解决问题的情况下,就要针对具体问题分析,该给EMC开case啦。
PowerPath发现dead路径时有以下步骤可用于诊断和修复:
1.检查新路径,如果显示deadpaths,则删除已存在的dead路径:
powermtcheck
2.扫描磁盘设备,PowerPath会自动进行配置;
powermtconfig
3.使用以下命令查看路径状态,如果所有路径显示为有效并且为激活状态(没有HBA激活问题),则进行下一步:
powermtdisplaydev=all
4.保存正确的PowerPath更改:
powermtsave
补充Alex的,说明一下powercheck命令和powerrestore命令:
powercheck:
对路径进行检查,并在需要的情况下从PowerPath配置中删除标记为dead的路径。
如果路径标记为dead或路径配置信息中的序列号与本地设备序列号不符,则出现提示用户删除路径。
powerrestore:
此命令测试并恢复指定路径,发出测试I/O并针对测试结果作出反应如下:
如果live路径通过测试,则此命令不做任何操作;
如果dead路径通过测试,此命令将其标识为alive状态;PowerPath此时可以使用该路径;此外,同一HBA和/或存储系统端口上的其他路径也将被测试。
如果live路径测试失败,此命令将其标识为dead并打印告警。
此外,共享HBA和端口的其他路径也可能标示为dead并被测试。
如果dead路径测试失败,此命令会打印告警。
此外,该命令还会尝试复活dead卷。
谢谢专家。
做例如powercheck这个操作的时候是否能在线操作吗?
需要停机操作吗?
不需要,因为这个命令只会对dead状态的通道进行操作,这些通道是不会有被用于发送I/O请求的。
有您这句话偶就大胆的往前走了。
嘿嘿,不过也是偶经常在跑的好好的机器上运行insf-e,也没有事情
请问powermtdisplaydev=all看到有这样的情况
以下是一个片段
SymmetrixID=xxxxxxxxxx
LogicaldeviceID=0175
state=alive;policy=SymmOpt;priority=0;queued-IOs=0
==============================================================================
----------------Host--------------- -Stor- --I/OPath- --Stats---
### HWPath I/OPaths Interf. Mode State Q-IOsErrors
==============================================================================
100/3/1/0.2.14.0.1.7.6 c10t7d6 FA 9dA active alive 0 0
110/7/1/0.1.14.0.1.7.6 c11t7d6 FA 7dA active alive 0 0
SymmetrixID=xxxxxxxx
LogicaldeviceID=01A9
state=alive;policy=SymmOpt;priority=0;queued-IOs=0
==============================================================================
----------------Host--------------- -Stor- --I/OPath- --Stats---
### HWPath I/OPaths Interf. Mode State Q-IOsErrors
==============================================================================
110/7/1/0.1.14.0.1.11.2 c11t11d2 FA 7dA active alive 0 0
怎么会一个有两个路径一个只有一个呢
这个倒不一定是一个错误。
首先从Symmetrix的角度,Device的Mapping和Masking,或者MaskingView(VMax)的配置都可以出现上述的现象,即每个设备的通道数量甚至连接的FA是完全不同的。
如果是连接了Clariion或者VNX的存储,出现了这个现象才表明有问题。
当然,如果这个通道数量和期望的不一致,首先要检查的当然是设备的分配情况。
如果没有问题,就要确认相应通道的native设备已经生成(HP-UX上可以用ioscan/insf这些命令来完成),然后再执行powermtconfig来将它们配置起来。
谢谢
如果发生了您说的那个情况应该就应该是powerpath与symmetrix给主机的路径的信息不一致吧,是否有必要一定要做校验调整呢?
通常可以用powermtdisplaypaths,powermtdisplay检查一下通道数量,逻辑设备数量的总结,如果觉得有疑问可以进一步通过powermtdisplaydev=all命令查看细节。
出现问题的情况还是少数,大部分情况下如果所有操作都合规范,正常运行的系统不大会出问题。
论坛上一篇文章总结过PowerPath常用命令的使用方法和注意事项,功能包括HBA/路径/端口/磁盘设备/存储系统执行配置、查看、删除、保存、恢复等:
PowerPath常用命令总结及应用
太复杂了,还要单独做一台rpowermt管理控制机吗?
为什么要这样设计呢?
大多数中低端存储都是AP模式的架构,即active/standby,起到的是冗余,而不能负载均衡,当时这是针对一个LUN来说。
当然也有例外,HDS的AMS系列就可以做到AA模式的,技术还是比较先进的。
请问PowerPathEncryption以及PowerPathMigration这两个功能是做什么用的呢?
PowerpathMigrationEnabler是用于做数据迁移的,这是一个主机软件用于迁移数据的解决方案,要求是主机必须同时连接源和目标存储,并且数据迁移的运算资源是来自服务器(与基于阵列的数据迁移相比较的主要区别)
PowerpathEncryption是将数据加密以后存放到存储设备上,读取以后解密再提供给应用程序的功能。
这两个功能的用户应该不是很多吧。
en.......关于powermigration:
这里的源是不是可以理解为就是主机上的硬盘或者光驱之类的存储介质呢?
所谓的migration是否是一种backup呢?
还是说可以做OS层面的在线迁移?
关于powerencryption:
加密后的数据能否被另一台安装了powerencryption的主机访问呢?
收藏之。
其实很简单,专业版一定会强于大众版。
这就是PowerPath一定会优于OS厂商提供的MPIO的原因。
要强有力的说明哦,不然客户怎么愿意买呢
anhong的这个要求很厉害啊,比较困难的说……毕竟Powerpath属于"InfrastructureSoftware"而不是一个业务应用,大部分客户不会在Powerpath层面做太多的定制,还是越稳定越好,用法也比较简单。
我就分享一点支持Powerpath这个产品过程中总结的经验,希望能有点帮助。
首先介绍一下常用的文档吧,在网站上有各种版本的PowerpathInstallationandAdministrationGuide,里面有比较详细的安装/升级以及卸载Powerpath的步骤及注意事项。
这些文档不是那么容易看,但是如果严格照着做的话,确实可以避免大部分的问题。
另外在连接EMC的Clariion/VNX阵列的时候,一定要查一下EMC的KBPrimusemc99467(通过网站搜索即可)。
这个里面包括了针对各种操作系统的InitiatorType,FailoverMode,Arraycommpath以及UnitSerialNumber的配置。
这个配置必须严格遵守,否则在识别设备或者运行过程中通道切换时都会有影响
如果连接的是Symmetrix设备,那么就要到上去确认一下DirectorBit。
这些配置同样会对设备识别以及通道切换造成影响。
另外在的文档中还包括了PowerpathCLIandSystemMessagesReferenceGuide,对于其他的一些管理任务,比如伪设备名的改变,批量导入导出,通道优先级变化,以及一些故障处理技巧方面都比较有用。
后面我会分享一些Unix操作系统上最常见的现象以及解决方法。
powerpath进程后台应该有定时检测IO链路是否alive的restore操作吧?
系统繁忙时,insf-e的操作最好不要做。
保不准系统就hang了,俺这里的HPUX发生过哦
这两个功能国内应该基本没啥企业在用。
数据迁移有大把的方法,而PowerpathMigrationEnabler很明显应该只能支持EMC存储之间,估摸着限制还不少。
不过这个功能用PP做还真是手到擒来,管理所有链路的IO,做同步岂不是容易得很。
说的太棒了,前段时间就因为没有注意到failovermode而吃了大亏,折腾了一个晚上。
期待最后那句的内容分享。
关于PPVEforWindowsHyper-V不是很确定,超出我的范围了...
但是查了一下"EMCPowerPathandPowerPath/VEforWindows5.5andMinorReleasesInstallationandAdministrationGuide",里面只提到PP/VEforHyper-V需要一个独立的License。
而没有更多的说明,所有的产品文档和软件都是放在一起的,看来只是一个许可证的区别而已。
先说说AIX吧。
想了一下,AIX上Powerpath最常见的部署问题恐怕还是在连接Clariion/VNX存储时的failovermode配置。
在使用Powerpath的情况下,failovermode这个值只能配置为3或者4。
3是PNR(PassiveNotReady),4是ALUA。
大致解释一下这两个的区别:
PNR/PassiveNotReady的模式下,对于一个LUN的访问只能通过它当前所属的控制器(SP)来进行,如果通过另外一个(Passive)控制器进行读写的话,就会得到一个"LogicalUnitNotReady"的错误,errpt里面会出现一个DISKOPERATIONERROR。
对于其他的操作系统来说,这样的模式是要求failovermode配置为1的。
ALUA是非对称的访问,对于主机来说两个控制器都可以接受读写请求的,但后端处理上会不一致。
这样的情况下,无论从那个控制器都不应该会看到"LogicalUnitNotReady"的错误。
5.3及以前版本的时候,如果这个值设置为1(大部分其他操作系统的要求),Powerpath可以识别设备,但是通道切换到时候会出现问题,过程不平稳,并且errpt里面会报一堆的错误。
从5.5(或者是某个小版本)开始,如果这个值配的不正确,那么powermtdisplaydev=all就显示不出任何的设备了。
这可能是因为Powerpath软件对这个值的检查条件增强了。
我们遇到过多次客户升级这个软件之后说设备都不见了,然后发现其实是一个错误配置用了很久很久...
除此之外还有一些客户在初次安装EMCODM的时候会比较困惑,那么多的文件集选哪些个安装呢?
大致总结一下:
版本:
AIX7.1需要使用ODM6.0.0.0,AIX5及AIX6需要安装ODM5.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阵列的安装过程出现问题的好像不是很常见。
XX文库-让每个人平等地提升自我我也是查看了相关文档发觉ppforWIN和PP/VEforhyper-v在安装上没差别,差别就是许可证。
。
谢谢!
PowerPath使用周期性路径测试以确认路径是否能正常工作。
路径测试是PowerPath通过发送一系列I/O以确认路径的可用性。
如果测试失败,PowerPath关闭该路径并停止向其发送I/O。
PowerPath继续周期性地检测故障路径,以确认其是否恢复。
如果路径通过测试,PowerPath将恢复对该路径的使用并重新发送I/O。
在轻量负载或小型配置的情况下,路径在修复后会在一小时内自动恢复使用。
对于大型配置,修复后恢复所有路径使用可能花费数小时,因为周期性自动恢复任务被更高优先级任务抢占。
路径的故障切换以及恢复流程对于应用程序来说是透明的。
当路径恢复后,存储,主机,应用程序将继续保持可用性。
测试正常工作路径将花费几毫秒,测试故障路径可能花费数秒,具体取决于故障类型。
谢谢A.Y