AWS备选方案替代DNS故障转移？

Question

我最近开始研究和尝试AWS，并对可以使用该平台实现的不同高可用性架构特别感兴趣。具体来说，我正在寻找一种可靠的、成本低廉的解决方案，可以使用最少量的服务器进行实现。

到目前为止，我对主要的HA问题：负载均衡、冗余、自动恢复、可扩展性等解决方案都感到满意...

我唯一困扰的是故障转移的解决方案。

使用ELB可能看起来很棒，但实际上ELB在底层使用DNS负载平衡。请参阅AWS Elastic Load Balancer是否存在单点故障？。此外，从Netflix博客文章中了解到：《Netflix从AWS故障中学到的经验》

这是因为ELB是一个两层负载平衡方案。第一层由基本的基于DNS的轮询负载平衡组成。这将客户端定位到云中ELB终端点，该终端点位于您的ELB configured要使用的区域之一。

现在，我已经了解到DNS故障转移不是理想的解决方案，正如其他人指出的那样，主要是因为DNS缓存不可预测。例如：请参阅为什么不建议使用DNS故障转移？。

除了ELB之外，似乎大多数AWS HA架构都依赖于使用Route 53进行DNS故障转移。

最后，浮动IP /弹性IP（EIP）策略在很少量的文章中出现过，例如：利用多个IP地址进行虚拟IP地址故障转移，但我很难确定这是否是生产系统的可行解决方案。此外，我遇到的所有示例都是使用一组主动-被动实例来实现此目的。看起来每个活动实例都需要一个被动实例来实现这个目标有些浪费。

鉴于此，我想问你如何更快、更可靠地执行故障转移？

具体来说，请讨论以下两个设置的不使用DNS的故障转移方法：

1. 2个位于不同AZ的活动-活动EC2实例。活动-活动，因为这是一个预算设置，我们负担不起有一台实例闲置。

2. 在A区域有1个ELB和2个EC2实例，在B区域也有1个ELB和2个EC2实例。同样，两个区域都处于活动状态并提供流量服务。如何从1个ELB切换到另一个ELB进行故障转移？

- Andrei G

Answer 1

如果你是一个好奇心强的人，那么通过使用ELB来更好地理解它是很有帮助的。

当在两个可用区域中配置1个ELB时，将按1个计费，但实际部署为2个。这两个负载均衡器将分别分配IP地址，并自动创建2个A记录，每个记录对应一个负载均衡器，并具有非常短的TTL。

这两个负载均衡器将转发流量到其同一可用区域中的实例，或者您可以启用跨可用区域的负载均衡（如果每个可用区域中只有1个服务器实例，则应该这样做）。

这些IP地址不经常更改，虽然ELB和其他任何东西一样可能会出现故障，但我可能有30个ELB，从未知地遇到过失效的情况，这可能是因为ELB基础架构将替换死亡实例并在没有您干预的情况下更改DNS。

对于2个区域，你只能在某个层面上使用DNS。 通过Route 53的基于延迟的路由，可以将用户发送到正常操作中最近的站点，并在检测到整个区域的故障（由Route 53健康检查检测）时将所有流量路由到其他站点，但是当整个区域不可用时，这可能会遇到DNS缓存问题。

当然，在单个区域中使用弹性IP的主动/被动困境的一部分可以通过在两个应用程序服务器上使用HAProxy轻松解决。 它是一个像ELB一样的http请求路由器和负载均衡器，但具有更广泛的功能集。 代码非常紧凑，您可以在应用服务器上运行它，CPU消耗可以忽略不计。 具有EIP的实例将在其本地应用程序服务器和对等服务器之间平衡流量。 在跨区域时，如果本地区域正常工作但由于某种原因应用程序无法为本地区域提供服务，则在ELB后面使用HAProxy可以将流量转发到远程区域的同伴。（我曾经使用这样的设置来增加外部服务的可用性，通过在本地区域的直接Internet路径不可用时将请求反弹到远程AWS区域。）

- Michael - sqlbot

---

从您的经验来看，我应该理解DNS缓存问题从未成为重新考虑使用ELBs的重要因素？ - Andrei G

我喜欢在两个应用程序都处于活动状态时使用主动/被动HAProxy的想法。如果完美的故障转移是目标，那么这种设置不是比ELB更好吗？ - Andrei G

关于HAProxy，不一定。一个外部进程必须负责EIP本身的故障转移，并且重新映射EIP是快速但不是瞬间完成的。还要注意，被动模式下的服务器也需要自己的EIP，因为公共子网中的每个实例如果向Internet或大多数AWS服务发出任何类型的出站请求，则需要公共IP...因此，故障转移操作实际上将是交换EIP，而不仅仅是移动一个。但是，每个实例上的代理都会使用机器的私有IP与其他应用程序实例通信，当然。 - Michael - sqlbot