1、背景介绍
我在 2010 年加入 Qunar 的时候,Qunar 的 IDC 规模还比较小,服务器也只有几百台。随着公司的发展,业务对服务器的需求也越来越大,随之 Qunar 的 IDC 规模也逐渐壮大起来。如果将所有服务器放到一个 IDC 中,虽然管理会简单一些,但是带来的风险也是不可避免的。单个机房出现故障的风险还是存在的,比如电力、网络、空调,都可能影响到业务的正常运行,尤其是网络。大家都知道,一般 IDC 都会有很多个用户,而现在的互联网用户经常会受到攻击烦扰。另一个方面,每个 IDC 的上连运营商的接入方法也是差别的,这又会造成运营商与 IDC,运营商本身网络的抖动给我们的服务带来了不稳定性。为了分担风险,我们实施了多机房部署方案,搭建 Qunar 的骨干网,解决了机房间流量互通和链路冗余问题。
多机房部署方案,解决了单个 IDC 扩容问题,同时提供了多个出口提供服务。但是当遇到单个机房出问题的时候,部分服务还是会受到影响。原有的处理方式:运维同学接收到报警,然后迅速打开笔记本,连接 vpn(进入内网),检查监控影响,做出判断,切流量。整个过程对于一个运维老手,做出迅速判断,至少也要 10 分钟以上了,10 分钟对于像我们这种电商损失就比较大了。同时,运维同学还要保证无论走到天涯海角,都要背着本本,随时做好要战斗的准备。
为了解决这些问题,Qunar 运维自主研发一套故障自愈系统,解决了机房网络的上行和下行两个链路的问题。
2、用户访问-下行
用户访问 Qunar 的产品主要是通过两种方式:客户端和 pc 端访问,但无论是通过哪种访问,都是基于 DNS 系统访问的。由于我们有多几个机房,所以我们在每个机房部署了一套负责均衡系统。
简单介绍下 Qunar 的负载均衡系统。我们原有的系统也主要是以 Nginx 类为作为负载均衡系统,早期的模式也是通过 heartbeat+nginx 模式,如下图:
随着业务的发展,单个 Nginx 成为了瓶颈。后期,我们引入了 ECMP 模式。Nginx 的横向扩展变得非常简单了。
后期,我们还引入了 Openresty 企业版。大家都知道,Nginx 每次加载配置,都需要 reload。而这个过程,会关闭原有的 worker,启动新 worker。这个过程,就会造成部分用户访问失败。而 Openresty 可以做到配置热加载,整个过程对用户无感。同时 Nginx 修改是一个串行的过程,下一次修改还要等这一次的修改完成。随着集群的数量增加,一次配置修改的时间也随之越来越长。Openresty Edge 正好解决了这个问题,它不仅可以对 upstream 进行热加载,同时对其他配置也可以做到热加载。另外,Openresty 还实现了分区管理,使我们串行的工作变成并行而且互补影响,使 OPS 的生产力大大的提高了。
通过这几次负载均衡系统的改造,我们避免了一个集群单节点的故障。但是,单个机房故障点还是存在的。针对用户访问问题,我们主要通过 DNS 解析解决。Qunar 已经开源了 DNSDB 系统,大家可以进入下面的网站了解和学习:
github https://github.com/qunarcorp/open_dnsdb
通过 DNSDB 系统,Qunar 运维就实现一键切换成百上千个域名。DNSDB 系统不仅可以通过 web 操作,并且提供 API 接口。正是有了 API,使我们的自动切换有了可能。我们每个机房都有对全国链路的监控:
上面这个图是每个机房全国网络的监控汇总。单个机房内,实现 30 秒内对全国 100 多个节点的检测任务。通过 watcher 监控平台,当监控阈值报警时,触发 DNSDB API 接口完成对 DNS 域名地址切换。我们设置阈值连续 4 个点有 2 个点报警再触发切换。这个也是一个经验值,可以有效的避免了监控系统的误报问题。当监控连续 20 分钟显示 ok ,触发 DNSDB 系统恢复原有配置。通过这种方式,我们彻底解决了单个机房的网络故障。并且,通过自动故障恢复机制,也避免了由于人为疏忽,造成流量长期不恢复而增加了带宽成本。Qunar 的 DNS 系统也提供 view 和 EDNS 等功能,也为 OPS 调节带宽和改善用户访问质量提供了有力的支持。
3、访问第三方业务-上行
虽然通过 DNS 系统我们避免了用户访问 Qunar 的问题,但是,我们的业务还有访问第三方合作等合作网站的需求。当单个机房出现问题的时候,尤其是 IDC 与上连运营商之间出现问题的时候,我们的业务就没有办法切换到其他出口了。
为此,OPS 和 Qunar TC 组一起实现了一个 IDC 代理模式。IDC 代理解决方案,同样包含三个部分:代理模块部分、qconfig 配置代理部分和监控部分。结构如下:
代理模块,我们选择了使用 squid 作为代理模块。开始我们选择过 ATS 作为代理模块,性能对比 squid 有优势,并且可以利用上多核。但是,测试中发现到一个问题。当一个网站有多个 IP 解析时,如果有一个 IP 出现访问失败,ATS 将不再会去重试第二个 IP,直接返回 502 网关失败。而 squid 在第一个 IP 失败后,会重试第二个 IP。所以我们最终选择了 squid 所作我们代理服务器。为了最大压榨服务器的性能,我们使用了 squid 的多线程模式。我们的一个测试环境:32 核的服务器,squid 使用超线程模式,在压测过程,CPU load 跑满的情况,qps 可以达到 50KQPS。在代理集群,我们同样使用了 ECMP 模式,使整个集群扩缩容都变得非常简单。
有了代理模块,我们还希望能够让业务在单机房故障时,代理能够自动切换,做到对业务透明。由于我们大部分服务是 java 服务,就请 TC 团队帮助开发了一个 http 模块。业务在引入这个模块后,就可以通过我们 qconfig 配置代理模块。
在业务侧,通过 qconfig,业务可以设置集中模式:
开关。通过开关控制是否使用代理。
配置白名单。只有配置了的域名才会走代理。
在运维侧,设置模式会比业务侧多几个组合:
黑名单。配置了黑名单的域名,将不允许走运维的代理。比如,我们会把自己的域名过滤,这样不会造成资源的浪费。
代理规则:可以采取域名、域名+机房、机房和默认规则。通过这些规则的设置,OPS 就可以做到对流量的控制了。
有了代理模块和 qconfig,我们还需要监控系统的配合。这一块,我们复用了在前面介绍的监控系统部分。当出现单个机房故障,我们的程序会调用 qconfig,触发代理规则修改,从而把流量快速切换到其他机房。整个过程,对业务是透明的,服务保持连续。
有了这两套系统,运维同学在休息日的时候,终于不那么紧张了。我希望能够带领运维同学们,继续完善我们的运维系统,让更多的系统能够实现故障自愈,让同学们有更多的时间去研究更先进的技术,有更多的假日时间陪伴家人。
作者介绍:
苗宏涛,2010 年加入 Qunar,目前负责技术保障部运维管理工作,先后带领团队完成 DNS 系统,负载均衡系统和运维自动化体系,分布式存储系统的规划和建设工作。
本文转载自公众号 Qunar 技术沙龙(ID:QunarTL)。
原文链接:
评论