AWS替代DNS故障转移吗? [英] AWS alternative to DNS failover?

问题描述

我最近开始阅读有关AWS的内容并在其中使用.我对使用该平台可以实现的不同高可用性体系结构特别感兴趣.具体来说，我正在寻找一种可靠的穷人解决方案，该解决方案可以使用最少个服务器来实现.

I recently started reading about and playing around with AWS. I have particular interest in the different high availability architectures that can be acheived using the platform. Specifically, I am looking for a reliable poor man's solution that can be implemented using the least amount of servers.

到目前为止，我对解决HA的主要问题感到满意:负载平衡，冗余，自动恢复，可伸缩性...

So far, I am satisfied with solutions for the main HA concerns: load balancing, redundancy, auto recovery, scalability ...

我唯一遇到的问题是故障转移解决方案.

The only sticking point I have is with failover solutions.

使用ELB似乎很棒，但是ELB实际上在幕后使用DNS平衡.请参阅 AWS的Elastic Load Balancer是否是单点故障?.同样来自Netflix博客文章:从Netflix中学到的经验教训从AWS停运中

Using an ELB might seem great, however ELB actually uses DNS balancing under the hood. See Is AWS's Elastic Load Balancer a single point of failure?. Also from a Netflix blog post: Lessons Netflix Learned from the AWS Outage

这是因为ELB是两层负载平衡方案.第一层包括基于基本DNS的循环负载平衡.这会将客户端带到云中的ELB端点，该端点位于您的ELB配置为使用的区域之一中.

This is because the ELB is a two tier load balancing scheme. The first tier consists of basic DNS based round robin load balancing. This gets a client to an ELB endpoint in the cloud that is in one of the zones that your ELB is configured to use.

现在，我了解到DNS故障转移不是理想的解决方案，正如其他人指出的那样，主要是因为DNS缓存不可预测.例如，请参见:为什么不建议DNS故障转移?.

Now, I have learned DNS failover is not an ideal solution, as others have pointed out, mainly because of unpredictable DNS caching. See for example: Why is DNS failover not recommended?.

除了ELB，在我看来，大多数AWS HA架构都依赖于使用路由53的DNS故障转移.

Other than ELBs, it seems to me that most AWS HA architectures rely on DNS failover using route 53.

最后，浮动IP/弹性IP(EIP)策略在少数文章中突然出现，例如

Finally, the floating IP/Elastic IP (EIP) strategy has popped up in a very small number of articles, such as Leveraging Multiple IP Addresses for Virtual IP Address Fail-over and I'm having a hard time figuring out if this is a viable solution for production systems. Also, all examples I came across implemented this using a set of active-passive instances. It seems like a waste to have a passive for every active to achieve this.

鉴于此，我想问您什么是执行故障转移的更快，更可靠的方法?

In light of this, I would like to ask you what is a faster and more reliable way to perform failover?

更具体地说，请讨论以下两种设置如何在不使用DNS的情况下执行故障转移 :

More specifically, please discuss how to perform failover without using DNS for the following 2 setups:

单独的AZ中的

1. 2个active-active EC2实例.主动-主动，因为这是一个预算设置，因此我们无法承受无所事事的情况.

1. 2 active-active EC2 instances in seperate AZs. Active-active, because this is a budget setup, were we can't afford to have an instance sitting around.

1个ELB在区域A中具有2个EC2实例，1个ELB在区域B中具有2个EC2实例.同样，这两个区域都处于活动状态并为流量提供服务.您如何处理从一个ELB到另一个ELB的故障转移?

1 ELB with 2 EC2 instances in region A, 1 ELB with 2 EC2 instances in region B. Again, both regions are active and serving traffic. How do you handle the failover from 1 ELB to the other?

推荐答案

如果您像我一样是好奇型人物，则可以通过玩ELB来更好地理解ELB.

You'll understand ELB better by playing with it, if you are the inquisitive type, as I am.

在2个可用区中配置的"1" ELB记为1，但部署为2.分配了2个IP地址，每个平衡器一个，自动创建2条A记录，每条记录都有一个非常短的TTL.

"1" ELB provisioned in 2 availability zones is billed as 1 but deployed as 2. There are 2 IP addresses assigned, one to each balancer, and 2 A records auto-created, one for each, with very short TTLs.

这两个平衡器中的每一个都会将流量转发到其相同AZ中的实例，或者您可以启用跨AZ负载平衡(如果每个AZ中只有一个服务器实例，则应该启用).

Each of these 2 balancers will forward traffic to the instance in its same AZ, or you can enable cross-AZ load balancing (and you should, if you only have 1 server instance in each AZ).

这些IP地址不会经常更改，尽管可以推断ELB像其他任何事物一样会失败，但我大概有30个，并且从来没有故意死掉过，这大概是因为ELB基础架构将取代死掉的东西实例并更改DNS，而无需您的干预.

These IP addresses do not change often and though it stands to reason that ELBs fail like anything else, I have maybe 30 of them and have never knowingly had a dead one on my hands, presumably because the ELB infrastructure will replace a dead instance and change the DNS without your intervention.

对于2个区域，除了在 some 级别使用DNS之外，您别无选择.来自路由53的基于延迟的路由可以在正常操作中将人员发送到最近的站点，并在整个区域发生故障时将所有流量路由到另一个站点(由路由53的运行状况检查检测)，但这有点当整个区域不可用时，DNS缓存更有可能遇到问题.

For 2 regions, you have little choice other than using DNS at some level. Latency-based routing from Route 53 can send people to the closest site in normal operations and route all traffic to the other site in the event of an outage of an entire region (as detected by Route 53 health checks), but with this is somewhat more likely to encounter issues with DNS caching when the entire region is unavailable.

当然，在两个应用程序服务器上，使用HAProxy可以轻松弥补使用Elastic IP的单个区域中的部分主动/被动难题.它是一个HTTP请求路由器和负载均衡器(如ELB)，但具有更广泛的功能.该代码太紧，以至于您可以在CPU服务器上的消耗可以忽略的情况下在应用服务器上运行它.然后，具有EIP的实例将平衡其本地应用程序服务器和对等方之间的流量.在整个区域中，如果本地区域已启动，但由于某种原因，应用程序无法处理来自本地区域的请求，则ELB后面的HAProxy可以将流量转发到远程区域中的伙伴. (我使用了这样的设置，通过在来自本地区域的直接Internet路径不起作用时将请求退回到远程AWS区域来提高外部服务的可用性.)

Of course, part of the active/passive dilemma in a single region using Elastic IP is easily remedied with HAProxy on both app servers. It's an http request router and load balancer like ELB, but with a broader set of features. The code is so tight that you can likely run it on your app servers with negligible CPU consumption. The instance with the EIP would then balance traffic between its local app server and the peer. Across regions, HAProxy behind ELB could forward traffic to a mate in a remote region, if the local region is up but for whatever reason the application can't serve requests from the local region. (I have used such a setup to increase availability of external services, by bouncing the request to a remote AWS region when the direct Internet path from the local region is not working.)

这篇关于AWS替代DNS故障转移吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！