1

我开始开发将托管在云中的 Web 服务，但需要比典型的云 SLA 提供的更高的可用性。

典型的 SLA，例如 Windows Azure，承诺 99.9% 的可用性，即每月最多 43 分钟的停机时间。我正在寻找一个数量级更好的可用性（每月<5分钟的停机时间）。虽然我可以配置几个负载平衡的数据库后端来解决这部分问题，但我发现网络服务器存在瓶颈。如果网络服务器出现故障，客户将无法使用整个服务。在不引入另一个可能的单点故障的情况下降低风险的选择是什么？我看到以下解决方案和缺点：

  1. SRV 记录：我复制整个基础架构（并注意数据库同步）并为域添加额外的 SRV 记录，以便绑定访问 www.example.com 的用户将自动转发到 example.cloud1.com或者如果那个离线到 example.cloud2.com。谷歌搜索似乎任何主要浏览器都不支持 SRV 记录，这是真的吗？

  2. 第二个 A 记录：添加一个额外的 A 记录作为替代。缺点：a) 在我的托管服务提供商处，我看不到添加第二条 A 记录的任何可能性，但只有一条……这正常吗？b）如果两台服务器中的一台服务器关闭，我不确定用户是否会自动重定向到另一台或 50% 的用户会收到 404 或其他错误

任何最佳实践的线索将不胜感激

干杯，塞巴斯蒂安

4

2 回答 2

1

当由云提供商指定时，实例的可用性（即 SLA）意味着“实例的健康状况是在 Hypervisor 或 Fabric Controller 的上下文中运行的服务器”。话虽如此，您需要努力并确保实例不会因为您的应用程序/操作系统/或实例内运行的几乎任何东西而失败。几乎没有什么东西是 devops 往往会遗漏的，并且会受到强烈的反击，例如 - 忘记配置操作系统更新和补丁。

可用性的基本公理是冗余。您的应用程序/基础架构更冗余，您的应用程序更可用。

我建议您研究一下Azure Traffic Manager，然后重新设计您的架构。您不必担心 SRV 记录或 A-Record。只是流量管理器的 CNAME 就可以了。

流量管理器的想法很简单，您可以告诉流量管理器站在域名之后（应用程序的域名解析），然后流量管理器根据轮询、灾难管理等因素决定将请求发送到哪里.

结合流量管理器和多区域基础设施设置；您将朝着高可用性目标前进。

链接

Azure 流量管理器概述

Cloud Power：如何使用流量管理器在全球范围内扩展 Azure 网站

于 2014-06-03T10:45:40.463 回答
0

也许您应该使用 DRBD 配置 corosync 集群？DRBD 将确保您复制两个节点上的数据（例如网站文件和数据库文件）。Apache 作为 Web 服务器将在域指向的虚拟 IP 下可用。如果一台服务器停机，corosync 将在几秒钟内将所有服务移动到第二台服务器。

于 2015-07-30T20:13:04.873 回答