从阅读开始,似乎不推荐DNS故障转移只是因为DNS不是为它而设计的.但是,如果您在托管冗余内容的不同子网上有两个Web服务器,那么还有哪些其他方法可以确保在一台服务器出现故障时将所有流量路由到实时服务器?
对我而言,似乎DNS故障转移是这里唯一的故障转移选项,但共识是它不是一个好的选择.然而,像DNSmadeeasy.com这样的服务提供它,所以必须有它的优点.任何意见?
解决方法
通过’DNS故障转移’,我认为你的意思是DNS Round Robin结合一些监控,即为DNS主机名发布多个IP地址,并在监控检测到服务器关闭时删除死地址.这对于小型,交通量较少的网站来说是可行的.
按照设计,当您回答DNS请求时,您还可以为您发出的响应提供生存时间(TTL).换句话说,你告诉其他DNS服务器和缓存“你可以存储这个答案并使用它持续x分钟,然后再回来查看”.缺点来自于:
>通过DNS故障转移,未知百分比的用户将使用不同数量的TTL缓存DNS数据.在TTL过期之前,这些可能会连接到死亡服务器.有更快的方法来完成故障转移.
>由于上述原因,你倾向于将TTL设置得很低,比如5-10分钟.但将其设置得更高可以带来(非常小的)性能优势,即使网络流量出现短暂故障,也可以帮助您的DNS传播可靠地工作.因此,使用基于DNS的故障转移会违反高TTL,但高TTL是DNS的一部分,可能很有用.
>将服务器放在同一LAN上.
>将LAN放置在具有高可用功率和网络平面的数据中心中.
>使用HTTP负载平衡器在各个服务器故障上分散负载和故障转移.
>获得防火墙,负载平衡器和交换机所需的冗余/预期正常运行时间.
>针对全数据中心故障制定通信策略,以及偶尔出现无法轻松镜像的交换机/数据库服务器/其他资源的故障.
极少数网站使用多数据中心设置,数据中心之间具有“地理平衡”.