针对DNS RR的常见警告是它不利于高可用性.当1个IP关闭时,客户端将继续使用它几分钟.
负载均衡器通常被认为是更好的选择.
两种说法都不完全正确：
>当流量为HTTP时,如果前一个记录关闭,大多数HTML浏览器都能够自动尝试下一个A记录,而无需新的DNS查找.阅读here chapter 3.1和here.
>当涉及多个数据中心时,DNS RR是分配流量的唯一选择.
那么,对于多个数据中心和HTTP流量,使用DNS RR是确保一个数据中心出现故障时即时故障转移的唯一方法吗？
谢谢,
华伦天奴
编辑：
>当然,每个数据中心都有一个带热备份的本地负载均衡器.
>为即时故障转移牺牲会话亲和力是可以的.
> AFAIK是DNS建议数据中心而不是另一个数据中心的唯一方法是仅回复与该数据中心关联的IP(或IP).如果数据中心无法访问,则所有这些IP也都是不可访问的.这意味着,即使智能HTML浏览器能够立即尝试另一个A记录,所有尝试都将失败,直到本地缓存条目到期并完成新的DNS查找,获取新的工作IP(我假设DNS自动建议到新的数据中心,当一个失败).因此,“智能DNS”无法确保即时故障转移.
>相反,DNS循环允许它.当一个数据中心发生故障时,智能HTML浏览器(大多数)立即尝试将其他缓存的A记录跳转到另一个(工作)数据中心.因此,DNS循环不保证会话亲和力或最低RTT,但似乎是确保客户端是“智能”HTML浏览器时即时故障转移的唯一方法.
编辑2：
>有人建议使用TCP Anycast作为最终解决方案.在this论文(第6章)中解释了Anycast故障转移与BGP收敛有关.因此Anycast可以使用15分钟到20秒完成.
在为此优化拓扑的网络上,可以使用20秒.
可能只有CDN操作符可以授予这种快速故障转移.
编辑3：*
>我做了一些DNS查找和traceroutes(也许一些专家可以仔细检查)和：
>使用TCP Anycast的唯一CDN似乎是CacheFly,其他操作符如CDN网络和BitGravity使用CacheFly.似乎他们的边缘不能用作反向代理.因此,它们不能用于授予即时故障转移.
> Akamai和LimeLight似乎使用地理感知DNS.但！他们返回多个A记录.
来自traceroutes似乎返回的IP位于同一数据中心.所以,当一个数据中心出现故障时,我很困惑他们如何提供100％的SLA.
解决方法
但这并不是DNS可用于全球高可用性的唯一方式.大多数时候,具有不同(技术)背景的人很难沟通.
最好的负载平衡技术(如果钱不是问题)通常被认为是：
> Anycast的全球“智能”DNS服务器网络,
>和一组全球分布的数据中心,
>每个DNS节点实现Split Horizon DNS,
>以某种方式监控“智能”DNS节点的可用性和流量流,
>以便用户DNS请求通过IP Anycast流向最近的DNS服务器,
>此DNS服务器通过“智能”水平分割DNS为该最终用户分发最近/最佳数据中心的低TTL A记录/ A记录集.
使用Anycast for DNS通常很好,因为DNS响应是无状态的,几乎非常短.因此,如果BGP路由发生变化,则极不可能中断DNS查询.
Anycast不太适合更长和有状态的HTTP对话,因此该系统使用水平分割DNS.客户端和服务器之间的HTTP会话保持在一个数据中心;它通常无法在不中断会话的情况下故障转移到另一个数据中心.
正如我在“A A Records”中指出的那样,我称之为“DNS Round Robin”的东西可以与上面的设置一起使用.它通常用于将流量负载分散到每个数据中心的多个高可用负载平衡器上(这样您可以获得更好的冗余,使用更小/更便宜的负载平衡器,而不是压倒单个主机服务器的Unix网络缓冲区等).
So,is it true that,with multiple data centers
and HTTP traffic,the use of DNS RR is the ONLY
way to assure high availability?
不,这不是真的,如果通过’DNS Round Robin’,我们只是意味着为一个域分发多个A记录.但巧妙地使用DNS确实是任何全球高可用性系统中的关键组件.以上说明了一种常见的(通常最好的)方法.
编辑：在我看来,Google论文“Moving Beyond End-to-End Path Information to Optimize CDN Performance”在全球负载分配方面是最先进的,可以获得最佳的最终用户性能.
编辑2：我阅读了OP链接到的文章“Why DNS Based .. GSLB .. Doesn’t Work”,这是一个很好的概述 – 我建议看一下.从顶部读取它.
在“浏览器缓存问题的解决方案”一节中,它提倡DNS响应,其中多个A记录指向多个数据中心,作为即时故障转移的唯一可能解决方案.
在靠近底部的“浇水”一节中,它显而易见,如果他们指向多个大洲的数据中心,则发送多个A记录是不冷却的,因为客户端将随机连接,因此经常会变得“缓慢” DC在另一个大陆上.因此,为了使其工作得非常好,需要在每个大陆上安装多个数据中心.
这是一个与我的步骤1 – 6不同的解决方案.我不能提供一个完美的答案,我认为需要来自Akamai或Google之类的DNS专家,因为大部分原因归结为实用技术诀窍今天部署的DNS缓存和浏览器的局限性. AFAIK,我的步骤1-6是Akamai用他们的DNS做的事情(任何人都可以证实这一点吗？).
我的感觉 – 来自在移动浏览器门户(手机)上作为PM工作 – 是因为浏览器的完全破坏的多样性和水平令人难以置信.我个人不相信需要终端用户终端“做正确的事”的HA解决方案;因此,我认为,如果不打破会议,全球瞬时故障转移在今天是不可行的.
我认为上面的步骤1-6是商品技术中最好的步骤.此解决方案没有即时故障转移.
我很喜欢来自Akamai,Google等的DNS专家之一来证明我的错. 原文链接：https://www.f2er.com/html/229902.html
