Qunar智能多机房链路冗余

背景

当机房出口网络链路出现异常时，面对业务全红的报警，作为运维人员我们能做什么？

解决的问题

如何快速自动检测到问题，并将业务进行自动进行切换呢？如何合理的利用手中的软件、系统、合理的整合成自动切换系统呢？文章通过 Qunar 切换系统来给大家一些思路。

文章目录

系统介绍

这是一张机房出口故障图，两条线代表机房的进出口流量在13：30-14：00机房进出流量都掉到了0，这段期间机房已成为不可用状态。

相信我们在平时工作中肯定会遇到过此问题，机房出口异常带给我们的灾难是毁灭性的，它代表的整个机房内的业务都会受到影响，那我们如何来解决这个棘手的问题呢？

智能切换系统

A: 智能切换系统是当我们idc出口出现异常，可以自动检测异常并将进出流向的流量自动切换到冗余机房，不影响正常使用及访问的系统串联。

这张图和第一张流量图右上角的图就是刚才那张机房出口故障图，此时有了切换系统，我们的流量被按照预先设置好的规则分担到了其他冗余机房上。

进向流量切换

进向流量是指用户访问我们网站及服务的流量，正常情况下用户通过 dns 解析我们的域名地址到达 A 机房访问，当 A 机房出口异常时，检测系统会自动检测出网络异常，触发权威 dns 修改对域名的解析地址，将地址解析到冗余机房上，达到切换目的。

出向流量切换

出向流量则是我们内部服务访问公网服务的流量，正常情况我们会在服务内部增加 proxy 网络正常时，代理地址则是本机房出口地址，当网络异常被自动检测到时，代理地址会被自动更改下发，地址更改成冗余机房的代理地址，这时用户请求会自动加载切换后的代理地址进行访问，达到切换目的。

了解了进出切换的原理那么我们要构建这个切换系统需要具备什么条件？

1.动态周期性的测试；

2.将检测数据进行有效的归类聚合；

3.服务要在多机房部署达到随时可上线状态；

4.要有完善的服务后台支持。

组件说明

第一层网络检测 smokeping 用 smokeping 的 alert 功能将异常数据检测并抛出。

第二层数据聚合归类及分析，我们采用的公司内部监控软件 wathcer 他可以按照我们抛出的异常数据上的标记来将异常数据做有效的聚合归类分析。

第三层应用实际切换层主要包括 dns 管理程序 q-proxy 代理管理程序等等，她的主要作用是当数据分析层判断出当前网络异常时，对应用进行有效的实际切换。

系统串联工作流

由smokeping检测全国检测点 ->

筛选出丢包和延迟异常的数据 ->

将数据按照预先设置的格式打上标记发送到wathcer ->

wathcer按照我们设定的维度将数据进行分类 ->

先计算出检测点到内部网络是否异常，排除机器本身问题导致的检测异常 ->

然后按照机房运营商维度来把数据进行合并，计算出该机房、该运营商的网络质量 ->

当网络异常时进行应用上的自动切换。

smokeping+weathermap 展现效果

weathermap 作为 cacti 的插件，可以更直观的反应出 smokeping 的检测情况。

组件分析

1.异常数据怎么打标记，发到哪?

2.什么样的数据才算异常?

3.什么时候用多指针?

第一点发送数据的问题我们可以通过 smokeping 的 to 来接入脚本，将异常数据抛出到指定的地方。第二点在我们实际运维中根据经验定义了2个异常指标，丢包大于5%和丢包大于10%当丢包大于这个阈值时对我们的业务访问及流量就会造成影响。第三点多指针我们什么时候用？就是当我们网络检测节点足够多，导致我们在1个检测周期无法对所有检测点检测完成时，在日志里会体现，这时我们定义多指针并发的检测来解决这个问题 weathermap 我们需要注意的一点则是他读取 smokeping 的 rrd 文件后生成的图片在 url 中不会自动刷新，需要我们定期脚本去刷新的问题。

我们根据自身需求设置的格式是机房/城市/运营商/丢包/延迟/时间戳的格式来将异常数据标记，这样可以在数据聚合时按照这些维度来区分和聚合，并可以记录下日志留存。

我们按照上一层打好的标记，在机房运营商维度上将本机房同一运营商的数据进行分析，判断出该机房该运营商的网络是否存在问题，当然这点大家也可以按照更细致更适合自己的维度来进行区分，如省市、地区等等...我们每个机房每个运营商的检测点约30个、阈值设置在10个。

分析出当前网络是否存在问题后，那么我们就来到了实际切换层了，这一层会接到上一层得出的结论，如该机房运营商的网络存在问题，则会将该机房该运营商的流量进行切换，切换到其他网络覆盖无问题的机房上实际应用则是 dns 系统，调用 dns 系统的 api 进行切换 dns 分配规则我们是提前预设好的，包括域名多机房解析规则、运营商分配规则等等...

出向访问

因为我们公司 java 服务居多，在这我就用 java 应用举例，来讲解下切换的过程，首先用户在 java 代码的实例中引入 common-http 的 jar 包并在使用 http client 请求时选择代理模式，自动读取 qconfig master 上本机房代理集群的 vip 地址，完成请求操作。当机房出口异常时，自动检测系统将问题机房的代理地址自动更改，java 服务在 request 请求时自动读取了修改后的配置，在 request 时加入 proxy header 头完成请求。

优化过程

那我们可以大致分几个方向来看下优化，第一在检测上，在检测中对异常 icmp 包的优化及定制什么样的丢包率延迟才会影响我们的业务？我们在实际过程总结将异常包分为5、10两种，这是通过观察丢包延迟和我们流量及请求的时间来定义的，在1个周期10个包内，只要有1个包大于等于我们设定的规则，这个检测点就被标记一次，累计2个周期都超过阈值则该检测点被标记异常，同一个运营商同一时间出现10个这样的检测点则标记该运营商网络异常，第二在检测周期上，检测周期直接影响到了故障出现到发现以及到切换的完整时间，那这个周期设置到多少合适呢?我们需要按照我们的切换时间要求及监测点的多少来设置，由于我们达到的是分钟级切换，那么我们的检测周期设置的是 30s ，我们之前说过，检测点过多后会影响到检测周期，这时我们就可以利用刚才说过的设置多指针来解决这个问题。在数据聚合层上我们对运营商异常累计的次数阈值及回调切换的接口上做了优化，我们还需要注意的一点就是要避免源检测点异常导致检测数据全部异常，我们可以通过内部的检测链路来排除或者靠源站自定义检测规则来排除。

那当我们完整的跑通了这个切换流程后就没有问题了吗？答案是不！我们需要对故障时的问题进行记录，需要知道出现问题时路由到底是哪一跳遇到了问题等等，所以我们要记录完整的检测日志，切换日志及故障时的分析日志，并且在故障来临前有预知功能，未到阈值前先对负责人员进行告知。当集群切换到冗余机房后，流量瞬间增长，我们还需要对单个集群的抗压能力进行优化，我们从 heartbeat 到 ecmp 集群改造的优化，使集群有更好的横向扩展能力。

未来规划展望

3个方面

第一、检测，要将检测做到更精确更广，覆盖城市更全，检测的运营商也要更加全面，包括长宽、广电等等...检测的力度要更细致对网络分析要更加透彻；

第二、应用，要做到支持更多的语言，更多类型的服务，能让服务更便捷的接入到切换系统中；

第三、切换，要将切换力度做到更加细致，现在我们是按照机房，运营商来切换，今后会做到按省市地区来切换，只切换覆盖有问题的地区并且在保证切换准确的前提下能不断缩短切换的时间，将我们的系统变得更完善更智能。

背景