您的解决方案需要在两台服务器上实时更新的共享数据库。该数据库将由一个事件记录器管理,该记录器将跟踪所有正在进行的呼叫;可能标记为 LINEUP。如果检测到故障,则故障服务器上的所有调用都将被标记为 DROPPEDCALL。当您的故障转移服务器启动并接管时——使用心跳监控或其他方式——然后它会做的第一件事是生成一组标记为 DROPPPEDCALL 的所有数据库记录的调用文件。然后可以将这些呼叫一起召开会议。
关于它的最困难的部分是事件监视器,确保您不会错过任何 RING 或 HANGUP 事件,可能会在系统中留下“幽灵”呼叫,以便在恢复操作中错误地拨打。
您可能还应该有一种机制来在“管理”机器上构建您的 Asterisk 配置,然后将更改推送到您的呼叫管理器 AST boxen 场。这样,任何节点都可以用任何其他节点替换。
您应该拥有 2 个使用复制技术和 Linux 高可用性 (LHA) (1) 的数据库服务器。或者,使用“公共”IP 进行 DNS 循环或负载平衡也会做得很好。这些机器的负载可能足够轻,也可以托管您的配置管理器,并且可以“免费”获得 LHA。
然后,至少 N+1 AST Boxen 用于呼叫处理。N 是您计划每秒处理的呼叫数除以 300。“+1”是您的故障转移节点。使用节点轮询,您可以设置一种机制,其中故障转移节点通过从配置管理器中提取正确的配置来采用故障机器的身份。
如果硬件便宜/免费,那么 1:1 LHA 节点冗余始终是一种选择。但是,一般来说,您的 PC 硬件和 Asterisk 软件的故障率相当低;罐头中有 3 或 4 个“9”。所以,真的,你正试图与“5th 9”保持最后一点距离。
我希望这能给你一些关于走哪条路的想法。如果您有任何问题,请告诉我,请花时间“接受”哪个答案可以满足您的需要。
(1) http://www.linuxjournal.com/content/ahead-pack-pacemaker-high-availability-stack