Small colo infrastructure for SaaS
-
This is how @scottalanmiller suggested HA in the database layer.
Webserver files themselves are static and the data in the database is what is changing.
-
What are you using to create those diagrams?
-
This is how @dustinb3403 suggested replicating VMs between hosts:
-
@black3dynamite said in Small colo infrastructure for SaaS:
What are you using to create those diagrams?
Microsoft Visio Pro.
-
It does a nice job of making those look good.
-
@pete-s said in Small colo infrastructure for SaaS:
For the VMs that need replication, we might just as well have replication going in both directions between the hosts, instead of just one direction. Don't you agree?
If you don't want Host 2 sitting there waiting for something to fail... then I would have the 4 Production VMs on Host 1 Replicate to Host 2...
And the 4 Production VMs on Host 2 Replicate to Host 1... That would work, but I see the potential for confusion there.
-
I'd also recommend using a tool like Consul for service discovery and health checking.
Fabio (load balancer) natively works with Consul so as systems (LXC or VMs) are brought up they will be auto added to the pool. If they become unreachable they will be automatically removed.
-
-
@pete-s said in Small colo infrastructure for SaaS:
BTW, can you setup continuous replication without XO, just using xencenter or with xen itself?
While possible, it's not easily doable.
For the VMs that need replication, we might just as well have replication going in both directions between the hosts, instead of just one direction. Don't you agree?
I disagree here, the host performance in this case means you need your hosts to be able to cover the workload of your entire clientbase. So having slightly more powerful hosts here isn't an issue, and replication is easily be changed around.
And the reason being is you'd be replicating VM's between two hosts and only having half of the workload protected from a failed host in this case anyways.
The entire conversation revolves around protecting from a host failing. Which if you have the worst case scenario you have your backups to restore from.
-
@pete-s said in Small colo infrastructure for SaaS:
This is how @dustinb3403 suggested replicating VMs between hosts:
While this is accurate, it also misses on the fact that he would still have his NLS server sitting, collecting backups on whatever schedule.
Other than that it is accurate. In Scott's proposal you are making the shift from migrating the entire workload (which is essentially instant) to migrating the database only.
In his case, the load balancer is the weak link in the chain. Granted these don't fail often but it isn't something you have control over either unless you provide your own for the COLO.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
Other than that it is accurate. In Scott's proposal you are making the shift from migrating the entire workload (which is essentially instant) to migrating the database only.
In mine he is replicating the database only, but not migrating it ever. The database would be in both places, at all times, always being used.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
This is how @dustinb3403 suggested replicating VMs between hosts:
While this is accurate, it also misses on the fact that he would still have his NLS server sitting, collecting backups on whatever schedule.
Other than that it is accurate. In Scott's proposal you are making the shift from migrating the entire workload (which is essentially instant) to migrating the database only.
In his case, the load balancer is the weak link in the chain. Granted these don't fail often but it isn't something you have control over either unless you provide your own for the COLO.
2 haproxy VMs (one per host) and keepalived for failover
