Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
Q2.Fusion Server infrastructure option
1.Separate database Server
server 1 - Fusion application
Seever 2 - postscript database
NOTE: Of course I should have a good bandwidth between two server
You typically do separate app and database servers when you are mixing apps and/or going to large scale. This is not large scale at all. You are well within the range of any tiny PBX. Adding this will likely just hurt performance, add risk, add complexity, and add cost. At this small scale, I don't see any benefits to the separation.
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
- Load Balancer option
Load Balancer point to Server 1- App1 and Server 2- App 2 and these two app server point to a Database server(postscript database)
Note: The load balancer is a single point of failure; if it goes down, your whole service can go down. A high availability (HA) setup is an infrastructure without a single point of failure. To learn how to implement an HA setup, you can read this section of How To Use Floating IPs.
HA doesn't mean you have or don't have a single point of failure. HA is exactly what it sounds like "availability rates that are significantly higher than standard." HA is determined by how many "nines" you get of availability, how that is achieved is not a factor in whether something is HA or not. In fact, many "fully redundant" solutions are actually the opposite, "low availability", because many redundancy mechanisms add risk rather than removing it.
Load balancing is not an appropriate mechanism for voice calls and does not make sense here.
It looks like you are taking diagrams from web applications, not PBX servers. These designs are not appropriate approaches for a PBX.
- Load Balancer option
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
- Master-Slave Database Replication
Note: The application accessing the database must have a mechanism to determine which database nodes it should send an update and read requests to Updates to slaves are asynchronous, so there is a chance that their contents could be out of date If the master fails, no updates can be performed on the database until the issue is corrected and does not have built-in failover in case of failure of a master node
This doesn't really make sense. The deeper we go, the more it looks like you are dealing with architectural diagrams from something other than a phone system. If we were talking about a high availability web app, sure, this makes total sense and is a standard design. For a PBX, this would buy you effectively nothing. All of this complexity would put you at greater risk, rather than protecting you.
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
- load balance the caching servers, in addition to the application servers, and use database replication in a single environment.
This doesn't work at all. You can't cache PBX traffic. So this is simply impossible. Whatever source you are using for this information is specific to web apps, and doesn't apply to your needs.
- load balance the caching servers, in addition to the application servers, and use database replication in a single environment.
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
Note:This environment still has two single points of failure (load balancer and master database server), but it provides the all of the other reliability and performance benefits that were described in each section above.
Sort of. Enterprise load balancers are clustered, not individual units. So this isn't a risk in that type of architecture. Bad idea for your phone system, doesn't make sense here, but is not a single point of failure when talking about this architecture.
If this was a real enterprise web app, we wouldn't put the database in master/slave but in master/master or active/passive modes so this would not be a single point of failure, either. What's the purpose of the slave node if it was believed it would be useless, anyway? In any normal database setup for HA, you have two (or three, or many) nodes that are all load balanced and any can take over.
But again, this isn't how PBXs work, so doesn't matter.
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
- IF you recommned any other setup to start for two new customer and of cource i can scale it later.
Worrying about PBX scaling will get you into big trouble. A single small PBX can handle thousands and thousands of extensions, no problem.
All you need for 800 extensions is a single VM that runs your PBX, that's it. Add anything more to that, and you are just adding more things to fail, more things to misconfigure, more cost. One VM, nothing more. Keep it "normal".
If you want HA, you don't need anything really, just a backup that you can restore in seconds. PBX are nearly stateless, you don't need live replication to keep them for HA purposes. If you have extreme needs way beyond industry norms (like way beyond) then you could run two PBX VMs, one replicated to the other, so that failover is a few seconds faster. That's it, that's all that you need. That way you can have the IP of the second VM registered with your trunk provider ahead of time.
It's that simple. Anything "more complicated" is just making things worse, not better.
-
@alimrahimi said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
Q3. Do i need to setup kamailio or opensips and what is the advantage to have it now?
No, you don't need it.
-
At such a small scale, you could even use SQLite instead of PostgreSQL to make VM to VM replication easier and system management easier, and to reduce risk. SQLite is a database, not an RDBMS, so has no service to fail, unlike MySQL, PostgreSQL, SQL Server, etc. There is nothing to "go down", it's just a file. So backups and restores, and uptime are a breeze.
-
@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
At such a small scale, you could even use SQLite instead of PostgreSQL
At what size would you stop using SQLite?
-
@360col said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
@scottalanmiller said in Best architecture / recommendation for multi sites (separate business) Cloud VOIP PBX:
At such a small scale, you could even use SQLite instead of PostgreSQL
At what size would you stop using SQLite?
Maybe a few thousand, or with multi-tenancy. PostgreSQL lets you go to a full live/live model, but that would be for things like 911 call centers.
