对于负载均衡调度器后端的多台实际服务器,我们完全可以通过监控系统来实时了解它们的状态,一旦发现某台服务器出现故障,这时候就需要立刻将它从调度策略中拿掉,也就是暂停指向该服务器的DNS记录,以免用户访问到发生故障的服务器而感到莫名其妙。
对于基于DNS的负载均衡系统,要做到这一点的确让人非常头疼,因为有一个现实的问题是,我们一般不会将DNS记录的TTL设置为0,这使得所有对DNS记录的修改都需要一定时间才能生效,比如一个DNS记录的TTL为3600秒,那么对它的更新最多要过一个小时才会生效,这是我们无法容忍的,当然,用户更无法容忍。
另一方面,如何在意识到故障后的第一时间修改DNS记录,也是我们需要考虑的问题,在迫不得已需要容忍DNS记录更新延迟的情况下,我们唯一能做的就是尽早修改DNS记录。
听起来一点也不难,也许你为站点搭建了专用DNS服务器,那么你可以通过修改配置来快速完成任务,如果你是在使用第三方DNS服务,也没有关系,通过域名管理平台同样可以完成DNS修改工作。但是,这些都得依赖人力,的确,它们显得不够快速和自动化,关键的时候时间就是一切,特别是当需要和监控系统集成实现自动故障转移时,这些方法都显得力不从心。
也许你听过动态DNS,这其实是DNS协议的一个特性(Standard Dynamic update DNS, DDNS,RFC2126),它允许DNS服务器开放特定的服务,为我们自动化远程修改DNS记录提供了可能。
这让我想起了现在几乎所有宽带路由器都支持的一个功能,那就是动态域名解析,你还有印象吗?当你的主机使用动态IP地址接入互联网,并且你希望将某个域名指向这台主机时,所谓的动态域名解析便发挥了作用,它做的事情很简单,就是在每次IP地址变更时及时地更新DNS服务器,当然,一定的延迟仍然是在所难免的,同样是因为DNS记录的TTL。
利用同样的思路,当我们监测到某台实际服务器发生故障后,便可以通过动态DNS协议来迅速修改DNS记录。


codecraft
11.9k 声望2k 粉丝

当一个代码的工匠回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧,这样,当他老的时候,可以很自豪告诉世人,我曾经将代码注入生命去打造互联网的浪潮之巅,那是个很疯狂的时代,我在一波波的浪潮上留下...


引用和评论

0 条评论