波哥亲历的一次超级烧脑的故障处理过程

ok!~又是一次超级烧脑的故障处理过程,这次故障还是非常考验推理及基础知识的扎实性的.

兄弟们可以先看我的问题描述,然后自己心里有个大概的方向或者有没有什么答案,亦或者上网查一些资料来尝试自己处理一下.

事件起因是因为一次zk架构改造!~

我们一起看看之前公司的zk老架构.

可以看到这是一套非常简单的架构,虽然有集群的特性,但是扩张和使用起来非常不灵活.很难满足4个9的需求.

再看看波哥设计的新架构:

相信各位应该能看懂什么意思哈!~

这里lvs使用的是跨网段的dr模型.

当然这里展示的也只是逻辑架构拓扑,改造还有很多细节.

比如zk、lvs+ospf及系统的参数优化,容器相关优化,监控大盘绘制,监控及故障自愈脚本撰写,zk自动分析功能模块撰写,自动部署及动态扩展的playbook撰写等等一系列内容.这里还有无数的细节.

这里就不给大家详细阐述了,以后抽时间带大家一起走一遍为了适应高并发核心组件的改造过程和细节,这些可都是经历了实战的内容哦!~

改造内容很多,简单总结分为以下几大块:

1、加入了内部dns解析(加入配置中间层使客户端配置和zk集群解偶).

2、加入lvs+ospf中间代理层(使客户端的直接通信跟zk集群解偶).

3、zk扩容(不同的云平台)

那么了解了新架构之后我们开始说问题.列事件大时间轴.

6月10号架构测试环境通过一系列测试.

6月17号架构生产环境割接结束.

#####期间无任何问题#######

6月23号凌晨,某部门批量更新多个服务,其中新增的C服务报无法连接zk.

org.apache.dubbo.rpc.RpcException: No provider available from registry zk01.xx.local:21xx,zk02.xx.local:21xx,zk03.xx.local:21xx for service com.xx.xxxx.service.IDubboOrderService:1.0.0 on consumer 10.xx.xx.xx use dubbo version chd-2.7.3-v1.0.4,  please check status of providers(disabled, not registered or in blacklist).atbrbr

错误日志见上面.业务侧将问题反馈给到了波哥.

那么首先他们不是光这一个服务连接zk,有很多服务都是连接zk的.所以我们初步推断应该是研发侧业务配置的问题.

业务侧发出了相关配置,发现没有错误.

开始正式处理问题.

登陆报错的服务器:

telnet lvs相关端口 不通!~ping lvs的vip,不通!~

ping lvs服务器的物理ip,不通!~

尝试直接ping zk服务器的端口和ip,正常通信!~

呦西!~

去这个部门的其他业务机器也是使用zk的,ping vip,正常通信!~

那么到这里就有几个比较成形的推断:

1、报错服务器本身没有网络设置问题.

2、zk生产环境割接完成了近一周时间,这个服务之前也连的zk一直没有问题.

3、业务侧的配置没改过,应该不是配置的问题.

4、不是zk和lvs+ospf的问题,因为连接zk服务的有很多,只有这个服务有问题,所以还是倾向是客户端的问题,但是客户端检查了一下,确实没有问题.

难道交换机更新了一些策略?

迅速联系基础网络组同事进行核查网络问题,那么这里需要协助的最重要的依据就是报错服务器,对lvs的物理ip及虚拟ip都ping不通了.处于失联状态.

网络排查中!~

第一阶段结束需要网络组同事介入一起判断.######

半个小时后网络组查实没有问题.

那么好吧,重新分析问题,咱们再梳理一遍:

1、研发侧配置没问题.

2、网络没问题,没有新增策略.

3、其他服务正常没有异常,说明zk集群没问题,lvs没问题,还在工作.

4、生产环境割接了一个星期了,这个服务一直没问题.服务做了变更重新发布了一下就连不上了!~

5、这次更新服务所有的都需要连接zk,只是这个c服务连不上.

那我们就来看看这些服务有什么不同.

ok有重大发现!~

这个服务部门的多个服务是分布在多个ip段的,立刻随机选择几个跟报错服务相同网段的服务器,对lvs服务器也是一样各种不通.

总结: 那么不是一个服务不通,而是一个ip段不通!~

迅速查了一下这个ip段的其他线上服务有哪些需要连接zk的,让业务侧查看是否正常.

回复都是: 正常!~

那么以上就是整个现象,各位看官要是你现在还有什么可排查的嘛?

那么基于这个局面迅速又拉网络组的一起探讨了一下问题.

就在这个时候,立刻传来了一个不好的消息!~

线上订单服务不好使了.

报无法连接zk,重启后不好使!~

p0级别的业务迅速介入.

发现报错服务是另一个ip段的.跟之前那个报错的业务不是一个段的,没见过这个段呀!~

呦呵!~什么他妈情况?

之前那个业务虽然也是生产环境的业务,但是是个旁系的内部服务.还可以给研究是时间,但是这个线上订单就不行了.

立刻让网络组改变映射关系,将dns的服务域名不在指向lvs集群,直接切换到zk集群.

切换后服务立刻恢复!~

那么现在基本确定就是lvs的问题了.由于业务都恢复了,也可以安心查找问题了.

先来看一下lvs的路由表:

这里可以看到起了三个虚拟子网卡来做路由用的.

那么这三个网卡代表三个网段.

作用就不解释了哈!~以后一起给大家讲.

经过测试凡是这三个段的网络都无法连接到lvs上.这里指的虚拟ip和物理ip都无法连接.关了这个虚拟网卡就可以了.

我曹!~我不是只做了一个么?这个是专门给zk用的呀…咋有三个了?

这个问题等会解释.

那么现在就基本确认了是这个虚拟网卡的问题.

因为已经到了核心问题点,我就不饶弯子了.

linux系统中有个内核参数是 rp_filter

开启rp_filter参数的作用

减少DDoS攻击
校验数据包的反向路径，如果反向路径不合适，则直接丢弃数据包，避免过多的无效连接消耗系统资源。

防止IP Spoofing
校验数据包的反向路径，如果客户端伪造的源IP地址对应的反向路径不在路由表中，或者反向路径不是最佳路径，则直接丢弃数据包，不会向伪造IP的客户端回复响应。

更直观的作用可以看这个图

如上所示，数据包发到了eth1网卡，如果这时候开启了rp_filter参数，并配置为1，则系统会严格校验数据包的反向路径。从路由表中可以看出，返回响应时数据包要从eth0网卡出，即请求数据包进的网卡和响应数据包出的网卡不是同一个网卡，这时候系统会判断该反向路径不是最佳路径，而直接丢弃该请求数据包。（业务进程也收不到该请求数据包）

查看了一下我们的lvs集群rp_filter 这个参数就是配置的是1

将其改成0.

一切恢复正常了.

用老妈的手艺做分割图片!~~

领大家做一次简单的复盘:

1、测试通过了?都测试了什么?

答:我们在做基础环境改造,业务环境也在做另一个迁移项目,波哥设计的测试用例确实也涉及到了跨域访问问题.我们这个测试也只是抽查了大部分业务所属的网段是否可链接.但是这次出故障的却偏偏是几个非常个例的ip段落.测试没有覆盖到.

2、内核参数为什么不对?

答:架构改造的时候申请了一批机器,基础设备组的同学就给了我们三台物理机,但是这几个物理机应该是别的组用过的,别的业务组可能也是好心帮我们做了初始化还原,移交给了我们,所以我们也只是简单的查看了一下机器就接收了.这里的内核参数并没有仔细核对.

3、为什么lvs集群上面我只是一个网段的虚拟网卡,事故发生的时候却又多了两个网卡?

答:这是因为同组的小伙伴把未来要做的其他核心组件改造提前做了,却又没跟我同步信息.所以自己新建了两个网段的虚拟网卡,而我又不知道,所以出问题的机器所在的网段我是一头雾水,因为在我的印象里根本没这方面的变更,而他又始终认为不是lvs的问题…这就没对上…

4、为什么割接完一周才出现问题?

答:这个割接流程是先迭代重启zk,更新zk集群配置以便完成扩容,扩容完成后第三天,才更改dns映射,因为涉及多重方案割接所以采用分步实施.

那么zk的链接是长连接,首次链接的tcp四层握手,需要走我们的lvs的dr模型对链接请求进行转发.后续链接握手成功,如果不主动挥手,就不会有重新握手的申请,那么也就不用走lvs这一个路由,所以出现了老服务虽然也是同段的ip,但是却没有收到影响的现象,然后重新部署,以及某些问题断开了链接,需要重新握手,那么肯定是握不上的.(时候询问了一下,线上的订单业务某些情况需要重启一下,然后发现了该故障).

唉!_{这次故障因为上诉的种种因素的干扰导致波哥这边处理起来也确实是非常棘手.这个沟通、还有细节还需要加强哈!}

这篇文章涉及的知识点可能有些多,但是解决问题的思路还是非常清晰的!~

各位小伙伴,你们在波哥叙述这个问题的过程中是否有判断出响应的问题么?可以私信找波哥聊聊哈!~