OpenSIPS 中的集群支持是一个具有挑战性的领域，并且不断发展。即使自其初始版本发布以来已经过去了很多年，我们仍然发现需要理解和解决的具有挑战性的场景。生产环境，尤其是涉及大量数据的环境，是此类挑战的典型熔炉。以下是我们过去几个月发现的一些问题。
集群同步与实时 SIP 流量之间的冲突
OpenSIPS 集群的同步机制可确保新启动的 OpenSIPS 节点拥有与同一集群内其他节点相同的数据集（如 SIP 端点）。这在 HA（High availability） 场景中非常有用，例如，在这种场景中，如果使用中的设备着火了，你希望有一个热备份设备随时可以接管 SIP 流量处理。
在这里我们发现，在极少数情况下，如果在 OpenSIPS 节点处理实时 SIP 流量时重新启动该节点，集群同步操作有时会因为同时处理的 SIP REGISTER 发生冲突而导致该节点卡住！
虽然这种情况很少发生，但如果没有适当的监控来强制重启有问题的 OpenSIPS 节点，就会造成暂时的服务中断。报告发布后不久，这个问题就得到了解决，继续下一步。
启动时大量数据同步不完整
如果您运行的是集群 OpenSIPS v3.4.8 或更早版本，并且有大量 SIP 端点注册到集群中，那么您可能已经注意到在重启任何实例后偶尔会出现同步不完整的情况。例如，OpenSIPS 节点有 25000 个注册端点，但新重启的实例有时只能提取约 9000 个端点，然后就会宣布自己 “已同步”。之后，系统管理员手动运行 ul_cluster_sync MI 命令，这次所有 25000 个注册点都被正确提取。但为什么初始同步会中途终止呢？
简而言之，问题的根源在于集群器模块的 seed_fallback_interval 设置，它没有考虑到现实生活中的启动延迟，例如从数据库加载路由规则、拨号计划、调度员目的地或类似的缓存操作，这些操作可能每个都需要几秒钟才能完成。
经常出现的情况是，由于需要复制大量数据（如注册），导致新启动节点上的数据暂时丢失。一旦我们了解了这个问题，修复它就只是一种形式。
大量数据同步期间集群中断
最后，我们解决了另一份报告，其中 OpenSIPS 集群会在大量数据同步期间暂时分裂，然后再次重新加入。事实证明，在不增加集群的ping_timeout 的情况下同步的数据越多，在同步期间破坏集群的可能性就越大，这也会中止同步。
后来，经过几次巧妙的改变，这个报告也得到了解决，不再需要系统管理员随着 SIP 端点的增多而增加ping_timeout 。
这是一个非常具有破坏性且极有可能发生的场景。想象一下——每次节点重启（甚至是备份）或手动 MI“同步”命令，都会破坏 OpenSIPS 集群的一致性几秒钟，同步数据甚至可能无法完全到达。同样，所有这些都与要复制的大量数据有关。
结论
12 月 18 日发布的最新一轮 OpenSIPS 稳定小版本，即3.5.3和3.4.10 ，包括对处理大量数据时的集群模块的一系列关键稳定性改进，以及对 OpenSIPS 其他部分的许多其他修复。
这些版本的打包已经可以通过APT和YUM存储库获得，而最新的源代码可以像往常一样通过 GitHub 下载。
原文：https://blog.opensips.org/2024/12/19/opensips-cluster-hardening-in-large-dataset-scenarios/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/54988.html
