Support

Home > Support > X community > Technical

CDN DNS部署与优化:兼容,快而稳,少而精

单纯的土豆 2017-06-16

从我的工作经历来说是从研发这个角度开始接触DNS的,最初做DNS时,DNS知道的不是很多,只能干巴巴的按照DNS的规范做各种功能,研发工作到一段落后,更多的是参与DNS运维、运营角度上的一些事情,成长为行业专家。自此之后直到去年的才意识到,实际上DNS的各种运维运营的经验很多已经沉淀到DNS的代码层面,下面我就从研发的白盒视角下剖析沉淀在代码里的DNS运维经验。可能时间比较仓促,把DNS关于性能方面的关键点跟大家说一下,而且有一点点的抽象,我尽量能够类比一下方便大家体会理解。

11.png

这个互动大家多少有些接触,这里想说的是,CDN业务环境中,CDN DNS与业务互动关系都是间接的(虚线),这种间接互动关系,几乎不可能构成数据分析数据链,在排查问题的时候经常会出现没头没尾的疑难问题,同时有关CDN DNS优化采用方式多数也被动间接方式。

12.png

这是详细的解析过程,但其实已经高度简化了。一般应用程序然后透过操作系统再访问本地的内网的DNS,像办公网或家庭中无线路由出现,本网DNS基本上变成了一个标配,然后再到本地运营商的DNS里面,然后再到公网里面按照存根逐步解析目标IP。

其实在这个过程中,会有可选的一些东西,比如缓存,在应用程序里面是有缓存的,最常见的是咱们的浏览器里的缓存;还有一些特别的地方,比如Java,在一些Java环境里面也有缓存的。

我们一位同学在做一些探测程序的时候尝试用Java写,而且写完以后跟一般Curl抓出来的结果不一样,有飘忽的差异。为什么?后来发现Jave环境是有缓存的,同时还有IPv4/IPv6协议栈带来的问题,实际上在互联网上IPv6实际服务量很小,作为通用软件环境和操作系统还是必须支持,而且有优先尝试权,其实在DNS后台日志里面,或者无论运营商还是权威角度都有20%-40%的IPv6解析在里面出现。还有办公室环境里面有同事进行web压力测试,没有考虑到一般Server Linux没有DNS cache这一点,测试产生DNS基本上把办公网无线路由上DNS压死了等等。常常相关资料语焉不详,需要仔细梳理每一个环节才可以帮助你定位故障。感兴趣同学可以查看StuQ社区DNS排查技能图谱寻找线索。

DNS部署和优化

现在介绍一下DNS部署和优化方面的事情。分下面几个优化点,一个是域名的集群的形式,还有一般的择优过程,然后是深入BIND的代码从中提取择优的算法然后剖析一下实例,看看DNS在运营商那里是怎么表现的,一般的CDN厂商或者从自己的网站来说是怎么做的。

13.png

首先域名的NS集群形式,比如a.com对应的是NS组织起来的,NS内容本身是一组域名,由另一组域名提供出来真正的IP,这个实际上给了域名两维的自由度,一个域名它的设备组织工作交付给另外一个域名。

14.png

然后这个是Local DNS的择优过程,一般里面会用到平滑RTT的概念,RTT是网络往返的时间,SRTT是经过平滑运算RTT。首先在第一次拿到DNS把SRTT初值为零,然后这个时候选择最小SRTT的NS,得到新RTT,然后更新SRTT,周而复始。

15.png

这个是BIND择优流程,BIND在公网上占到80%的份额,它代表DNS一个通用中规中矩做法。首先初始值SRTT等于零,然后入选在使用的NS它的SRTT乘以70%、RTT占3成进行加权平均得到新的SRTT,同时落选那部分把SRTT衰减2%。如果出现错误异常,要施加一个惩罚,在原有的基础上加200毫秒。但这套算法到底衍生出什么?其实如TCP也有SRTT过程,分析优化相关文章都丰富,但是DNS这个领域像样文章很少,能联系现实业务就更少了。

16.png

这个东西怎么理解呢?可以类比一个问题,上面一堆的公式转化成业务状态是什么样的,我们可以用这个问题类比,假如到新公司没有食堂,中午想出去吃饭,你不知道附近哪个餐厅好吃,那你就一家一家试,然后最终我选择一家吃,吃一段时间腻了再换一家,大概是这样的流程。

17.png

这幅图描述是一个Local DNS访问迅达云DNS RTT序列图,最前方半透明蓝色是LDNS DNS访问RTT汇总,其余是各个NS 的RRT。这里有6个NS,初始SRTT都等于零,这种条件下,每一个NS会被试一遍,记录RTT是多少,然后前面介绍的算法中逐步形成最小的RTT NS占优的状态(绿色序列),同时其他NS SRTT 按照2%的衰减减小,这会让少量的NS穿插访问(非绿色序列),付出少量代价了解其他NS服务状态。 18.png

这个是表达错误惩罚的特征,开始是优势设备(绿色),但是它出了一个异常,按照算法它的SRTT被施加了一个惩罚,SRTT拉升到200毫秒,然后转移到次优的设备占了主导,由次优设备逐步提供解析,然后在程序那最优设备的SRTT衰减下来后重新上升为最优。这个最优(绿色)的时候跟其他设备之间互动过程中,其他设备择优的比例会相对比较少,因为它的RTT低,优势大;而次优的很难镇住其他设备,择优过程中穿插那些比较差的设备的时候比例会更多一些。

19.png 这个是BIND加代码把实际RTT输出的样子,98%递归相乘会产生这样一条斜线,在每一次的解析过程中一直触到设备最低的点再重新跳起来,再一次再跳起来。这里面最优设备出现一次异常,然后被施加惩罚以后,到这个点以后重新获得优势。从访问序列看,一个设备出现失误的时候,惩罚范围将接近200次。

类比一个问题,假设在上海开一个连锁店,店面位置有什么样的考虑,实际上要贴合你客户群的附近选择,其实这个得到也是类似这样的选择。

但是又回到第二个问题,假设我的客户群90%都在上海,我在上海部署4个NS,比如北方部署一个NS,这样按照刚才的算法,上海的NS比例很高,可以进一步提高择优的效果,请问这个合适吗?其实这里DNS同时放一起是一个大忌。比如举个例子,上海机房发生闪断,闪断持续5秒钟,对这个架构的部署影响是:上海DNS记住这4个NS RTT比较小,距离上海很近,北京比较远,大致情况4上海网络状况相似,Local DNS 4个里面随机性轮流做最优,网络闪断发生时最优异常,DNS是无连接的UDP协议通信,只能等超时,一秒钟后尝试次优,其实还是上海同一机房,等待一秒换第三个,同样没有反应换第四个,最后选择北京成功解析,整个过程耽误很长时间。另一个方面可能需有些算法功底了,实际上多部署上海实际强化优化效果,是对抗指数算法,并且还是做分母。假设为上海北京比例1:50,优化可能效果1:48,优化效果非常有限;但对于北京,额外增加3个次优设备,次优概率增加近3倍,负面影响很大。从性能角度讲不建议同节点部署多个DNS。

20.png

上图是我手绘示意图,辨识一组NS的访问频度,如何用理论帮助你去改善你的系统,其中黑色的这部分在自由过程中Local DNS大家不会愿意选它这样的设备,像这样的设备就可以去考虑淘汰掉或者是找一个更合适的网络节点;还有一个是特别在高峰期出现这样的现象,访问量逆趋势出现凹坑(红),一部分转移另一个节点(绿),中通常是节点网络质量导致,RTT增大或丢包所致,另外也可以帮助发现互补设备,决策优化方式。通过观察这些数据逐步调整DNS的布点的位置,能够去提高DNS解析的速度。

21.png

说了这么多,总结一下DNS的选定原则,当然是偏性能的,第一个是兼容并包,部的DNS设备必须放在一个互通互联相对比较好的作用,比如一些教育网互通互联比较差的时候,就是给整个DNS里加了一个猪一样的队友,会拖累其他地方的解析。但是这个可以考虑的覆盖面是像北京、上海、广州等必须在全国能用的IP。另外一个是快而稳,这个算法里面如果经常或哪怕零星出现错误,就会施加一个比较大的惩罚,稳和快一样重要。另外一个是多个NS在一起的时候,每加入一个次优设备,大约会分散掉3%、5%的量,如果把设备堆的过多,实际上速度也会因为这个而被拖累,所以要做少而精的集群。

22.png

我今天就讲这么多,这是我们的技能图谱,由这个发起的项目,特别是云解析的过程如果能够进行一次整理,整理这个过程不像是写一篇大型的文章,其实整理的这个代价不是很大,也可以帮助新的行业从业人员能够梳理一下自己的知识面,查缺补漏。(注:由李孟贡献的DNS排查技能图谱1.1版已上线 https://github.com/TeamStuQ/skill-map/blob/master/data/map-dns-troubleshoot.md 图谱说明:DNS作为互联网的基础服务,已渗透至互联网应用各处,并与相近业务交织在一起。本图谱除了多角度梳理展示DNS服务的互动形式及作用位置,主要帮助遇到DNS问题的同学缩小排障范围,为疑难问题提供分析线索。)

问题解答

提问1:刚才我看三个原则里面,每一个对于DNS布点的网络质量要求非常好,这样性能就变好了,但是那种互连互通基本上做不到这种,这点怎么选择,比如西藏移动用户,或者新疆电信用户,那我要不要加当地的节点?

李孟:这是一个很好的问题,这个地方由于演讲篇幅的原因,我只能把这一部分内容跟大家分享的,迅达云边缘化的DNS技术没有时间展开。组织域名NS有两维自由度,也就是一个域名是由另外一个域名组织起来的,另一个域名提供具体DNS设备IP,同时这个域名也是可以有智能行为的。但是也因为DNS有协议规范,这样的配置是受到一定限制的,不是每个组合可以用,还是要淌很多坑才可以达成的。

提问2:BIND作为一个比较大而全的开源软件,对于中小企业用性能还蛮好的,但是在业界包括在我这么多年以来实际的使用当中,性能这一块并不怎么样,我们作为云提供商甚至CND,肯定会遇到DDOS包括域名的攻击。

李孟:关于BIND,开场是提到DNS里面的运维或者运营的经验方面以代码形式体现的载体,实际上很多DNS协议本身建议实现就是摘录BIND的代码,所以BIND作为DNS研究的一个对象,如DNS面临很多运营商和客户的问题投诉,在分析的过程中,很多时候都翻一下BIND的代码逻辑分支是怎么样的,毕竟DNS协议有几十个组成,要自己整理很难,但是BIND提供一个比较简练的方式,一个BIND几乎把所有DNS协议融合在一起,特别那里几个分支的步骤先做什么后做什么,最后做什么才能满足那几个协议的要求。

提问3:我接触几家DNS厂商,大部分是效果已经很差了,但是DNS没有及时切,我们通知供应商说这个节点太差了要他们下线。

李孟:你说不是DNS本身问题,是DNS指向的IP问题,那个是CDN监控探测上的事情。


转自http://www.cloudmeetday.com/?id=13

Please and then reply

I want to say

Back to top
WeChat

Scan with WeChat, follow CloudXNS official account

>
QQ
Sina Microblog