本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
活动-备用状态服务器之间的 HA 浮动 IP 模式
浮动 IP 设计模式是一种众所周知的机制,用于在主用和备用硬件节点(媒体服务器)之间实现自动故障转移。为主动节点分配了静态辅助虚拟 IP 地址。在活动和备用节点之间进行持续监控可检测故障。如果主动节点出现故障,则监控脚本会将虚拟 IP 分配给就绪备用节点,备用节点接管主活动功能。这样,虚拟 IP 就会漂浮在主节点和备用节点之间。
RTC 解决方案中的适用性
并非总是可以让同一组件的多个活动实例投入使用,例如由 N 个节点组成的活动集群。主备配置为 HA 提供了最佳机制。例如,RTC 解决方案中的有状态组件,例如媒体服务器或会议服务器,甚至 SBC 或数据库服务器,都非常适合主备设置。SBC 或媒体服务器在给定时间有多个长时间运行的会话或通道处于活动状态,在 SBC 活动实例出现故障的情况下,由于浮动 IP,端点无需任何客户端配置即可重新连接到备用节点。
实施于 AWS
您可以使用亚马逊弹性计算云 (Amazon EC2) 中的核心功能、亚马逊 EC2 API、弹性 IP 地址以及亚马逊 EC2 对辅助私有 IP 地址的支持,在 AWS 上实现这种模式。
要在上实现浮动 IP 模式,请执行 AWS以下操作:
-
启动两个 EC2 实例以扮演主节点和辅助节点的角色,其中假设主节点默认处于活动状态。
-
为主 EC2 实例分配额外的辅助私有 IP 地址。
-
弹性 IP 地址与虚拟 IP (VIP) 类似,与辅助私有地址相关联。此辅助私有地址是外部端点用来访问应用程序的地址。
-
要将辅助 IP 地址作为别名添加到主网络接口,需要进行一些操作系统 (OS) 配置。
-
应用程序必须绑定到此弹性 IP 地址。对于 Asterisk 软件,您可以通过高级 Asterisk SIP 设置来配置绑定。
-
在每个节点 KeepAlive 上运行监控脚本(在 Linux、Corosync 等)上自定义,以监控对等节点的状态。如果当前的主动节点出现故障,则对等节点会检测到此故障,并调用 Amazon EC2 API 将辅助私有 IP 地址重新分配给自己。
因此,正在监听与辅助私有 IP 地址关联的 VIP 的应用程序可通过备用节点提供给端点。

使用弹性 IP 地址在有状态 EC2 实例之间进行故障转移
优势
这种方法是一种可靠的低预算解决方案,可以防止 EC2 实例、基础设施或应用程序级别的故障。
局限性和可扩展性
这种设计模式通常仅限于单个可用区内。它可以跨两个可用区实施,但有所不同。在这种情况下,将通过可用的重新关联弹性 IP 地址 API 在不同可用区域的主用和备用节点之间重新关联浮动弹性 IP 地址。在上图所示的故障转移实现中,正在进行的呼叫将被丢弃,端点必须重新连接。可以通过复制底层会话数据来扩展这种实现,从而提供会话的无缝故障转移或媒体连续性。
使用 WebRTC 和 SIP 进行负载平衡以实现可扩展性和高可用性
基于预定义规则(例如轮询规则、亲和性或延迟等)对活动实例集群进行负载平衡是一种由 HTTP 请求的无状态性质而广泛推广的设计模式。实际上,对于许多 RTC 应用程序组件,负载平衡是一个可行的选择。
负载均衡器充当向所需应用程序发出的请求的反向代理或入口点,该应用程序本身配置为同时在多个活动节点中运行。在任何给定时间点,负载均衡器都会将用户请求定向到已定义集群中的一个活动节点。负载均衡器会对其目标集群中的节点执行运行状况检查,并且不会向未通过运行状况检查的节点发送传入请求。因此,通过负载平衡可以实现基本程度的高可用性。此外,由于负载均衡器以亚秒为间隔对所有群集节点执行主动和被动运行状况检查,因此故障转移的时间几乎是即时的。
定向哪个节点的决定取决于负载均衡器中定义的系统规则,包括:
-
轮询
-
会话或 IP 关联,可确保将一个会话中的多个请求或来自同一 IP 的多个请求发送到集群中的同一个节点
-
基于延迟
-
基于负载
在 RTC 架构中的适用性
WebRTC协议使WebRTC网关可以通过基于HTTP的负载均衡器轻松进行负载平衡,例如弹性负载平衡 (ELB)、应用程序负载均衡器 (
AWS 使用 Application Load Balancer 和 Auto Scaling 为 WebRTC 开启负载平衡
对于基于 WebRTC 的通信,Elastic Load Balancing 提供了一个完全托管、高度可用且可扩展的负载均衡器作为请求的入口点,然后将请求定向到与 Elastic Load Balancing 关联 EC2 的目标实例集群。由于 WebRTC 请求是无状态的,因此您可以使用 Amazon A EC2 uto Scaling 来提供全自动且可控的可扩展性、弹性和高可用性。
Application Load Balancer 提供完全托管的负载平衡服务,该服务在使用多个可用区时具有高可用性,并且可扩展。这支持处理WebRTC应用程序信令的 WebSocket 请求的负载平衡,以及使用长时间运行的TCP连接在客户端和服务器之间进行双向通信。Application Load Balancer 还支持基于内容的路由和粘性会话,使用负载均衡器生成的 Cookie 将来自同一客户端的请求路由到同一个目标。如果您启用粘性会话,则同一目标会收到请求并可以使用 Cookie 恢复会话上下文。
下图显示了目标拓扑。

WebRTC 可扩展性和高可用性架构
使用 Network Load Balancer 或 AWS Marketplace 产品实现 SIP
对于基于 SIP 的通信,连接通过 TCP 或 UDP 建立,大多数 RTC 应用程序都使用 UDP。如果 SIP/TCP 是首选的信号协议,那么使用 Network Load Balancer 进行完全托管、高度可用、可扩展和性能的负载平衡是可行的。
Network Load Balancer 在连接级别(第四层)运行,根据 IP 协议数据将连接路由到 Amazon EC2 实例、容器和 IP 地址等目标。网络负载平衡非常适合 TCP 或 UDP 流量负载平衡,能够每秒处理数百万个请求,同时保持超低的延迟。它与其他流行的 AWS 服务集成,例如亚马逊 A EC2 uto Scaling、亚马逊弹性容器服务(亚马逊
如果启动了 SIP 连接,则另一种选择是使用AWS Marketplace

利用 AWS Marketplace 产品实现基于 SIP 的 RTC