我们有一个基于Rails的应用程序，部署基础设施绑定到 AWS 。当前架构包括以下层：
有3个SPF：负载均衡器，数据库，媒体服务器。
我的问题是关于冗余，我如何减少SPF：
答案 0 :(得分：6)
我喜欢这些问题，因为它们总是看起来很简单，但事实上它们并非如此。
首先，您的 BIGGEST SPF就是所有内容都在亚马逊上。我喜欢AWS有很多原因，但在所有你需要真正可用性的情况下，你实际上是100％依靠它们来自我攻击。因此，您的第一个计划应该是将您的服务分发给多个提供商（云，VPS或专用）。
我想问你一个问题：如果AWS发生故障，你需要多长时间/可以/将会注意到它，然后对它做些什么，以及你需要多快恢复和运行你的服务？
我问的原因是：A / AAAA记录的DNS负载平衡是一个很好的解决方案，遗憾的是，您无法使用SRV / MX记录设置权重或优先级。这意味着如果AWS变得完全不可用，您将必须快速实现DNS更改以删除IP。如果您的DNS提供商拥有允许该API的API，则 CAN 会自动执行。另一方面，DNS缓存在很多地方执行，可能不值得进行DNS更改，这意味着如果1个IP不可用，您将拥有50％到100％的可用性（假设您有2个A记录），因为如果1st不起作用，某些浏览器可以尝试第二个IP。
在我看来，考虑到AWS的出色正常运行时间，您可以将2个不同的IP（在2个不同的提供商上）分配给您的域名。我认为这比1 IP下降时的0％可用性更好，但是失去50％的请求仍然没有乐趣。
每个提供商可以拥有2个负载均衡器，如果某些实例/服务器已关闭，则允许他们将请求转发给其他提供商。换句话说，您只需要BOTH提供商的功能负载均衡器和ONE提供商的功能服务器/实例。确保选择对AWS没有太多延迟的备用提供商;）
MMM也是一个很棒的工具，但它与Rails没有任何关系。我个人更喜欢在我的所有数据库服务器前面放置一个负载均衡器，让它们处理谁获取请求等等。由于数据库服务器上的数据非常重要，通常最好有一个人的外观当它出现问题时确保一切正常，而不是让工具管理它的可用性，配置等.MMM在很多情况下工作，也许你应该尝试它，看看它是否满足你的需求。我不能说任何坏事。
我对Wowza媒体服务器并不熟悉，但快速搜索解释了一些事情。由于Wowza使用RTSP（UDP 和 TCP），HAProxy是 NOT 解决方案，因为它只执行TCP。另一方面，Keepalived可以执行UDP负载平衡（它使用IVPS / LVS）。事实上，如果您有长时间的查询，Keepalived也应该用于数据库从属负载平衡。
最后需要注意的是，有许多方法可以“推出自己的”类似AWS的服务，例如S3存储。如果您想避免使用SPF但仍需要与AWS服务相同的功能，则应考虑运行开源变体，例如Eucalyptus / Cloud.com / Openstack / GlusterFS。设置所有这些内容涉及很多工作，但是当你可以说：“那么，如果X提供商失败了，那么Y可以接管”。
答案 1 :(得分：1)
以下是一些建议：
1）Load Balancer：使用您的应用程序级负载平衡知识创建两个ha_proxy实例，并根据需要自动创建新实例。通过运行状况检查将Amazon Elastic Load Balancing连接到它们前面以绕过单个ha_proxy故障。当一个失败时，动态混合新的ha_proxy实例。
2）数据库：我认为没有办法在MySQL中处理主要的自动故障转移，但是如果你引入一个层来从副本读取并写入主要数据库，你可能能够保持只读功能如果小学课程已关闭，请起床。
3）Wowza：您应该能够在ha_proxy层后面的多个Wowza实例进行负载平衡，并进行健康状况检查，以便单个Wowza故障不会禁用媒体流
答案 2 :(得分：1)
在Scalarium我们有一个可以显着降低SPF的解决方案，您可以在第12页的Rails in the Cloud看到信息图。
您使用Amazon Elastic Load Balancer在ha_proxy实例之间进行路由。为了获得更高的安全性，您可以将应用程序拆分为多个可用区域。
MySQL master master复制并不是最简单的事情。您可以拥有一个主实例，并在多个可用区域中拥有多个从属。然后，即使您的主人已经离开，您也可以支持阅读操作。我认为无法实现真正的主站故障转移。
ha_proxy应该能够对您的Wowza实例进行负载均衡。