对于追求可扩展性和灵活性的提供商来说，在云中运行 VoIP 服务已成为一种常见的方法。典型的高可用性解决方案包括一对主动/备用服务器，其中只有一台服务器处于活动状态，其他服务器作为热备份，随时准备接管。
不同的云提供商提供各种机制来实现这种设置，确保在发生故障时自动进行故障切换，或出于维护目的手动触发故障切换。一种常见的方法是使用指向活动服务器的浮动 IP，通过调用 API 更新 IP 映射，实现无缝切换。包括 AWS、DigitalOcean 和 Hetzner 在内的许多云提供商都支持浮动 IP。但是，依赖虚拟化网络协议栈的云环境，如 Microsoft Azure 和 Google Cloud Platform，则不提供这种功能。
在本文中，我们将探讨在 Microsoft Azure 中部署 VoIP 的另一种高可用性策略，以及如何在不依赖浮动 IP 的情况下实现无缝故障切换。
VRRP
要实施主动-备用高可用性设置，需要一种机制来指定一个节点为活动节点，同时持续监控其健康状况。如果出现故障，必须提升一个新节点来接管。这种行为通常由 Keepalived、Pacemaker 和 Heartbeat 等工具管理，所有这些工具都依靠 VRRP（虚拟路由器冗余协议）来监控节点状态，并确保在任何给定时间内只有一台服务器保持活动状态。
在正常情况下，VRRP 通过多播网络运行。但是，大多数云环境都禁止多播流量，以防止不必要的网络泛洪。为了绕过这一限制，VRRP 必须以单播模式运行，允许节点直接通信而不依赖多播。这就是 Keepalived 守护进程特别有用的地方，因为它支持单播 VRRP，即使在网络配置受限的云环境中也能实现可靠的高可用性。
Azure 负载均衡器
当客户端尝试访问平台时，它通常使用完全限定域名 (FQDN)，该域名最终解析为 IP 地址 – 即平台的入口点。在支持浮动 IP 的云环境中，基础架构会自动将流量转发到通过 API 公布的指定活动节点。但是，由于Azure 不支持浮动 IP，我们需要一种替代方法：利用Azure 负载平衡器(Azure Load Balancers)来管理流量分配和故障转移。
如图所示，Azure 负载均衡器充当入口点 IP，以主动-主动方式在多个服务器之间分配传入流量。但是，由于我们的目标是实现主动-备份设置，因此我们需要修改此默认行为。为了实现这一点，让我们仔细看看Azure 负载均衡器的工作原理并探索必要的调整。
配置Azure 负载均衡器时，您将定义一组能够处理传入流量的虚拟机 (VM)。每个节点都分配有一个HTTP 探测器，用于定期检查其可用性。我们将利用这种内置的健康检查机制：我们将配置HTTP 端点来查询监控Keepalived的小型 HTTP 服务器，而不是探测通用服务。该服务器将确定节点是否处于活动状态 -如果是，则返回200 OK ，如果不是，则返回 503 Service Unavailable 。
因此，通过使用Keepalived跟踪活动节点并将此信息公开给Azure 负载均衡器的健康探测器，我们确保流量始终定向到一个节点，即活动/健康节点。
局限性
这种解决方案在理论上是可行的，但在实践中，事情并没有那么简单。探测不能连续进行。在 Azure 中，最小探测间隔为 5 秒，而触发故障切换所需的最小不健康响应数为 2。这意味着，要发生故障切换，至少需要 10 秒，最多 15 秒–对于某些应用程序，尤其是那些需要近乎瞬时故障切换的应用程序来说，这种延迟可能会造成问题。
此外，探测并非在所有节点上即时完成。因此，Azure可能会在某个节点崩溃之前探测该节点，将其标记为活动节点，然后探测另一个节点并发现它也处于活动状态（由于故障转移）。这会创建一个小窗口（大约 10 秒），在此期间平台可能有两个（或可能更多）活动节点。为防止出现问题，您需要确保您的服务能够在应用程序层处理此问题。具体而言，如果在此短暂时间内无意中将流量路由到备份节点，则应将备份节点配置为返回503 服务不可用。
结论
总之，在项目设计阶段早期评估云提供商至关重要，因为它会极大地影响您构建产品的方式。像 Azure 这样的云环境缺少某些功能（如浮动 IP），需要采用替代策略来实现高可用性，例如利用负载平衡器和自定义运行状况检查。提前了解这些细微差别将有助于确保您的系统保持弹性、可靠性并能够满足您的正常运行时间要求。
译自：https://blog.opensips.org/2025/02/06/high-availability-for-voip-in-microsoft-azure/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/55745.html
