CDN网络故障分析

CDN故障处理初见

 

固定问题1：一个客户如何接入使用金山云的CDN加速服务？

CDN业务加速逻辑是通过DNS服务器把需要加速的域名进行CNAME，然后打上ks-com.的后缀，通过该标识可以通过我们的DNS-GSLB调度到边缘结点的cache服务器上，给予访问者提供资源。

所以如果我们想为某个客户进行加速服务的话，需要把客户需要加速的域名通过DNS改成ks-com.后缀的域名，然后网民就会解析到我们的cache节点上了。当然，第一次访问资源时cache上并没有需要的数据，所以cache会向上层节点拉数据，如果上层数据也没有的话，就需要回客户的源站/KS3回源请求数据。所以，如果想让网民可以更快体验到业务加速的快感，我们需要和客户约定，当有重大业务更新时，或者大数据量的业务发布时，需要提前的预加载数据，这样做可以避免众多CDN厂家回源对源站服务器产生较大压力，也可以缩短网民等待时间。

扩展问题1：如何校验cache中的数据不是最新的？

Cache中的数据存储时间是由客户设置的，当数据缓存到期后再次有请求时需要回上层回源站去拉数据，但是如果客户修改某个页面展示，但是缓存还没有到期时就需要手动数据下发，金山云使用的relay作为数据下发和预热。但是我这里想问的是我们如何可以通过自检来判断目前缓存的数据是否是当前客户展示的界面。

1. 定期向客户源站存储服务器比对数据更新时间，如果数据有变更那么相应的更新时间也会不同，可以询问客户是否有数据变动，再进一步确认是否需要手动下发数据。
2. 定期比对数据大小，原理同上。

客户接入加速服务不仅仅只是简单的“内容分发”，更多的是更快的发现和解决业务传输问题。

 

固定问题2：边缘或者上层一台机器故障如何做到自动摘除服务流量，如何手工摘除一台机器流量？

不论是边缘还是上层，凡是提供服务的设备都是由调度机通过访问调度把请求流量调度到服务器上的，边缘设备是由GSLB识别出网民的local DNS ip的归属来判断该网民身在哪个省份，然后通过调度组进行流量调度。

当我们使用GSLB调度流量时，应该提前检测将要被调度的边缘cache提供服务器的能力。此能力包括：网络质量、服务器健康状态（负载能力、服务器故障、nginx故障等）、边缘服务器性能对比。

举个栗子：当北京的网民访问某个域名时，会通过CNAME到我们的GSLB设备上，然后通过localdnsip判断为北京的用户，假如我们用天津、唐山、石家庄、廊坊的节点来覆盖北京，那么GSLB就要首先判断需要提供服务器的这个4个机房到网民的localdnsip或者终端PC的ip延迟如何，进行排列，根据延迟排名增加优先级单位。然后探测cache服务器健康状态，是否都符合提供服务器的要求，设置负载阈值，比如当cpu使用率达到50%时降低优先级5个单位，达到70%时降低优先级7个单位。延迟优先级+健康状态优先级=最终服务等级，然后我们通过服务等级进行流量调度，调度可使用加权轮询机制。

关于手动摘除服务流量，可以直接通过GSLB直接把备选覆盖机房从里面直接拿掉（禁用），这种在进行计算“服务等级”的时候自然就不会计算禁用掉的机房了，也就不会再有新的访问流量过去了，这里之所以说“新的访问流量”是因为DNS有缓存时间，网民客户端比如浏览器也有cookie时间。

 

扩展问题2：如何通过检测手段正确判断优先级/服务等级

关于网络延迟，我们可以开放zabbix接口，通过提取zabbix数据进行延迟计算。也可以通过自身下发指令触发机房设备主动监测到localdnsip的延迟情况。

服务器健康状态需要系统和业务同事鉴别服务器cpu承载能力、连接数、进程数、服务器硬件log报警、状态码告警等。进行数据的收集和判断相应的故障所带来的影响从而设置优先级。

 

固定问题3：边缘回上层如何选择回哪个上层，有什么策略？

边缘节点之所以需要回源就是因为本地没有请求的数据，进而可以大胆判断，上层也有很大几率没有该资源，所以考虑到上层也需要回源的情况，我们需要根据加速域名客户的源站位置来制定回源路径。

这个问题也需要考虑业务问题：

1. 客户域名加速并非全国，而是个别省份。
   1. 这种情况边缘回源就去寻找离客户源站近的上层机房拉数据，这样可以尽可能的降低上层回源的延迟，更快的把数据拉入我们的CDN系统内。
   2. 当首选（手选）上层节点运营商（比如电信）出口出现问题时，可以考虑跳转到其他上层回源，然后拉完数据后再通过其他运营商（联通）传入首选上层，同时备选上层将数据吐给边缘cache上。

 

2. 客户域名加速为全国时。
   1. 边缘节点选择与自己最近的上层机房进行回源，这样可以更快的让上层机房知道数据命中率正在降低，尽快做出回源请求。同时考虑到网络层面的延迟情况，如果在一个省内传输的话肯定延迟会相对较低，省内拥堵情况也比较少。可以更快从源站把数据拉过来，这样在与其他CDN厂家PK时，可以优先“抢到”miss的资源。
   2. 如果首选机房出现故障也可以通过1-b的方式来解决。

 

我们同样需要智能的判断网络质量，服务器健康状态，动态的选择回源路径，原理和“问题2”的解决思路大致相似，通过边缘节点模拟回源路径（在采取回源的同时开启检测进程），icmp的检测往往比下载一个文件更快，所以可以测试得出边缘到上层，上层到源站的延迟总和，对比所有可选上层的所有RTT时间，择优选择回源路径。

 

扩展问题3：虽然可通过icmp检测网络质量，但是有一个漏洞！

这个漏洞就是：有时候测试ping不丢包，可能是因为ping的字节较小，所以导致一个现象是ping的情况很好，但是下载文件的速度却不尽人意。虽然可以增大ICMP字节大小来进一步确认问题，但是相对于模拟下载还是有差距，所以我们可以长期模拟wget进程，目前我看到鹰眼里的“慢速率”是可以展示出下载的情况的。我们可以选择一个小文件，比如几兆的网页文件，通过relay服务器进行wget下载，来判断该节点出口下载速度是否良好。

 

固定问题4：三线上层回源站，如何选择线路，线路故障能否自动摘除，维护过程中的注意点？

此问题其实在“固定问题3”中回答了一部分，这里再仔细思考一下上层回源的具体逻辑，然后找出逻辑上可通过判断什么参数智能的选择和切换。

当有上层节点需要回源站/KS3拉数据的模型中有可能会出现3种故障。

1. 源站/KS3机房到上层节点间的网络问题。
   1. 该情况通过上面的wget监控可以检测到，也可以通过ping的延时、丢包情况来判断出问题，如果出现了网络问题，可以快速进行故障定位。
   2. 结合多个节点机房向源站拉数据，如果其他多个节点到源站均没有出现下载慢、丢包、延迟高的情况，可以初步判断出故障链路。
2. 源站/KS3服务器故障、机房故障。
   1. 如果下载速度变慢的话，进行多个机房测试依然无法定位问题，很有可能是源站出现了问题，具体是网络问题还是服务器问题可以再进一步确定。
   2. 网络问题判断：可借助第三方平台，比如webkaka通过全国多个节点同时ping向目标机房，也可利用我们的鹰眼localdns的数据ping向源站机房。如果全国所有地区到该机房都出现网络问题，可以初步判断为源站机房网络问题。
   3. 服务器问题判断：如果多个上层节点到源站ping不丢包，但是下载很慢，在排除了网络问题后，可以初步怀疑源站服务器负载很可能变高，导致无法提供正常的下载业务。需要联系客户处理。
3. 该上层节点机房服务器故障。
   1. 服务器回源请求过大，或者web小文件导致的响应变多，占据很多资源处理业务请求，导致磁盘io读写达到上限，从而产生下载变慢的情况，这种情况可以通过硬件检测进行判断，比如可通过zabbix监控服务器健康情况。

 

如果判断为源站服务器问题，需要直接通知客户进行处理。

如果判断为中间网络问题或者上层节点服务器问题，可以把回源的请求再吐给边缘节点，告知边缘节点，该上层节点的优先级降低，然后边缘节点再重新发起回源请求，继续计算优先级，进而可通过其他相对服务状态好的上层节点进行回源。

 

扩展问题4：内部程序切换问题，数据测试提取问题。

上层节点如何知道其他节点的测试数据，因为要判断其他上层节点到源站的数据才能分析出下载速度慢属于哪种故障类型。这个需要做一个自动化程序发布测试命令，并收集测试数据。而且需要在很快的时间内完成，否则失去了快速切换的目的，不过就算稍微慢一点，也会比人脑去分析再得出结论会快。

然后通过分析，需要向边缘节点吐回“我这边有故障了，降低我的优先级选择其他上层节点吧”的信息，然后促使边缘节点再次进行计算选择需要回源的上层节点，这个也需要程序来自动判断，这一点可能要麻烦开发的同事了。

 

 

此想法的解决思路来自路由协议启发，类似于ospf树形开销选路。路径检测协议BFD工作原理。

以上CDN业务逻辑观点主要来自“《CDN技术详解》”一书的中的CDN运行原理。

故障处理思维逻辑分析来自于PPT中的“CDN架构介绍”拓扑。