FreeSwitch的高可用性
我已经安装并配置了FreeSwitch。它已经启动并完美地运行。现在，我需要实现高可用性。我的自由开关部署在AWS Ubuntu EC2中。根据HA的AWS文档，它显示了浮动IP概念。我尝试了这个，但我无法在AWS中创建虚拟IP。我也尝试了EFS。它也失败了。还有其他可能的解决方案吗？
I have installed and configured FreeSwitch. It is up and running perfectly. Now I need to achieve high availability. My freeswitch was deployed in aws ubuntu ec2. As per aws docs for HA, it shows the floating ip concept. I tried this but I cant create a virtual ip in aws. I also tried efs. It also fails. Is there any other possible solutions?..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在Freeswitch中，HA没有一件事情。
如果您需要VIP，则确实有[0]
有多种解决方案。但是通常，您需要将FreeSwitch视为正在执行某些业务逻辑的应用程序，然后将反向代理放置。代理人轻量级，他可以从HA和可伸缩性中获得更多功能。
Opensips或Kamailio比任何软开关（FreeSwitch，Asterisk等）至少可以进行十倍的并发会话。
因此，您的解决方案是在Freeswitch后面放一些SIP代理。然后，如果freeswitch降低了，则代理不会拨打电话。
代理本身具有用于多主管的专用协议
尽管如此，您仍需要考虑BLF，会议等等边缘案例。
通常，关于VoIP HA，不要试图保存实时呼叫。只需确保系统正在启动并运行下一个呼叫
更新：请参阅 https://developer.signalwire.com/freeswitch/freeswitch-explained/configuration/chigh-availabilation/
[0] ：（过时的URL https://freeswitch.org/confluence/pages/viewpage.action?pageId=7143926< /a>）
In Freeswitch, there is no single thing about HA.
If you want VIP, you do have [0], but this is not so recommended since VIP is required to decide whether the server is up or down, which does not come easily
There are multiple solutions for this. but generally, you need to think about FreeSwitch as an application that is doing some business logic, and you put a reverse proxy behind it. the proxy is lightweight, and he is capable of much more from HA and scalability.
OpenSIPs or Kamailio is capable of at least ten times of concurrent sessions than any soft switch (FreeSwitch, Asterisk, etc.)
So your solution is to put some SIP proxy behind the FreeSwitch. then if the FreeSwitch is down, the proxy will not dispatch calls to it.
The proxy itself has a dedicated protocol for multi-master
Still, you need to think about edge cases like BLF, conferences, etc.
Generally, about VoIP HA, don't try to save the live calls. Just make sure the system is up and running for the next calls
UPDATE: see https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Configuration/High-Availability/
[0]: (outdated URL https://freeswitch.org/confluence/pages/viewpage.action?pageId=7143926)
“ ha”的自由开关文档描述了一种琐碎的（实际上无用的）场景，从中可以从中恢复。那不是真的给你哈。没有任何类型的故障感知，如果两者都试图活跃，没有数据同步，则节点之间没有协调，如果促销失败，则无法控制节点，也没有对事件/失败的响应等。对于家庭系统，只需创建一个备用节点，然后将其关闭，直到需要它为止。如果是用于商业VoIP安装，请继续阅读。
首先查看此Voip-info网页：高可用性设计< /a>。尽管有几个部分指的是星号而不是自由开关，但它在解释了什么是高可用性和不是什么方面做得很好。 （很容易与负载平衡相混淆）。如果您认为浮动IP是最大的挑战，那么您可能已经忽略了使VoIP HA在现实世界中起作用所需的条件。
首先定义VoIP“失败”。用最简单的术语来说，这是Freeswitch过程即将死亡。但是通常，FreeSwitch过程还活着，而不是桥接呼叫（因此避免使用简单的过程监视脚本）。如果网络连接熄灭（或防火墙失败），或者您的AZ和Trunks/Phone Sets之间的路线将变得不稳定怎么办？您的HA解决方案应该能够考虑上游路线等环境因素，以确定同伴是否无法再提供电话服务。一些解决方案使用通用的Linux心跳软件，这些软件没有任何深厚的自由开关可见性或环境可见性。
如何保持数据之间的数据同步？从语音邮件，到配置数据，再到电话设置固件等。解决方案（例如RDS或DRBD）使其变得容易，但是一个同伴的损坏立即损坏另一个。例如，如果一个同行损坏损坏的过程损坏关键的freeswitch文件，则将启动另一个同行（如果他们使用drbd，则没有）。因此，避免使用RDS或基于DRBD的“解决方案”。
如果您引入负载平衡（即多个活跃的同行），如果有2个同行同时获得用户123的语音邮件1，则一个“获胜”？这需要您介绍前端服务器以进行呼叫桥接，语音邮件的后端等。而且您仍然有单个失败或共享组件。
如果您从失败中恢复并需要重新组装群集，那么如果每个同行将数据写入其共享“磁盘”副本，会发生什么？您是否手动开始调和？如果一个同时出现2个同伴（双重活跃） - 哪一个获胜并接管？如果您引入共享磁盘解决方案（DRBD，NFS，ISCSI），那么您将消除HA解决方案中最大，最重要的元素之一：PEER自治。因此，寻找“同步”，而不是“共享磁盘”。
FreeSwitch最便宜的“ HA”解决方案倾向于使用共享的虚拟磁盘（例如：DRBD/NFS/SMB）和/或共享频道库。正如您将在上面阅读的那样，真实的HA解决方案（如911/PSAP呼叫中心中使用的解决方案）需要完全自主的同行和呼叫路径。有些解决方案开始在各处添加冗余（例如：前端，数据库，角色服务器等），但他们真正做的就是创建多个无法处理大多数真实世界故障场景的失败点。而且它们很难维护。
因此，现在决定您是想要免费还是商业商业，以及权衡什么。高端是 hafs （免费/商业）产品，该产品没有共享的组件并使用复杂的健康检测，并且与所有Freeswitch发行版兼容 - 但需要更多的Linux技能来安装，并且根据版本的不同（更多用于企业或任务关键电话系统）。另一端是一个（免费脚本）翻转脚本，易于安装，但称其为“ HA”是一个伸展的脚本。尽管您询问了AWS，但还有一些VMware提供通用的HA（但不是PBX/TRUNK/SIP/ETC AREAWS），您还会发现一些供应商将RAID 1作为“ HA”作为PBX，但这是一个伸展。而且在此范围内也有更多产品。没有供应商“认可”或“认可”或“认证”任何其他产品，因此您必须在购买之前尝试。
您还会发现人们提供“容器”作为HA解决方案，但这并不是HA。容器是部署软件的方便方法，您可以拥有准备部署的备用PBX容器；但是，您没有设置/语音邮件/等的同步，没有失败等。
最后，您还将找到对Kamailio，opensips，Proxies等的参考。但是所有这些都会创建一个新的单点（或许多单点）点）在您的“群集”前的失败。然后，您必须将HA添加到HA解决方案等。
当您评估产品时，请务必提出正确的问题！没有一个单一的解决方案适合所有人 - 但是VoIP-Info HA设计页面将帮助您理解权衡。如果您需要符合911/PSAP标准或为大量呼叫中心建造，请查看高端HAFS产品。如果是为了家庭使用，请尝试Flipit（我在某处看到AWS特定版本，但现在找不到）或通用的Linux群集（组合心跳，rsync等软件包，等等，监视等，也可以在AWS上使用）。最后，您会发现移动浮动IP是最简单的工作之一。
The FreeSWITCH docs for "HA" describe a trivial (and practically useless) scenario from which FreeSWITCH can recover. That's not really giving you HA. There is no sensing of different types of failures, no coordination between nodes in case both/neither are trying to become active, no synchronization of data, no control of nodes if promotion fails, no response to events/failures, etc. If this is for a home system then just create a standby node and keep it powered off until you need it. If it's for a commercial VoIP installation read on.
Start by having a look at this voip-info web page: high availability design. Although a couple parts refer to Asterisk instead of FreeSWITCH it does a great job explaining what high availability is and isn't. (Its easy to confuse high availability with load balancing). If you think a floating IP is the biggest challenge then you might have overlooked what it takes to make VoIP HA work in the real world.
Start by defining a VoIP 'failure'. In the most simplistic terms it's the FreeSWITCH process dying. But often the FreeSWITCH process is alive just not bridging calls (so avoid simplistic process monitoring scripts). What if the network connection goes out (or a firewall fails), or a route between you AZ and trunks/phone sets becomes unstable. Your HA solution should be able to consider environmental factors like upstream routes/etc to determine if a peer can no longer offer telephony service. Some solutions use generic Linux heartbeat software which doesn't have any deep FreeSWITCH visibility, or environmental visibility.
What about keeping data in sync between peers? From voicemails, to configuration data, to phone set firmware, etc. Solutions like RDS or DRBD make it easy, but corruption by one peer immediately corrupts the other. For example, if a corrupt process on one peer damages critical FreeSWITCH files, will the other peer start (if they use DRBD then no). So avoid RDS or DRBD based 'solutions'.
If you introduce load balancing (i.e. multiple active peers) which one 'wins' in the event that 2 peers each receive voicemail #1 for user 123 at the same time? This require you introduce front-end servers for call bridging, back-end for voicemail, etc. And you still have single points of failure or shared components.
If you recover from a failure and the cluster needs to re-assemble, what happens if each peer wrote data to its copy of the shared 'disk'? Do you manually start reconciling? What if 2 peers come up at once (dual active) - which one wins and takes over? If you introduce a shared disk solution (DRBD, NFS, iSCSI) then you eliminate one of the biggest and most important elements of an HA solution: peer autonomy. So look for 'synchronization', not 'shared disk'.
The cheapest 'HA' solutions for FreeSWITCH tend to use a shared virtual disk (eg: DRBD/NFS/SMB) and/or a shared channel bank. As you will read above, real HA solutions (like the ones used in 911/PSAP call centers) require completely autonomous peers and call paths. There are solutions which start adding redundancy everywhere (eg: front end, database, role servers, etc) but all they really do is create multiple points of failure unable to handle most real-world failure scenarios. And they are difficult to maintain.
So now decide if you want free or commercial, and what the tradeoffs are. On the high end is HAfs a (free / commercial) product which has no shared components and uses sophisticated health detection, and is compatible with all FreeSWITCH distributions - but requires more Linux skills to install and can be more expensive depending on the edition (more for enterprise or mission critical phone systems). On the other end is a (free script) flipit script that is simple to install but it's a stretch to call it 'HA'. Although you asked about AWS, there is also VMware which offers generic HA (but it's not PBX/trunk/SIP/etc aware), and you will also find some vendors offering RAID 1 as "HA" for a PBX but that's a stretch. And there are more products in this spectrum too. No vendor 'approves of' or 'endorses' or 'certifies' any other product, so you have to try before you buy.
You will also find people offering 'containers' as HA solutions, but that isn't really HA. Containers are convenient ways to deploy software, and you can have a spare PBX container ready to deploy; but, you don't have synchronization of settings/voicemails/etc, no detection of failures, etc.
Finally, you will also find references to Kamailio, openSIPs, proxies, etc. But all of these create a new single point (or many points) of failure in front of your "cluster". Then you have to add HA to your HA solution, etc.
Just be sure to ask the right questions when you do evaluate products! No single solution is right for everyone - but the voip-info HA design page will help you understand the trade-offs. If you need to meet 911/PSAP standards or are building for a high volume call center, have a look at the high-end HAfs product. If it's for home use, try flipit (I saw an AWS specific version somewhere but can't find it now) or generic Linux clustering (combining packages for heartbeat, rsync, etc, monitoring, etc. available on AWS too). In the end you will discover moving a floating IP is one of the easiest things to get working.