如何处理n层架构中的服务器故障？
想象一下，在自动缩放的云环境中，我有一个n层体系结构，并说：
- 一个故障转移对中的负载均衡器
- 反向代理层
- networking应用程序层
- 数据库层
每个层需要连接到下面的层中的实例。
连接层的标准方法是什么，使它们对每层中节点的故障具有适应性？ 即每层如何得到下面的层中的每个节点的IP地址？
例如，如果所有的反向代理服务器都应该将stream量路由到所有的networking应用程序节点，那么它们如何设置，以便它们不会将stream量发送到无效的networking应用程序节点，并且在新的networking应用程序节点联机时可以发送stream量去呢？
- 我可以运行一个将所有configuration更新到所有节点的代理，但效率不高。
- 我可以在每层之间放置一个LB对，所以上面的层只需要连接到负载均衡器，但是如何处理LB死亡的问题呢？ 这似乎将分层A需要知道层B中所有节点的IP的问题分stream到层A中需要知道层A和层B之间的所有LB的IP的所有节点。
对于一些应用程序，如果他们联系下面那个没有响应的层中的节点，他们可以实现重试逻辑，但是有什么方法可以让一些中间件将stream量引导到下一层中的活动节点？
如果我在AWS上托pipe，我可以在层之间使用ELB，但是我想知道如何自己实现相同的function。
我已经读了（简要地）关于心跳和keepalived – 在这里有关吗？ 他们谈论什么是虚拟IP，他们如何pipe理？ 使用它们还有单点故障吗？
像haproxy这样的应用程序负载平衡器。 例如，如果它从Web服务器检测到5xx错误，则可以将服务器标记为失败。 另外，如果服务器三次握手失败，则可以将其标记为失败，另外在客户端继续等待时尝试另一台服务器。
使用keepalived和心跳，你可以有一对haproxy服务器。 如果一方失败，另一方接pipe。
我在这里使用haproxy作为例子，但几乎任何应用程序负载平衡器（又名第4层负载平衡器）都具有这些特性。
你的问题是How do I deal with failures?
答案是Redundancy ，或者更具体一些 
- 创build一组可以完成所需工作的节点。
- 确保他们有独立的电源和networkingpath到您的核心。
- 如果您需要容忍集合中单个节点的故障，请按照所述将集合放在负载均衡器后面。
- 如果您需要容忍负载平衡器的故障，请给它一个合作伙伴。
- 关于单独的电力和networkingpath同样的警告。
- 如果您需要忍受多个节点的故障，请执行
N+S冗余
（多个备件准备好跳入并接pipe）。
您可以使用Amazon ELB（如果您使用的是EC2），使用循环虚拟IP的pf防火墙（或pfsense ）或pfsense各种软件负载平衡工具（这可能是他们来的最佳select具有一些体面的故障检测function，虽然他们确实需要额外的硬件）。
如果您有现金，还有专门的商业负载平衡器解决scheme，如思科的内容交换机或内容交换模块 。
不要忘记在你的testing环境中模拟失败，以确保事情按预期的方式失败。
LB应该监视代理层，并自动删除已经消失的主机（即将stream量redirect到幸存的节点）。
反向代理应该再次使用监视networking应用程序的LB。 networking应用程序应该能够接pipe来自其他节点的会话。
networking应用程序应通过LB连接到数据库服务器。