SpeedyCloud李孟：CDN系统中的DNS设计与开发

作者简介

李孟

现任SpeedyCloud研发总监，目前主要负责资源调度系统的设计与研发工作，为迅达云一站式云服务平台提供技术支撑。 
李孟曾在蓝汛就职7年，专注于CDN、GSLB及其衍生领域研发与实践，是蓝汛自主研发CDN、DNS的第一人，在研发与运营分析过程中积累了丰富的行业经验。

导读

随着 CDN 的普及，人们对CDN与DNS的认识越来越深入，但是始终有两大问题一直困扰着人们，即性能与调度 。具体来说主要表现为以下两类问题：

1.如何评估各种业务场景下需要什么指标水平的 CDN 与 DNS？

2.CDN与DNS如何表达流量调度？

李孟试图通过本次演讲来解决人们的这些疑问，并从以下4个方面来做全面的分析：

 

1. 智能DNS解析

业务形式



CDN 服务的过程如上图所示，在客户选择使用 CDN 之后，客户可以将自己的域名通过CNAME方式指向 CDN 提供的域名上来，这样可保证客户域名和 CDN域名的彼此独立性，这个过程是通过 DNS 来完成的。

CDN、DNS的支持协议标准



RFC 1035 是87年的协议，最后是ECS。一个月前ECS出了04版，大家会发现04版和03版之间有少量的修饰语变化，意味着不久以后ECS将成为一个真正的DNS协议，现在做CDN如果不支持ECS就落伍了。BIND是全球使用最广的DNS服务，一年前它的开发版已支持ECS。

权威DNS通信特点



如上图所示的典型报文特征，绝大多数是单包请求响应。如果不是自身报文过大，一般是2个9的访问，基本上由单包完成，一来一回是小包，如果你域名是如a.cn一样简短，甚至比64个字节还要小，则需要往后补充一个空白位到64。

DNS在访问权威时，要求每次访问的端口号不一样。其业务特征是，延迟敏感和分布式部署

系统消耗特征



DNS 属于IO密集型和CPU密集型双高的业务，因为DNS协议从特征上类似UDP或SMTP，从处理上，是一些像处理HTTP和字符串压缩，两者结合后，就变成了 CPU 密集型的情况。

2. 域名解析过程



终端与Local DNS交互特征



CDN 中 DNS 调度是基于用户所使用的 LocalDNS 的，符合实际应用的场景。本地终端用户群和Local DNS终端用户群两者并不重合，会导致调度时，你在Web服务器或统计时的访问和在LocalDNS定位上存在偏差。

Local DNS 与CDN的 DNS 交互特征



目前在大陆环境里，LocalDNS 是运营商占了绝对的大头，可以说在一个城市里，往往只有几组 DNS 决定了区域绝大部分的流量，剩下的可能是大型厂商自己的 DNS 组成的。

从CDN的DNS视角，它稀释了热点，可以说少量的请求决定了绝大部分的流量，大量请求的流量是微乎其微的。

LocalDNS与智能DNS集群交互特征



在流量调度和CDN设计时，需要非常细致地考虑这个环节。LocalDNS内部有一定的算法，大家可以看一下BIND或OpenDNS，这两个算法类似。

LocalDNS择优选择

择优选择是依靠IPT。当LocalDNS发出一个请求，给一个集群里的某台设备，然后在解析中记录IPT时间，根据IPT概率性的选择，而不是100%。离我最近的会以最高的概率使用，低的会以较低的概率使用。

流量调度

每个DNS获得的访问是不对等的。北京的LocalDNS访问集群时偏向北京，天津的设备会倾向于访问北方，广州的设备倾向于访问南方，上海的设备则南北都有。

集群择优实例



试验做法是架构标准的BIND。你可以关注某厂商或关注自身的DNS，通过抓包分析往返时间。当LocalDNS开始启动时，因为不知道哪台机器好，每个机器试一遍，顺序是被打乱的，试完后发现IP1设备是最好的，然后以大概率的形式使用这台DNS。你会发现NS发生了一个小失误，它的解析高了一点点，就被别人抢了。这个地方也是高了一些，解析就被别人抢去了……说明它对解析的速度是高度敏感的。

高延迟情形下的惩罚实例



我的客户隔了一个LocalDNS,然后访问到我的权威，如果我的权威访问慢，有一个客户倒霉，访问是200毫秒，当后续的用户过来，对LocalDNS就有排斥心理，这是大家都理解的概念。但是LocalDNS有一个择优行为，当你此次访问代价被客户端稀释，下一次访问时你最优的设备就被替换掉，你需要长时间访问这个次优的设备。

解析延迟敏感。最小的解析两三毫秒的设备，中间发生了一次失误。设备转入次优平台，次优经过一段时间的磨合，当你的域名有效期是1小时的话，1小时工作1次的话，时间就过去了。

持续地为次优的设备服务，而次优设备与其它设备之间的差距较小，未来解析会比以前解析提高很多。

3. 性能要求



高品质DNS软件的性能特征



只有一个标准：跟本设备上的ping值保持一致。
我做调研和工作时，就是选用一台设备的ping值和DNS返回时间的差距，来判断服务器的质量情况。

性能评估



经过LocalDNS的cache缓存后，即使大型互联网网站，到权威上的解析量也非常少（1000QPS一下），主流DNS是10万左右的量级，甚至可以到50万的量级，可以支撑一个相当大的业务。但另一方面DDoS基本10G以上的，其业务规模和攻击防护的数量级的差别非常大。

设计DNS系统时，你应考虑面向什么样的开发诉求？比如是设计一个高灵活性低速DNS搭配第三方安全产品，还是设计特殊架构超高性能DNS。

评价性能时，在线的速率与你测试的速率经常容易出偏差。举个例子，假设公司有一个域名，它的TTL是1个小时，也就是LocalDNS它会缓冲1小时，一个小时内不会再访问该权威；另外CDNDNS会结合LDNS的特征，根据LDNS和域名两个条件找到对应的数据。这使对应数据至少需要相隔1小时才会被再次使用。另外权威是一个集群系统，LDNS不一定会访问同一台设备。

我们知道计算机体系架构中包括存储、CPU和软件，会普遍存在根据使用状况的将数据把它从下面慢速的装置上提上来各级cache架构，相反的不使用的数据会逐渐从cache中淘汰下去。实际上我们做测试时，标准的linux和标准的BIND，没有采取任何特别的优化，做测试时，也会差距70%或50%。建议设计开发的DNS服务达到什么量级时，需要预留足有性能空间。有条件建议采取线网真实回量的方式，而且时间需要足够得长，通过回量的方式测试性能。对于DNS使用的算法、存储等，需要额外考虑随机提取的效率情况。

性能测试



性能测试的工具
前两个是DNS软件，第一个是BIND自带的工具，可以进行全速测试，第二个可进行定量测试，第三个是tcpreplay回放的方式测试性能。

性能评价的误区



评价权威DNS主要性能指标是QPS，不是并发。对于并发也与WEB、DB等有显著区别。

我们测过BIND高压时的情况，基本上是攻击一撤服务就恢复。成熟的DNS往往是快速把超量的服务请求丢弃掉，避免堆积并发。

我也跟踪去年.cn受到攻击时，最严重时发现解析成功率只剩下1%左右，即使这样的状况，少量的成功解析延迟只有几毫秒。对于WEB处理大并发处理时，拖一秒或许没问题，但DNS必须实时应答，终端对LDNS容忍只有1秒，LDNS对权威DNS容忍只有0.8秒。还有就是CDN的DNS是CPU密集型的业务，一旦出现超量的访问，会受限于CPU处理能力越堆越多。这种情形应果断丢弃掉，避免高压后导致一系列的问题，量力而行保持低延迟处理。



使用前2个工具来做性能评价，当然研发时可以做版本之间的性能比较，但用来预期线上性能指标达能达到什么程度，这个就不太合适了。

LocalDNS的变化

大陆环境，一个大型的活跃LocalDNS在数千个左右，还有一个很长的长尾，加起来有十几万的规模。它的变化使用这种测试很难达到。一些安全原由，LDNS访问权威DNS的端口是随机变化的，也就是LDNS访问五元组完全不重复。而前两个工具，启动时用的哪个端口就一直用这个端口，这种无法真实体现设备网络底层的消耗。

工具配合节奏

前两个工具默认并行十个请求，等你应答了，再发出下一个请求，每一个线程是温和的配合DNS节奏打压测试。但互联网不是这样，出现发出一万QBS就是一万QBS，即使你应答跟不上，它并不会减少。

另外DNS里存在人为的波动，包括周期性的探测、网页爬取及搜索引擎爬取，平均值和瞬间峰值有相当大差距。

网络选型IO



网络选型I/0的点，IO大致的数量集。
值得一提的是DNS绝大部分访问时没有连接状态，你发出一个请求，我给你一个应答请求，从底层看裸包和DNS报文之间的差距只是多了这一截，即使失去协议栈开发DNS服务难度也是可控的。

新近出现的DNS存储



新近出现的DNS存储叫LMDB，是OpenLdap的基础存储，它对读数据进行高度优化。所列DNS软件可以达到70万QPS水准

负载均衡的选择



很多负载均衡则面向有连接的状态，UDP请求过来后，因为不知道什么时候结束，需要维持一段时间连接直至超时。但DNS是小包单包通信（类似ping），维持连接意义不大，无谓的消耗负载均衡资源。

处理高性能DNS场景里，建议采用交换机和路由器作为负载均衡设备，对DNS设备构造『等价路由』 均分流量，它的速度就是交换机和路由器的三层的吞吐指标。

4.智能CDN与DNS流量调度



实例分析


优化前，左侧图例是3个IP一个一个给的效果，DNS调度时给A一次，给B一次，给C一次，就像发扑克牌一样看起很均衡，但看到图中流量抖动达到60%。为什么会发生抖动？跟前面提到的LocalDNS的规模差距非常大，这个例子在广州，大型LDNS就是十几个，分IP时易出现偏差，看细节时会发现这是此消彼涨的。DNS表达流量调度时，会直接影响后期的调度，探测到什么样的值，会调配多少流量。

调度参照2个指标：精度和准度。
当你设计调度模式时，需要注意调度的精度和准度。精度和准度特征会导致你后期调度系统的风格不一。但精度高不一定准度高，DNS里面的配置数值与你的调度流量是有偏差的，比如你在DNS里的配置是1：1，但你表现出的流量是5：1。

准度好的调度表达方式，容易规划预测流量，DNS表达50%流量就会是50%，后面提及准度好大部分算法以牺牲精度为代价的。

调度的判断依据


DNS调度时，慎重使用DNS统计数据作为流量调度依据，使用它们试图达成流量调度，效果是不可预期的。

延迟特征

整体上还有规律可遵循，但不适合把数据都汇总到一起，如果依赖中央数据交互与DNS低延迟特征冲突，无法做到高效的快速应答。


常常采用固有属性作为调度参考，比如一个IP属于哪个城市？一个IP属于哪个网络？无论Local DNS选择哪个权威DNS都会相同结果，调度精度保证的。

采取无状态的属性达到其流量调度的目的，比如采取IP的Hash值，如果hash值是“0”分配策略A，Hash值为“1”分配策略B。还有随机值，其效果是无状态的，这像投掷硬币的反正面，无论用谁的手100枚硬币高概率平均起来是50%和50%，虽然这个数值会有些抖动

一个值得一提是调度表达特征是被继承的，有时很隐蔽。

一个常见场景是某客户会选择2个CDN厂商，他也有自建CDN系统，它做的是分流角色，将流量均分，一半域名解析给CDN A，一半域名解析给CDNB，从客户到达均分目的效果不错（1000枚硬币的反正面基本可以稳定500上下个）。但CDN厂商在其内部将调度细化到省，市时，比如深圳市，用户上游分时就把深圳市的LocalDNS分成了两个不断漂移的两半（10枚硬币的反正面很难稳定在5：5））分给了CDN厂商，这就让厂商继承的是这种不稳定因素。

如果云厂商遇到上面常见场景，这种大幅波动会干扰云平台的服务效果，需要安排额外冗余资源，对于云客户常见就意味购买更高配置应对波动。