我开始开发一个将托管在云中但仍需要比典型的云SLA提供的更高可用性的Web服务。
典型的SLA，例如Windows Azure承诺99.9％的可用性，即每月最多43分钟的停机时间。我正在寻找一个数量级更好的可用性（每月停机时间<5分钟）。虽然我可以配置几个负载平衡的数据库后端来解决问题的这一部分，但我发现网络服务器存在瓶颈。如果Web服务器失败，则客户无法使用整个服务。在不引入另一个可能的单点故障的情况下降低风险的选择有哪些？我看到以下解决方案和缺点：
SRV记录： 我复制整个基础架构（并注意数据库是同步的）并为域添加其他SRV记录，以便绑定访问www.example.com的用户将自动转发到example.cloud1.com或者如果那个离线到example.cloud2.com。谷歌搜索似乎没有任何主要浏览器支持SRV记录，这是真的吗？
第二张A记录： 添加额外的A记录作为替代。缺点： a）在我的托管服务提供商处，我认为没有任何可能添加第二个A记录，但只有一个......这是正常的吗？ b）如果两个服务器中的一个服务器关闭，我不确定用户是否自动重定向到另一个服务器或50％的用户获得404或其他错误
赞赏最佳做法的任何线索
干杯， 塞巴斯蒂安
答案 0 :(得分：1)
实例的可用性，即云提供商指定的SLA意味着＆＃34;实例的运行状况是服务器在Hypervisor或Fabric Controller＆＃34; 的上下文中运行。话虽如此，您需要付出努力并确保实例不会因为您的应用程序/操作系统/或在实例内运行的任何内容而失败。很少有东西倾向于错过，例如那种难以回击的东西 - 忘记配置操作系统更新和补丁。
可用性的基本原则是冗余。更加冗余的应用程序/基础架构更适用于您的应用程序。
我建议您查看 Azure Traffic Manager ，然后重新开始使用您的架构。您无需担心SRV记录或A-Record。只需一个流量管理器的CNAME即可。
交通管理员的想法很简单，你可以告诉交通 经理站在域名后（域名解析） app）然后流量管理器决定在哪里发送请求 考虑诸如Round-Robin，Disaster Management等因素。
结合流量管理器和多区域基础设施设置;你将迈向高可用性目标。
<强>链接
Azure Traffic Manager Overview
Cloud Power: How to scale Azure Websites globally with Traffic Manager
答案 1 :(得分：0)
也许您应该使用DRBD配置corosync集群？ DRBD将确保您复制两个节点上的数据（例如网站文件和db文件）。 作为Web服务器的Apache将在指向域的虚拟IP下可用。如果一台服务器关闭，corosync将在几秒钟内将所有服务移动到第二台服务器。