作者mac2008·2018-10-08 11:07

项目经理·IT公司

同城存储双活故障处理技术案例分享

字数 3375阅读 6227评论 4赞 10

# 一、	故障概述
最近处理了一起同城存储双活故障事件，故障比较典型，整理出来和大家进行技术分享，欢迎大家对存储双活架构进行讨论、指教。

故障现象是客户反馈业务系统中断，部分虚拟机无法访问。通过VMware vsphere 控制台登录检查发现，虚拟机灰色状态，部分共享存储不可访问。

![71m1uk5ck2o](/home/attachment/201810/08/3384_153896704722111.png)

# 二、	故障处理
## 1.	硬件环境说明
客户硬件环境是做的同城存储双活，本地是一台EMC Vplex存储网关纳管2台EMC存储，前端是VMware ESXI主机集群，异地也是一台EMC Vplex 纳管2台EMC存储，前端是VMware ESXI主机集群，具体硬件架构如下图：

![8ccq1kiovtw](/home/attachment/201810/08/3384_153896711011644.png)

## 2.	故障分析处理
第一步：首先检查EMC VPlex存储网关和EMC存储，设备状态运行正常，排除EMC VPlex存储网关和EMC存储硬件故障。
第二步：检查SAN光纤交换机，第一眼看SAN交换机端口都是online状态，没有在意继续排查。
第三步：由于是EMC双活环境，对其中一台ESXi主机进行重启，重新识别共享存储，发现ESXI主机共享存储恢复正常访问，先恢复业务要紧呀。
第四步：通过逐台对ESXi主机进行重启，业务全部恢复正常。
第五步：收集EMC Vplex日志、VMware ESXI主机日志，配合厂商进一步分析。
## 3.	故障原因定位
**第一步：**通过VMware ESXI主机日志分析，存在如下报错信息：

vmkernel日志中显示 All Paths Down (APD) error ，时间在 00:06 UTC time，输出如下：

```
First time at 00:06 UTC time
-----------------------------
00:06:05.901Z cpu72:20695671)ScsiDevice: 6881: Device naa.6000144000000010b028176445fd175d APD Notify PERM LOSS; token num:1
00:06:05.901Z cpu72:20695671)ScsiDevice: 6881: Device naa.6000144000000010b028176445fd17a8 APD Notify PERM LOSS; token num:1
```

ESXI主机不能访问存储lun的原因是因为发生了All Path Down，会使得ESXI主机短暂丢失对datastore的访问，这段时间内IO error出现都是可能的。

现在初步判断: ESXI主机部分无法访问共享存储是因为发生了All Path Down导致，接下来故障原因

聚焦在ESXI主机到共享存储多路径上。

**第二步：**重新检查SAN交换机端口状态，对2个站点光纤交换机SFP长波级联模块以及光纤链路进行光信号强度进行测试，发现生产中心到灾备中心直连光纤链路光衰较大，RX分别是-16dBm、-17dBm，偏离EMC存储双活环境推荐范围值。

EMC官方建议：EMC建议RX的收光功率最好大于-7dBm。日常实践证明，如果8G链路的收光功率小于-10dBm，交换机基本无法正常接收光信号。

![7qcgrt3aeur](/home/attachment/201810/08/3384_153896733449940.png)

![ynwsx850ws](/home/attachment/201810/08/3384_153896737434200.png)

**第三步：**进一步确认由于生产中心到灾备中心直连光纤链路光衰较大，导致EMC VPlex Metro Mirror 延时异常，生产中心部分共享存储发生All Path Down，从而导致虚拟机不可访问。 中断EMC VPlex Metro Mirror, 协调运营商对生产中心到灾备中心直连光纤链路信号衰减进行修复。

**第四步：**运营商对生产中心到灾备中心直连光纤链路信号提高大于-7dBm后 ，重新进行EMC VPlex Metro Mirror存储数据同步，VMware 虚拟化平台主机运行恢复正常。

# 三、	技术分析
## 1、	SFP模块光功率信号强度分析
FC（fibre channel）交换机使用光信号传输数据，交换机的SFP/GBIC模块负责接受/发送光信号，并完成光/信号的相互转换。如果SFP模块接受/发送的光信号强度不够，势必会影响到上层FC链路的稳定性。一个优秀的SFP/GBIC模块是FC链路稳定的最基本保障。

**衡量方法:**
业界常见衡量光信号强度方法有两种：Microwatts(mW)和dBm，不同平台交换机采用方式可能会不一样，部分会选择mW，部分会选择dBm。SFP光模块信号强度通常包含两个指标，分别是Tx Power和Rx Power。Tx Power代表SFP模块发送方向的光信号强度；Rx Power代表SFP模块接受方向的光信号强度。

**mW和dBm之间联系**

mW通过功率方式描述光信号强度，dBm是decibel of the measured power to one millwats的简称，通过分贝方式描述光信号功率比。Cisco交换机使用dBm方式，Brocade交换机使用mW方式。两者可以通过以下公式互相转换：

dBm -> mW：

![0s9wvjoqsds](/home/attachment/201810/08/3384_153896753868069.png)

mW -> dBm：

![9wfcx0czjfj](/home/attachment/201810/08/3384_153896757565060.png)

EMC推荐光信号强度范围：

![oitej40vj0s](/home/attachment/201810/08/3384_153896778454746.png)
![dfdgdenkcbm](/home/attachment/201810/08/3384_153896782630478.png)

常见速率最大可接受光衰减范围：
•         8Gbps最大可接受信号衰减值：-13.8dBm
•         4Gbps最大可接受信号衰减值：-15.4dBm
•         2Gbps最大可接受信号衰减值：-18.2dBm

EMC的推荐范围比Cisco/Brocade交换机自带范围要小，最小信号强度相对高一些，最强信号强度相对低一些。EMC建议RX的收光功率最好大于-7dBm。日常实践证明，如果8G链路的收光功率小于-10dBm，交换机基本无法正常接收光信号。

如下图说明：

![q0ih2d25n5m](/home/attachment/201810/08/3384_153896789149105.png)

## 2、	VMware ESXI主机共享存储卷路径设置策略
由于客户生产环境是EMC VPlex 存储双活环境，对于VMware存储卷路径设置策略就比较有讲究，由于客户主要业务系统虚拟机都在生产环境站点，EMC官方推荐路径策略采用 固定 模式。

![hxygysbe0so](/home/attachment/201810/08/3384_153896792953347.png)

# 四、	故障总结
通过本次同城存储双活故障处理，总结一下经验：

1、	生产端与灾备端的SAN光纤交换机级联SPF模块及链路RX的收光功率最好大于-7dBm。
2、	EMC VPlex 存储双活环境VMware存储卷路径设置推荐采用固定模式。
3、	EMC VPlex 仲裁服务器Witness推荐放置第三站点。

同城双活链路抖动存储双活故障处理运维管理

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论4 条评论

luochao1985技术支持同有飞骥
2019-05-13 13:19

很好，值得学习

不宕机不丢包系统工程师XX银行
2018-10-22 09:53

这个案例中的双中心SAN链路没有经过波分设备，直接裸纤互连的吗？另外请问下两中心SAN的互连接口有CRC错误是否也与光衰较大有关系啦？

不宕机不丢包系统工程师XX银行
2018-10-22 09:52

这个案例中的双中心SAN链路没有经过波分设备，直接裸纤互连的吗？另外请问下两中心SAN的互连接口有CRC错误是否也与光衰较大有关系啦？

haizdl技术经理大连
2018-10-08 11:28

这个故障过程有点讲不通啊，生产中心到灾备中心的链路有问题导致访问灾备端的存储镜像有问题，这个没问题。可是生产中心本地的链路没问题啊，local的镜像是可以访问的啊，这是很典型的链路中断场景，存储双活不就是为了保障这样场景的故障不影响业务啊，怎么业务会中断呢？导致中断的根本原因似乎不是这个啊。个人见解哈

mac2008： @pobird 感谢@赵海兄弟、@pobird兄弟的见解： 1、本身存储双活架构是保障一端存储有问题，业务能不受影响，由于是同城双活架构，不是本地双活架构，从现场故障分析处理来看，链路的抖动的确影响了vplex服务稳定运行。 2、对于仲裁节点，我在文章中忘记说明，仲裁节点Witness是一台虚拟机，放置在ESXI主机本地硬盘上，由于当时业务中断影响面较大，对ESXI主机进行重启操作尽快恢复业务，仲裁节点Witness做过重启。 3、对于产生本地存储链路中断，大家有其他分析见解，欢迎讨论交流学习研究，哈哈！

2018-10-09 19:44

pobird： @haizdl 估计还有仲裁节点的设计问题没提

2018-10-09 10:00

添加新回复

Ctrl+Enter 发表

匿名评论

同城存储双活故障处理技术案例分享

添加新评论4 条评论

作者其他文章

相关文章

相关问题

相关资料