从阅读来看,似乎不推荐 DNS 故障转移,因为 DNS 不是为它设计的。但是,如果您在不同子网上有两个 Web 服务器托管冗余内容,那么还有哪些其他方法可以确保在一台服务器出现故障时将所有流量路由到实时服务器?
对我来说,似乎 DNS 故障转移是这里唯一的故障转移选项,但共识是这不是一个好的选择。然而像 DNSmadeeasy.com 这样的服务提供了它,所以它一定有它的优点。任何意见?
所以,关于 SF 有很多关于使用和任播 IP 很酷的问题。我的方法更实用。要使用这些地址之一,我特别需要什么?
基本上,如果我想使用 Anycast IP 地址,我到底需要什么,从设备到配置部分。
如果大多数浏览器从 DNS 服务器获得多个 A 记录,它们会如何表现?只要可以访问就坚持使用一个IP(并且只有在IP关闭时才使用另一个)?或者他们总是无缘无故地切换?
如果当前的大多数浏览器都坚持使用一个 IP,那么 DNS-RR 作为一种简单的故障转移解决方案对我来说就足够了。
通常,像 Amazon 的 Elastic Load Balancers 这样的负载均衡器使用具有多个 A 记录的 DNS 记录集来提供多个负载均衡器实例,这些实例可以处理到请求端点的流量:
$ dig +short my-fancy-elb.us-east-1.elb.amazonaws.com
10.0.1.1
10.0.1.2
Run Code Online (Sandbox Code Playgroud)
如果我尝试以详细模式卷曲此 URL,我会注意到curl似乎对两个 IP 地址进行循环尝试:
$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.1)
$ curl -ivs http://my-fancy-elb.us-east-1.elb.amazonaws.com | grep -i 'connected'
* Connected to my-fancy-elb.us-east-1.elb.amazonaws.com (10.0.1.2)
Run Code Online (Sandbox Code Playgroud)
curl对记录集中描述的 A 记录进行循环的事实是由curl二进制本身完成的还是 Linux 内核为它做的?
TCP 存在于第 4 层,DNS 存在于第 7 层,所以我想各个二进制文件和库必须实现自己的负载平衡和故障转移:获取给定域名的 DNS 记录集并选择一个 TCP 地址以从那个集合连接到。
我可以合理地期望编程语言、浏览器和像 curl 这样的库会为我在 A 记录上进行负载平衡和故障转移吗?