Small colo infrastructure for SaaS
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because VM replication is not added complexity. it is easier, by far, than managing individual databases on every VM.
-
@pete-s said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because you'd need to have a readily available to use infrastructure somewhere that can host said database. Which might be beyond the technical expertise at the table to configure.
I don't want to replicate the db to the cloud. And I want to have the backup locally available - even if I will also backup to offsite at times.
Colo is 30 minute drive from our office.
Well, it will cost more upfront to do, but the solution is still sound. I would recommend an approach like Host A - Master, Host B slave - NLS backup target
Host A performs continuous replications to Host B, as well as Host A backs up to the NLS host on a different schedule.
Should Host A go down, everything is on Host B with a quick startup and you're off to the races.
You'd still have your separate backups to recover from should something even worse occur.
-
@jaredbusch said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because VM replication is not added complexity. it is easier, by far, than managing individual databases on every VM.
That's also a very good point.
-
@jaredbusch said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because VM replication is not added complexity. it is easier, by far, than managing individual databases on every VM.
It's more to fail than just having the workload on both all the time.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because you'd need to have a readily available to use infrastructure somewhere that can host said database. Which might be beyond the technical expertise at the table to configure.
It's pretty basic for any database today.
-
@pete-s said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because you'd need to have a readily available to use infrastructure somewhere that can host said database. Which might be beyond the technical expertise at the table to configure.
I don't want to replicate the db to the cloud. I believe it will be too slow.
Sure, but I don't think anyone is suggesting anything like that.
-
@pete-s said in Small colo infrastructure for SaaS:
And I want to have the backup locally available so restores are fast - even if I will also backup to offsite at times.
Colo is 30 minute drive from our office.
Hence my design, failover is instantaneous and simple.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because you'd need to have a readily available to use infrastructure somewhere that can host said database. Which might be beyond the technical expertise at the table to configure.
I don't want to replicate the db to the cloud. And I want to have the backup locally available - even if I will also backup to offsite at times.
Colo is 30 minute drive from our office.
Well, it will cost more upfront to do, but the solution is still sound. I would recommend an approach like Host A - Master, Host B slave - NLS backup target
His picture states shared nothing migration. I would argue, like you, that it should be live VM replication.
And the storage is only for backups as he already stated.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
My biggest question is why split workloads, rather than just the two servers, one acting as the active host, the other acting as the backup host.
Remove the NL Storage server entirely.
Perform continuous replication from Host A to Host B, as well as backup offsite.
Why even that much complexity? Only piece that needs replicated normally is the database.
Because you'd need to have a readily available to use infrastructure somewhere that can host said database. Which might be beyond the technical expertise at the table to configure.
It's pretty basic for any database today.
Sure, its easy enough to move a database in a planned move, during a disaster you have to pay the host, setup the DNS records, move the data, let all of the changes sync.
VM replication is extremely straightforward. On XenServer with XO it creates a full initially and then only performs the delta's afterwards.
The data is on both locations, always.
-
-
@dustinb3403 said in Small colo infrastructure for SaaS:
Should Host A go down, everything is on Host B with a quick startup and you're off to the races.
Why quick startup, rather than both running in parallel? There is no licensing cost to running both, there is no obvious benefit unless the only goal is to avoid a load balancer.
What am I missing?
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
And I want to have the backup locally available so restores are fast - even if I will also backup to offsite at times.
Colo is 30 minute drive from our office.
Hence my design, failover is instantaneous and simple.
It is most certainly is not. It is definitely more complex.
He has hypervisor A with 20 web apps running everything.
Hypervisor A shits.
Now, every single one of those 20 VM's on hypervisor 2 must be logged into and the IP addresses updated, or the router must be logged into and all the inbound traffic must be rerouted. or the added complexity of some kind of magic pool of proxy servers must be previously setup.
Either way, once hypervisor a comes back online, you have to spend more time and effort figuring out how to reverse the replication process.
On the other hand, you setup hypervisor replication from host to host and something to heartbeat it to turn on the VM's on the second host on a failure.
Then when host A comes back, you simply reverse the replication and host 2 goes back to being standby.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
Sure, its easy enough to move a database in a planned move, during a disaster you have to pay the host, setup the DNS records, move the data, let all of the changes sync.
Still not following. Since this would be planned, even in the event of a disaster, it's still free and easy. What am I missing? there is no DNS, no data to move, no syncing... nothing.
Both nodes have the DB all of the time. None of your concerns would exist until yet another layer of disaster were to strike. At which point, you'd be recovering from backup rather than load balancing to the other node.
-
@jaredbusch said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
And I want to have the backup locally available so restores are fast - even if I will also backup to offsite at times.
Colo is 30 minute drive from our office.
Hence my design, failover is instantaneous and simple.
It is most certainly is not. It is definitely more complex.
He has hypervisor A with 20 web apps running everything.
Hypervisor A shits.
Now, every single one of those 20 VM's on hypervisor 2 must be logged into and the IP addresses updated, or the router must be logged into and all the inbound traffic must be rerouted. or the added complexity of some kind of magic pool of proxy servers must be previously setup.
I'm confused. MY design has none of that. 20 VMs, zero interaction. Just fails over, immediately. No effort, no mapping. Failover can be done safely anytime, all the time. In fact, with normal load balancing, you effectively failover with every incoming new connection.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
Should Host A go down, everything is on Host B with a quick startup and you're off to the races.
Why quick startup, rather than both running in parallel? There is no licensing cost to running both, there is no obvious benefit unless the only goal is to avoid a load balancer.
and which host is that going to run on?
and what are you going to do when that host fails?No. You are wrong. The entire word is not stateless. VM replication is easier and simpler and cheaper.
-
@jaredbusch said in Small colo infrastructure for SaaS:
Either way, once hypervisor a comes back online, you have to spend more time and effort figuring out how to reverse the replication process.
Not in my design, none of this either. None. 100% avoids all this complexity.
-
@jaredbusch said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
Should Host A go down, everything is on Host B with a quick startup and you're off to the races.
Why quick startup, rather than both running in parallel? There is no licensing cost to running both, there is no obvious benefit unless the only goal is to avoid a load balancer.
and which host is that going to run on?
You normally buy a load balancer and put it out front. Or you get one from your colo and they handle that for you. That's extremely common. I've done this in the past in colo, the colo provided it.
You can do this with something like HAProxy if you want to do it for free. If you do that, you need only fail over the HAProxy, nothing else.
-
@jaredbusch said in Small colo infrastructure for SaaS:
No. You are wrong. The entire word is not stateless. VM replication is easier and simpler and cheaper.
That's why I pointed out that this was specifically the standard for well made bespoke apps, which is anything but the whole world.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@jaredbusch said in Small colo infrastructure for SaaS:
No. You are wrong. The entire word is not stateless. VM replication is easier and simpler and cheaper.
That's why I pointed out that this was specifically the standard for well made bespoke apps, which is anything but the whole world.
I see how both can work.
I think replication of the DB would be faster than continuous replication of the VM because there are less data to be changed.
Also if you have a VM of the application running on both servers and load balance you would get a higher performance and scalable solution. -
If your datacenter doesn't provide load balancing, or you just want to do it on your own, and you don't want to buy a load balancer (or load balancer cluster), you can build your own for free.
Load balancers are cheap, small, and stateless. HAProxy is one of a dozen or so decent open source options. You can make it a live/live cluster, but this takes some work that you might not want to do. If you do want to, great, you've got serious HA and load balancing without a crazy amount of effort.
If you don't, you've got lots of options. You can use VM replication only for the load balancer of course. Or you can manually flip the virtual IP when necessary and have only a single change needed for everything to fail over.
This design is very nice because you get load balancing so that you leverage both systems at the same time, and you "test" both nodes and the complete stacks on both all day, every day. You know for certain that they are both healthy. So if one fails, you aren't in doubt about the other one, you were using it just seconds ago.
Plus failover can be instant, regardless of workload size. No waiting for VMs to spin up, not even to reboot. And no worries that something has changed since the last reboot because they are already up and running.
