具有共享数据库的星号集群

具有共享数据库的星号集群

我想从 3 个 asterisk (13.x) 节点构建一个 asterisk 集群,一个在美国,一个在欧洲,一个在亚洲。现在我有 3 个服务器。Asterisk 正在为 sip/iax 用户、队列、cdr、cel、queue_logs 使用实时基础设施。所有用户都在使用 SIP 和软件电话。

数据库通过 Master <==> Master 解决方案进行复制,因此基本上我在所有位置都有“相同”的数据库,并且数据是实时复制的(1-2 分钟,因为服务器彼此相距很远)。

由于队列表已被复制,所以我在所有位置都有所有队列,这是所需的行为,因为一台服务器是另一台服务器的备份。

我想要实现的是,无论呼叫被路由到哪里,到这 3 个服务器中的一个,“系统”都应该能够从该队列中找到可用的代理并响铃到他们的设备,无论代理登录到哪里。为了
复制设备状态,我使用了 Openfire XMPP,但在这里我遇到了一些差异,因为用户在不同服务器上的特定队列中通常具有不同的状态。

即,我在一台服务器上让代理 Adrian 实时处于 IN_USE 状态,他正在通话中,而在另一台服务器上实时处于 NOT_IN_USE 状态。这里的问题是,如果第二台服务器的队列中有呼叫,它将尝试呼叫 Adrian,而不知道他已经在通话中。因此,它会给 Adrian 带来压力,因为它会在软件电话的第二条线路上响铃,而呼叫不会转到其他可用的代理。
我怀疑问题是由于我在所有服务器上都有所有队列,因此状态会因此而改变。
我看到有些设置有一个专用的队列服务器。为什么会这样?是为了避免这种问题还是为了分配负载?

对于具有共享数据库场景的星号群集,推荐的方法是什么?

关于如何实现这一目标,我有什么想法吗?

PS:我已在 sip.com 中启用了呼叫计数器


更新:
这里使用“集群”一词确实不太恰当。我猜最理想的情况是在每个位置上都部署一个由两台星号服务器组成的集群(主动-被动,具有故障转移检测),然后在该层之后部署一个更高层来平衡这些位置之间的呼叫。

我现在面临的主要问题是我有这 3 个位置,并且我在它们之间共享队列(因为它们都有相同的数据库)。假设名为 TestQueue 的队列有 15 个用户,每个位置有 5 个(团队分为 3 个)。我想要实现的是,无论呼叫在哪个服务器上进入队列,都能够到达所有可用的代理(并确定哪些在忙,哪些不忙)。
我不确定我的方法是否可行,或者我应该有一个用于托管队列的星号服务器和其他 3 个用户将注册的服务器(队列服务器和注册服务器之间的 xmpp 同步状态)。

答案1

从您的描述来看,您混淆了集群和负载平衡,这会造成混乱……请选择其中一个。请查看此 serverfault 问答它很好地描述了 Asterisk 的聚类状态。

如果这确实是一个集群,那么备用节点在不使用时不应该运行 Asterisk(没有活动的 SIP 堆栈供代理/中继连接)。尝试使用不同的状态等保持活动和备用节点运行更接近于负载平衡 - 就您尝试实现的目标而言,这并不是真正理想的选择。

主主同步也是集群中的一个错误。如果一个节点发生故障或开始破坏数据,它不应该破坏其他对等节点 - 主主同步会破坏其他对等节点。同样,使用 NFS、iSCSI、DRBD 等共享文件存储都允许一个发生故障的对等节点破坏所有对等节点。

不要寻找“共享数据库”,而要寻找“同步数据”。这样,集群软件就可以控制同步的内容(并且如果对等端发生故障,则避免同步)。

您还忽略了集群的一个主要方面 - 健康检测。您如何知道硬件是否出现故障?中继是否关闭?上游设备是否关闭?代理无法连接?等等。这将如何触发故障转移?转移到哪个节点?

您似乎采用了“硬件层”集群视角,这在必须跨对等体共享状态(例如语音邮件、队列等)的应用层上效果不佳。您的方法最适合简单的操作系统级服务(HA 文件共享、HA 数据库等),而不是应用层服务。请仔细查看上面提到的 ServerFault 问题,此 Voip-Info 网页

如果您在选择方向时遇到困难,请考虑这一点:负载平衡非常适合在无状态系统上实现高容量。10 年前,这对于 Asterisk 来说非常重要,因为单个服务器可以保持打开的同时通道数量非常少。现在,即使是商品硬件也可以保持 500 个通道打开(无需转码),因此负载平衡已不再受欢迎。

具有托管状态的集群现在是关键呼叫中心的标准。这包括复杂的健康监测、同步(不是共享数据)、使用共享拨号计划在对等点之间进行智能定制/区分等。具有 2 个对等点的集群也是标准(对等点位于不同的数据中心)——当您达到 3 个以上的对等点时,您会开始遇到在争用情况下同步状态的新问题(2/3/4/等处于活动状态)。使用您描述的 Master-Master DB,您将永远无法从多活动争用中恢复。

听起来你买了很多硬件,现在正在设计一个解决方案来使用这些硬件。你可能想用另一种方式来解决这个问题——一旦你有了实用的设计,就重新利用不需要的硬件。我建议使用双节点集群,并进行数据同步和健康监测。

相关内容