本帖最后由 常鸿 于 2022-9-14 22:15 编辑
在一次测试产品去到某客户的现场,测试的产品不是重点
过去的时候,客户的信息部正在激烈的讨论着什么问题,没有及时跟我对接开展测试,我也就在一旁听着。 发现他们在讨论关于外网链路和域名解析的问题
大概是这样的,昨天他们的一个链路出现了故障,但是这个链路提供的域名服务没有及时的下线,导致了部分用户访问应用出现问题,然后呢进一步了解到,提供链路负载和域名解析的是同一个产品,就是咱们的负载均衡 刚好我对负载也略懂一二,就凑上去研究了一下
先说一下客户那边的现有配置
链路负载就不说了,有手就会配
主要是全局负载:
我搞了个模拟环境还原一下问题现场 联通和电信双线链路
同时在运营商上做了MX记录,然后呢向外提供一个域名的解析服务,这边域名就以 abc.com来模拟
然后配置虚拟IP池 用ping进行探测
然后在做一个DNS映射
这么配置,专家来看了都会直呼没毛病
巴特(BUT)
用户的当前配置下,却导致了昨天的业务事故
原因是这样的,AD上 abc.com 解析出来的地址,是AD的公网出口地址,AD同时也做链路负载,内网的WEB服务器通过地址映射到AD的公网出口上
然后这两个公网IP被配置到了虚拟IP池里,这会出现一个情况,就是在虚拟IP池里面的PING探测怎么都是通的,然后假如联通的链路down了,但是联通对应的域名却还会解析给访问者,导致链路不通
我给客户提了一个小小的改动建议
首先虚拟IP池里根据联通和电信 创建两个虚拟IP池 探测方式还是写ping 但是 地址指定为网络出口的网关 电信同理
这个样子,起码就可以根据链路状态来判断哪个地址应该生效,哪个地址不应该生效
但是这个方法,动态就近性又没有那么灵活了,不过AD还有个很强的功能静态就近性
我们来手动配起来
配置运营商地址 然后把访问过来的解析成对应地址
这样从哪个链路访问过来的,就返回对应的哪个地址
再配置两条保底解析策略,应对其他运营商的解析请求,这个目前就只能根据带宽大小,人工来做哪个链路优先了
配置完成后,最大限度上优化了用户访问,以及在链路故障时候,可以灵活切换解析对应地址 |