存档

文章标签 ‘netapp’

VMware ESX/ESXi 使用NETAPP存储 FCP Partner Path Misconfigured 报错处理

2011年10月27日 没有评论

VMware ESX/ESXi 使用NETAPP存储 FCP Partner Path Misconfigured 报错处理

在VMware ESX/ESXi 使用NETAPP存储时,存在多路径访问存储lun的情况下如果配置不当极易引起报错:
[hostname: scsitarget.partnerPath.misconfigured:error]: FCP Partner Path Misconfigured - Host I/O access through a non-primary and non-optimal path was detected.

这个主要是因为ESX主机在访问lun时使用了非主路径造成的,就如下图这种情况:

从上图来看我们可以看到这个lun在主机上实际是有2个访问路径的,一个是通过lun所在的机头访问的主路径,另一个是Partner机头的备用路径。
如果是更加高可用的采用2个机头各自使用2个光纤交叉连接至2个交换机的方式,那么每个lun在主机上对应的访问路径将会有4个,其中2个是主路径,2个是备用路径。

那么在ESX中是如何来选择多路径的呢,这里也介绍下ESX的多路径选择机制。
首先ESX会判断存储的类型,主要是A/P主-被、A/A主-主、ALUA主-被和非对称主-主这几种。
对应不同的存储类型ESX会使用不同的默认路径选择方式:

最近使用(VMW_PSP_MRU):选择最近用于访问指定设备的路径。如果此路径不可用,则会切换到替代路径并在该新路径可用时继续使用它。MRU是主-被阵列(A/P- Active/Passive)的默认路径策略。
固定(VMW_PSP_FIXED):使用指定首选路径(如果已配置)。否则,它将使用在系统引导时间发现的第一个工作路径。如果主机不能使用首选路径,则它会选择随机替代可用路径。一旦首选路径可用,主机便会恢复到首选路径。“固定”是主-主阵列(A/A – Symmetric Active/Acivie)的默认路径策略。
VMW_PSP_FIXED_AP:将“固定”功能扩展到主动-被动阵列和非对称主-主(ALUA – Asymmetric Active/Active)阵列。
循环(VMW_PSP_RR) :使用路径选择算法轮流选择所有可用的活动路径,并在路径之间启用负载平衡。

根据我管理的系统中2台NETAPP的存储在ESX中均被识别为:VMW_SATP_DEFAULT_AA,就是A/A主-主类型,所以他默认使用的是 固定(VMW_PSP_FIXED)。
那么问题就在这里了,由于固定(VMW_PSP_FIXED)方式的路径选择,ESX将会选用第一个发现的路径作为首选路径来使用,但是有些时候这往往不是主路径,所以就导致了Host I/O access through a non-primary and non-optimal path was detected.的报错。
这个时候就需要手工调整首选路径了,那么如何来确定什么路径才是主路径呢?

1.首选确定目标lun所在的机头
这个我想不用多说了

2.连上目标lun所在的机头确认FC Nodename和Portname

FAS2050A> fcp show adapters
Slot: 0a
Description: Fibre Channel Target Adapter 0a (Dual-channel, QLogic 2432 (2462) rev. 2)
Adapter Type: Local
Status: ONLINE
FC Nodename: 50:0a:09:80:88:8c:82:35 (500a0980888c8235)
FC Portname: 50:0a:09:81:88:8c:82:35 (500a0981888c8235)
Standby: No

Slot: 0b
Description: Fibre Channel Target Adapter 0b (Dual-channel, QLogic 2432 (2462) rev. 2)
Adapter Type: Local
Status: ONLINE
FC Nodename: 50:0a:09:80:88:8c:82:35 (500a0980888c8235)
FC Portname: 50:0a:09:82:88:8c:82:35 (500a0982888c8235)
Standby: No

根据上例返回的信息,这个机头有2个hba卡,在esx看到的目标路径就是Nodename Portname,这个的2个目标路径就是
50:0a:09:80:88:8c:82:35 50:0a:09:81:88:8c:82:35
50:0a:09:80:88:8c:82:35 50:0a:09:82:88:8c:82:35

3.知道了目标路径后打开esx存储适配器手工指定目标lun的首选路径


本图由于有4个路径分表是其中有2个目标路径对应lun所在机头的2个hba卡,可以根据实际情况手工指定不同的hba卡分流流量。

如何检测调整的效果
1. lun stats -o 查看Partner Ops 和 Partner KBytes 字段,可以直观的以lun列表的形式查看,如果是调整后可以使用lun stats -z清空统计数据。
2. sysstat -b 1 查看Partner字段,可以直观的以实时监控的形式查看。

如果上述字段为非0那就说明有Host I/O access through a non-primary and non-optimal path的情况。

总结一些netapp管理中的误区把,省的初学者绕弯路。

2011年9月13日 没有评论

1.建立lun的时候lun name最好就直接写明白lun的内容。

我之前是这样建lun的

lun create -s 201g -t linux -o noreserve /vol/volb1/web1/lun1
lun comment /vol/volb1/web1/lun1 web1

本来想想这样子已经够清楚了,没想到最近在用lun_top监控lun的读写情况是发现他就仅仅用了lun name,而不是path。结果就是重头到尾的排序都是lun1
解决方法:lun move /vol/volb1/web1/lun1 /vol/volb1/web1/lun.web1

未完待整理

分类: 硬件相关 标签:

一次netapp2050机头故障的修复经历

2009年4月3日 1 条评论

今天吃饭前,上网管机,惊现存储监控的页面上面闪红灯,紧急赶往机房一看,一台netapp2050的机头a处于关机状态,于是连机头b查看,机头b的cf status状态是FAS2050B has taken over FAS2050A. 目前存储处于机头b接管状态。

于是又输了几条命令查看了下机头b的状态,当输入stats show 之后,没有出现命令行,ctrl+c也无法退出到命令行,断开终端重连输入用户名和密码后还是处于无命令行状态,顿时抓狂。

联系了下售后,决定先找机头a当机原因,起出机头a,由于机头a处于Waiting for giveback状态(ctrl+c重启后autoboot还是这样),无命令行,web也无法进去,直接用nfs连也无法通过。

到此为止,基本情况就是这样,机头a处于Waiting for giveback等待状态,需要机头b进行giveback才能回到正常工作状态,但是进行这个操作必须在机头b进行命令操作,但是机头b无论串口还是telnet都无法出现命令行。
:???:
抓狂了一阵后,忽然想到rsh可以直接写命令进去,试了下
rsh 10.10.1.1 -l root:root rdfile /etc/log/messages

果然有戏,把机头a的日志给读了出来了,一看原来nvram的电池检测到问题,自动关机了
Thu Apr 2 20:00:27 CST [FAS2050A: kern.shutdown:notice]: System shut down because : “NVRAM BATTERY FAILURE”.

把日志发给售后,netapp那边一开始说发配件换电池把,后来又打电话说无法判断是电池还是充电模块问题,干脆换机头把。 :shock: …说等会给我确定送货时间,我一琢磨下一工作日岂不是要4天后才能搞定了 :evil:
等了一会,售后又打电话过来说netapp那边分析下来应该属于固件版本太低的问题,这个版本固件可能有点bug,电池是应该好的,让我直接giveback。 :???:

没办法客服的话总是要听的,rsh 10.10.1.2 -l root:root cf giveback 结果提示
Partner not waiting for giveback, giveback cancelled.
To do a giveback without checking for partner readiness, please either set optio
n “cf.giveback.check.partner” to “off” before doing “cf giveback” again, or do ”
cf giveback -f”.

The first choice disables checking for all future “cf giveback”, until it’s turn
ed back to “on”. The second choice is good for this giveback only.

客服说我插拔过机头用cf giveback -f,咱照做,果然有反应了
在机头b上面cf status,目前状态是
FAS2050B has taken over FAS2050A, giveback in progress.
giveback is in module “snapmirror”, 118 of 131 modules.

一阵等待后,提示ready for giveback,终于真不容易。。。。
继续 cf giveback
哗啦啦一堆信息滚过之后终于
Cluster enabled,2个机头都up了

最后按照客服提示options autosupport.doit 2000669538 导出一份autosupport报告发了过去。
客服说下周安排过来升级固件。

流水账就此结束,幸亏发现的及时,没有造成什么后果,这次经历之后我乖乖的还是把autosupport邮件名单添加了一份我的手机邮地址,可怜每个星期天半夜要被骚扰一次了。

分类: 硬件相关 标签:

netapp重复数据删除,vmware的绝配

2008年9月16日 没有评论

今天在新建设vmware平台的netapp存储上面尝试打开重复数据删除功能。
具体如何打开请看我另外一篇博文http://226617.cn/index.php/archives/170
环境是5台10g的linux虚拟机。占用空间50g,做了重复数据之后的结果
FAS2050A> df -sh
Filesystem used saved %saved
/vol/vola1/ 3052MB 47GB 94%

看完成之后只占用了3g空间,空出了47g。节约了达到94%的空间。这个数据真是恐怖啊

在打开的sis的时候还发现一个莫名奇妙的问题
FAS2050A> sis on /vol/vola1
Volume or maxfiles exceeded max allowed for SIS: /vol/vola1

一开始以为volume太大了,后来修改后发现还是这样提示,把另外一个机头的完全一样的volume试了下打开sis却完全没问题。
最后赶时间,把数据挪了下位置把整个volume重新建了下,就正常了。真是奇怪的问题。

NetAPP 重复数据删除快速配置

2008年9月10日 没有评论

1:添加license, license 是免费的 NetAPP 建议使用7.2.4 及以上版本
>license add
>license add
2:在需要删除重复数据的volume上面,开启重复数据删除功能
>sis on /vol/(volname)
如果要把已经存在的数据进行重复删除用(比较占cpu和磁盘读写,尽量在没有什么数据量的时候进行)
>sis start -s /vol/vola1
3:检查重复数据删除的情况
>sis status /vol/(volname)
当过程结束只有,通过df来检查volume占用空间的变化
>df -s /vol/(volname)
4:配置重复数据删除的schedule
>sis config /vol/(volname)
注:
1: SnapMirror : SIS + SM, 一般都是先做Deduplication,再做SnapMirror
2: 在VMware 的环境下面,重复数据删除能够起到很大的作用

分类: 硬件相关 标签: