未解决
此帖子已超过 5 年
89 消息
0
5320
如何预警并处理一个FC链路的故障
兄弟姐妹们：
之前有帖子讨论powerpath如何处理链路故障，超时机制，也有帖子问如何判断san环境的健康，我们来讨论下，如何预警并处理一个FC链路的故障。这种故障在实际中比比皆是：
一个SAN环境，在出线链路物理故障时，交换机和存储、主机都有感知。交换机能看到CRC，存储能看到FC loop闪断，主机也能看到链路不稳，但是由于发生和恢复极快，基本都是在秒级，所以在一些看起来都“正常”，只有“warning”，“online”，没有“critical”的情况下，应用（比如OLTP数据库）挂了！
如果物理链路在某一个时刻，突然坏了，不再恢复，那么各种故障处理机制会生效。但是就怕时好时坏，不稳定的情况出现，故障处理机制没有彻底进行，所有io持续压在这个链路上，应用层挂，是必然的。
我们虽然可以监控各种日志，主机，交换机，存储，但是能扑捉的信息，往往只是个“偶尔”，“可能”，这些信息，不能直接作为故障处理的依据，也就是说，即使扑捉，也就是产生一种“将要坏”的预期，而无法避免。
这可如何是好啊？
liulei_it
3.2K 消息
0
2012年9月3日 07:00
做数据库的也经常碰到这样的“幽灵”哦，动不动就DB完了，赶快查，结果动用了服务商甚至第三方工具也看不出个所以来。经常发生或者发生了状态定型了也好办了，就是怕遇到您说的那个情况，秒级毫秒级瞬间一霎那，系统挂了。然后看到若干人等开始忙碌了。
理想的情况是建立一个知识库或者叫做状态统计信息库，把您说的比如FC链路的各项重要指标作为参数对系统采集数据。按照发生问题时指标的数值根据统计学的规律推测当其中一项或者几项指标达到或者超过基准时危险就会来临。
当然样本越多获得的信息越多，EMC可以尝试推荐重要指标并且在可以建立 公用知识库 这样方便用户阿。
不然只能考工程师的经验了可有的时候经验也不准阿。
SteveZhou
136 消息
1
2012年9月3日 19:00
我觉得这种问题还是得从源头考虑，DB crash的root cause是什么？如果是我们谈到的秒级瞬断，那么DB为什么会因为这种瞬断而Crash而不是通过另一种机制做出反映。
现在的冗余机制基本都会有瞬断，关键是App的设计如何应对。如果不从App考虑，我的想法是解决冗余机制的瞬断问题。
Roger_Wu
4K 消息
0
2012年9月3日 19:00
重要指标大伙应该都清楚，主要还是监控手段的问题。传统的远程监控手段，在抓取数据时会有间隔，这一间隔通常都在30秒-600秒之间，确实无法应对楼主说的“秒极”的事件。但是每一秒都做检测呢，会对应用和设备造成更大的负担，因延时而造成的误报也会更多。
不知道各位都用的哪些数据库监控软件？像Quest Foglight/Spotlight之类的软件能做到提前预警吗？
SteveZhou
136 消息
0
2012年9月3日 19:00
个人对DB不熟，所以也无从思考。我想了解的是，你刚才说的由于瞬断（秒级）导致DB Crash究竟是如何发生的，我指的是为什么DB会因为瞬断而Crash，Crash是指unmount了？Crash是DB本身的保护机制所引起的吗？就像WINDOWS的蓝屏（bugcheck）。
我一直认为软件才是核心，硬件无法控制的问题可以通过改善软件机制来解决，可惜不懂DB，不好判断。
Jun_Tan
605 消息
0
2012年9月3日 19:00
IT基础架构监控是个大难题，尤其规模大、业务种类多的时候，势必需要借助监控自动化+变更管理来保证架构的可用性。
实际工作中，很多公司都有自己完整的自动化监控和变更管理体系，监控指标也很量化，但是面对这种面对这种“模棱两可”、“无法重现”的问题也没有很好的解决办法，因为没有办法从技术角度来定这个度。如果从数学角度来分析这个问题就很好理解，“模棱两可”是代表一个随机分布连续空间，而我们的监控体系是一个不连续的离散空间；用离散指标去覆盖连续变量肯定是有漏洞的。
个人建议是：
作为运维人员要有卖服务的意识，对不同业务分类，根据重要性跟业务谈好SLA。如果从这个思路来看这个问题，相对比较好解决。
对于重要DB和应用的FC链路只要出现跟硬件相关链路问题就主动采取变更。这样可以将业务风险降到最低。
leecoool
89 消息
0
2012年9月3日 19:00
记录各项链路的指标确实是现阶段可行的办法。我现在也有这样做的，比如记录各个段落log中关键字的内容，然后写进数据库或者文件中，统计发生的次数。
不过遗憾的是，究竟什么数量来判断我们是否应该更换硬件是个难题，比如链路CRC开始出现了，或者光功率下降了，究竟什么时候主动的去做个变更，把这个端口disable，然后更换掉。而不是等待这个硬件故障发生，一旦发生了，就是我开帖子的那个情况出现了。
如何把握这个“度”？
SteveZhou
136 消息
0
2012年9月3日 20:00
sp event log的监控粒度太大，秒级别无法反映这种瞬断，所以看到了同一秒down & up，这种情况从VNX角度来说，只有EMC内部的工具能检查一些粒度更细的日志，比如各种组件的debug trace。
就我们谈到的这个问题来说，该不该换硬件也只有厂商有指标来判断了，我们就算有指标也未必有工具能抓出来看。
相信你们已经能够对DB做细粒度监控，抓到每条event最终确定是因为瞬断导致问题，但这没有解决实际问题，就像你说的，明知瞬断导致问题却不知道该如何阻止它发生。
我在想，除了App和链路切换机制，难道就没有其他一些高级功能能解决这个问题吗？比如A/A Cluster、分布式系统等等，对这些技术知识有限，只能空想。。。。看来需要修行一凡。
leecoool
89 消息
0
2012年9月3日 20:00
基本上碰到这类问题都是主动变更，把链路关闭的。但是往往都是事发之后。
SteveZhou
136 消息
0
2012年9月3日 20:00
谈到这个不由得让我想起了虚拟化，虚拟化解决的一个大问题就是App与物理设备之间的耦合性，去耦之后，由于物理特性导致的问题就不再会影响App，因为App不再直接依赖硬件，就好比VMWARE DRS+vMotion。现在网络虚拟化也是大热门，我认为虚拟化的理念是解决IT复杂性的关键。
leecoool
89 消息
0
2012年9月3日 20:00
应用设计是必须要做的，不能认为所有的后端都100%处于高可用高性能的状态
leecoool
89 消息
0
2012年9月3日 20:00
就我遇到的情况来说，在vnx的记录里能看到在同一秒里看到的down & up，所以，如果不抓日志，是很难捕获的。我们的数据库监控大部分是自己写的。。。
leecoool
89 消息
0
2012年9月3日 21:00
其实DB没有crash了，只是hang了一下，但这一下很致命。
拿oracle来说，在powerpath去判断路径健康与否的时候，会hang io，这个时候，oracle的redo就写不下去了，延迟忽然就高了。。在otlp应用下，本来应用都是2到3ms的，这个时候就是几十ms了，于是稍稍敏感的应用，就跪了。。
liulei_it
3.2K 消息
0
2012年9月3日 22:00
愚以为，IBM大型机是个硬件耦合程度比较高的，但是没有很多的企业和机构能承受的起那高昂的价格啦。
对于开放式系统阵营来说，虚拟化的确是个好的方向，听说网络上已经有客户用神马虚拟化设备代替了传统网络设备搜索生成树了。不知道效果怎么样。
在结合了许多厂商的系统中要找出问题还真的不容易尤其还要面对客户的质问时心理素质一定要好啊。
愚以为正因为如此才出现了一体机，所有的东西都是我的。哈
leecoool
89 消息
0
2012年9月3日 22:00
那个。。。是openflow,SDN之类的吧。。跑题了。。还有，IBM大机很少了，现在都是小机。。
SteveZhou
136 消息
0
2012年9月3日 22:00
也不算完全跑题，本来就是随便聊有什么想法能解决此类问题的。
我觉得如果FC SAN环境能也能构建出类似openflow这样去耦合技术，把App对于硬件的依赖降低为0，那才是解决“软件需要100%可靠，而硬件又无法保证”的问题，毕竟硬件有其物理特性，不可能永远不出问题。