Ideal Fusionpbx Load Balaning Solution

[Maani]

@DigitalDaz @KonradSC @markjcrane @phonesimon
Hi
I think Ideal Fusionpbx Load Balancing Solution should have this features:

• Load balance single domain over multiple Fusionpbx servers.
• Register cache and rate throttling.
• No need special feature on sip phones.
• No Need to replicate internal Freeswitch database.(So still can put it on RAM and there is no performance penalty)
• Add or remove Fusionpbx servers gracefully if traffic needs or for maintenance without service interruption.

Do you want to add new feature or like to sponsor ?
Regards.

 

[KonradSC]

I think a lot of this depends on the environment. I would say that in your domain has a couple thousand extensions or less, then you can just load balance by DNS.

I'm still leaning towards having a shared FS database for large customers (5000+ users in a domain). In my spare time I've played around with Apache Ignite. https://ignite.apache.org/ It looks like it could be a really nice replicated in-memory database for the FS database, however the thought running Java kind freaks me out.

 

[Maani]

I think a lot of this depends on the environment. I would say that in your domain has a couple thousand extensions or less, then you can just load balance by DNS.

I'm still leaning towards having a shared FS database for large customers (5000+ users in a domain). In my spare time I've played around with Apache Ignite. https://ignite.apache.org/ It looks like it could be a really nice replicated in-memory database for the FS database, however the thought running Java kind freaks me out.

I think it is possible via putting special intelligence in a sip proxy(Opensips) in front of Fusionpbx farms omits need to shared FS database or DNS load balancing.

 

[DigitalDaz]

With respect, this is kind of a recurring thing I see on here, many people have the ideas but nothing, certainly so far, has come from them.

 

[babak]

@DigitalDaz @KonradSC @markjcrane @phonesimon
Hi
I think Ideal Fusionpbx Load Balancing Solution should have this features:

• Load balance single domain over multiple Fusionpbx servers.
• Register cache and rate throttling.
• No need special feature on sip phones.
• No Need to replicate internal Freeswitch database.(So still can put it on RAM and there is no performance penalty)
• Add or remove Fusionpbx servers gracefully if traffic needs or for maintenance without service interruption.

Do you want to add new feature or like to sponsor ?
Regards.

I have an idea that it seems can provide all mentioned features:

call-->Opensips---(route based on A_number)--->Fusionpbx1---(enable services based on A_number like redial located in hash db)---->Opensips---(route based on B_number)-->Fusionpbx2---->destination
With adding some intelligence to Opensips it is not even need to replicate internal Freeswitch database .
It is possible to have many load sharing Fusionpbx servers Opensips remember how to route digits but it is not hard coded.
Opensips can replicate successfull Register message to all Fusionpbx servers and also it is possible to use mid_registrar.
Call center/conference... calls goes to one server but have alternate route.

@KonradSC @DigitalDaz @Adrian Fretwell

 

[Scubadave112]

I just setup BDR and syncthing on a couple servers, following mark crane’s advanced videos. was planning to add 5 of my smaller clients to it this weekend test them for a week and then stick a load balancer in front of it.
The setup was smooth and easy and I can have a crazy amount of these. Then if I really wanna have fun I can setup two more at another data center and then use dns to handle the active failover.

I am migrating the 5 clients over (about 50 endpoints) this weekend and will share how that goes.

@DigitalDaz your correct people claim 10 diff ways to accomplish this but I never see posts about people using @markjcrane documented and supported method, is there a reason for this?

 

[KonradSC]

Probably because of scaling issues. BDR is slow compared to something like sqlite in a RAM drive.

 

[Scubadave112]

At what point will that impact my system/end users, I mean BDR should be viable for at least 1000-2000 registrations, right? And if someone has that many and lacks the capital/resources to build another cluster then they don’t need a BDR solution they need a financial advisor; however, if you have experienced issue with this at let’s say 300 registrations, please share because if that’s the case I won’t waste my time on this.

 

[DigitalDaz]

Most of us do not bother to replicate the freeswitch db anymore and I do not believe Mark recommends it these days.

 

[DigitalDaz]

Just burn this in your brain and you are good. Apart from per domain load balancing where all calls for one domain stay on a single server, LOAD BALANCING DOESN'T WORK.

 

[KonradSC]

FS db in BDR cluster with 300 users should be fine. If you are using UDP for SIP I would set my registration expires to something like 120 sec or higher and use keepalives.

You've got a environment stood up. Run some tests with SIPP or StarTrinity SIP Tester.

Something to keep in mind...even with only 300 users there will most likely come times when all 300 phones try to register within a few seconds of each. So in your testing you want to ratchet it up to 150 to 200 Registrations/sec.

Report back your findings.

 

[babak]

Just burn this in your brain and you are good. Apart from per domain load balancing where all calls for one domain stay on a single server, LOAD BALANCING DOESN'T WORK.

Hi DigitalDaz
Please check Scaling Asterisk with OpenSIPS by Razvan Crainea especially page 37.
Cross dialog data accessing was improved in Opensips 3.1

Regards

 

[mat1010]

Kazoo, developed by 2600hz is using kamaillo, freeswitch, rabbitmq and couchdb with their custom written erlang application called "ecallmanager" to setup a highly scalable voip platform. The project is opensource and there's a good documentation how to setup the infrastrucutre on premise. You can also start small run all components in 1 or 2 servers and scale later. Might be worth a look instead of building it on your own from scrath.

 

[DigitalDaz]

Kazoo, developed by 2600hz is using kamaillo, freeswitch, rabbitmq and couchdb with their custom written erlang application called "ecallmanager" to setup a highly scalable voip platform. The project is opensource and there's a good documentation how to setup the infrastrucutre on premise. You can also start small run all components in 1 or 2 servers and scale later. Might be worth a look instead of building it on your own from scrath.

In the past you couldn't even do things like have custom on hold music per tenant, its features were severely lacking compared to fusionpbx.

 

[mat1010]

In the past you couldn't even do things like have custom on hold music per tenant, its features were severely lacking compared to fusionpbx.

I agree, you are more flexible with the method how fusionpbx generates and maintains the configuration for freeswitch. Depending on the use case it might be still good enough if your main focus is scalability over multiple datacenters without the need of extremly customizable pbx features. In the end Kazoo is also maintained pretty active since they are using the same software stack for there pbxaas infrastructure and therefore I guess many more features will be added over time if there's demand for it.

 

[bcmike]

Kazoo, developed by 2600hz is using kamaillo, freeswitch, rabbitmq and couchdb with their custom written erlang application called "ecallmanager" to setup a highly scalable voip platform. The project is opensource and there's a good documentation how to setup the infrastrucutre on premise. You can also start small run all components in 1 or 2 servers and scale later. Might be worth a look instead of building it on your own from scrath.

I looked at this and setup the environment at one time. My take away was that in trying to achieve scalability they added an unacceptable amount of complexity. To run and support Kazoo we'd need to become experts (or at least passable administrators) in kamaillo, freeswitch, rabbitmq and couchdb, not to mention erlang. With Fusion we need only need to administer Freeswitch and Postgres. I can't imagine trying to troubleshoot an issue across all of those applications.

 

[mat1010]

I looked at this and setup the environment at one time. My take away was that in trying to achieve scalability they added an unacceptable amount of complexity. To run and support Kazoo we'd need to become experts (or at least passable administrators) in kamaillo, freeswitch, rabbitmq and couchdb, not to mention erlang. With Fusion we need only need to administer Freeswitch and Postgres. I can't imagine trying to troubleshoot an issue across all of those applications.

That's correct, but it's the price you have to pay if you want a real scalable system without a monolithic application. Of course it would be great to just have to care about fusionpbx, freeswitch and postgres, but in the current state you won't be able to get a real robost, scalable system with only those components. But I didn't intend to hijack this thread with a discussion about Kazzo, just wanted to mentioned it and that it might be a viable solution. But if it's solely about making fusionpbx scalable that's too much off-topic.