DNS故障转移的AWS替代方案？
我最近开始阅读和玩AWS。我对使用该平台可以实现的不同高可用性架构特别感兴趣。具体来说，我正在寻找一个可靠的穷人的解决方案，可以实现使用最少的服务器。
到目前为止，我对主要的HA问题的解决方案感到满意：负载平衡、冗余、自动恢复、可伸缩性...
我唯一的症结是故障转移解决方案。
这是因为ELB是一个两层负载平衡方案。第一层包括基本的基于DNS的循环负载平衡。这将使客户机到达云中的一个ELBendpoint，该endpoint位于您的ELB被配置为使用的区域之一。
现在，我了解到DNS故障转移并不是一个理想的解决方案，正如其他人所指出的，主要是因为不可预测的DNS缓存。参见例如：为什么不建议DNS故障转移？。
在我看来，除了ELB，大多数AWS HA架构都依赖于使用路由53的DNS故障转移。
>
2例分离AZS中的活动-活动EC2实例。主动-主动，因为这是一个预算设置，我们不能让一个实例坐在那里。
区域A中有1个ELB和2个EC2实例，区域B中有1个ELB和2个EC2实例。如何处理从1个ELB到另一个ELB的故障转移？
共有1个答案
如果你像我一样是好奇的类型，你会通过玩ELB更好地理解它。
在2个可用性区域中提供的“1”ELB作为1计费，但作为2部署。分配了2个IP地址，一个分配给每个均衡器，以及2个自动创建的记录，每个记录一个，具有非常短的TTL。
这两个均衡器中的每一个都将把流量转发到其相同AZ中的实例，或者您可以启用跨AZ负载平衡（如果每个AZ中只有一个服务器实例，则应该启用跨AZ负载平衡）。
-
问题内容： 由于群集Redis仍在工作中，Resque中是否有机制可以在主服务器宕机时自动故障转移到Redis从服务器？ 问题答案： 我不这么认为。但是，您可以使用Apache Zookeeper 轻松轻松地实现主选举机制： 您可以将上面的脚本修改为： 使用Redis服务器的IP /端口而不是进程的PID 将redis-cli与SLAVEOF命令一起使用可处理“成为主服务器”，“已更改主服务器”和
-
我们使用MQ作为传递消息的主要路径。这是我们的制度运作不可或缺的一部分。消息代理有时会失败，所有相关的队列也会随之失败。在camel中，有没有一种方法可以启动故障切换，并在其启动时恢复到主故障切换？
-
我正在尝试用6台机器实现一个Redis集群。我有一个由六台机器组成的流浪集群： 运行redis服务器 我编辑了上述所有服务器的/etc/redis/redis.conf文件，添加了这个 然后我在六台机器中的一台上运行了这个程序； Redis集群已启动并运行。我通过在一台机器上设置值手动检查它显示在其他机器上。 我的问题是，当我关闭或停止任何一台主机上的redis server时，整个集群都会停止运
-
我正在使用GCS web仪表板/控制台中提供的传输工具来安排从S3到GCS的备份文件副本。 在GCS传输日志中，它显示UNKNOWN：（显示241个故障中的5个）。失败列表中显示的文件没有什么不同。同样的241个文件在每次计划的传输中失败。有没有地方我可以得到一个实际的错误消息？ 我已经检查过： 在这些失败之前和之后有超过150万成功复制的其他文件。这些失败不是在传输列表的开始或结束，也不是连续的
-
我安装了墨盒，并将其缩放到3个档位。每个的设置为2。在我将从： 致： 现在，在重新启动墨盒后，它看起来一切正常，直到我杀死主人。奴隶们只是坐在那里数着他们上次看到的几秒钟...他们（其中一个）的日志上写着：
-
我们有一个mongodb副本集，其中包含两个实例（127.0.0.1:27017-主要，127.0.0.1:27018-次要）和一个仲裁器（127.0.0.1:27019）。当我使用rs.steppdown（60）从主实例中退出时，它应该成为辅助实例，辅助实例应该成为主实例，所有写操作都应该在辅助实例中发生（退出后的主实例）。但在卸任后，我遇到了一个异常“无法将数据写入传输连接：远程主机强制关闭了