Small colo infrastructure for SaaS
-
I'm going to rent a 1/4 rack at a colocation center and put some servers there.
The purpose of this project is to host applications we have developed so our customers can use them. In the past we have mostly developed one-off intranet applications that we have installed on the customers own infrastructure and then maintained.
I feel that that is a dead end from a business point of view and it's long overdue for us to become a SaaS provider, albeit at a very small scale. Our current customers are enterprise customers but the applications themselves don't have that many users, from maybe 20 users up to about 300. In any case the applications have happily been running on single servers, without any load balancing, database clusters or other similar techniques.
First step for this project is to find an infrastructure that will get the job done without overspending but that we could expand upon. I don't feel that we need high availability from a business point of view. If we have a hardware failure though we need to be able to get up and running again in a few hours.
I'm thinking two VM hosts without HA and without running on shared storage could do that. If one host goes down we could manually fire up the backup on the other host.
This is what I had in mind:
VM host nodes will have 1 CPU, 10 cores, 64GB RAM, 500GB SSD storage. In my mind that would allow us to run 8 VMs per node with 4 vCPU, 8GB RAM and 50GB storage per VM. Every VM will be linux/bsd.
Nodes are also easily expandable to 2 CPU, 20 cores, 128GB RAM and whatever storage that is needed (6x3.5" bays).
I like the management of Xenserver so that is what I'd like to use, well actually XCP-ng.
What do you guys think?
-
So a LOT of these decisions will be completely dependent upon you application architectural design. Traditional HA (which you said you don't need) and shared storage (which you think that you do) are based around the applications themselves not sharing data between nodes. But that isn't too much of a challenge for a modern application.
In many cases you would need none of these things. Two VM hosts, yes. But shared storage? Not likely. Let the database replicate and you get HA without needing shared storage or HA from the VM hosts.
-
If every VM is Linux based and you are confident that that will remain true, consider an LXC/LXD based infrastructure. Faster spin up, lower overhead.
-
I don't see anything wrong with the approach here. This is how a lot of system design should be setup in the first place.
Can you add HA, absolutely with very little added effort. Any mainline Hypervisor includes this at little added effort or cost.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
So a LOT of these decisions will be completely dependent upon you application architectural design. Traditional HA (which you said you don't need) and shared storage (which you think that you do) are based around the applications themselves not sharing data between nodes. But that isn't too much of a challenge for a modern application.
In many cases you would need none of these things. Two VM hosts, yes. But shared storage? Not likely. Let the database replicate and you get HA without needing shared storage or HA from the VM hosts.
That's exactly what I had in mind. The storage in the colo is for backups primarily, hence nearline.
-
@pete-s said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
So a LOT of these decisions will be completely dependent upon you application architectural design. Traditional HA (which you said you don't need) and shared storage (which you think that you do) are based around the applications themselves not sharing data between nodes. But that isn't too much of a challenge for a modern application.
In many cases you would need none of these things. Two VM hosts, yes. But shared storage? Not likely. Let the database replicate and you get HA without needing shared storage or HA from the VM hosts.
That's exactly what I had in mind. The storage in the colo is for backups primarily, hence nearline.
Ah, okay, no problem then.
-
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
-
You can even get Near-HA with the pool functionality in XenServer or XCP-NG. Or you can use StarWinds vSAN and have true sHA for little overhead.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
You can even get Near-HA with the pool functionality in XenServer or XCP-NG. Or you can use StarWinds vSAN and have true sHA for little overhead.
For a third party workload, I'd do that. But for a bespoke app, I bet he doesn't need to. You can make it all failover with nothing more than load balancing.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
Live migration for service, upgrades and such.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
I'm thinking for those cases of a host catching on fire.
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
You can even get Near-HA with the pool functionality in XenServer or XCP-NG. Or you can use StarWinds vSAN and have true sHA for little overhead.
For a third party workload, I'd do that. But for a bespoke app, I bet he doesn't need to. You can make it all failover with nothing more than load balancing.
True, but its nothing more than a control function to "move" the workload to another host in the pool.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
I'm thinking for those cases of a host catching on fire.
@scottalanmiller said in Small colo infrastructure for SaaS:
@dustinb3403 said in Small colo infrastructure for SaaS:
You can even get Near-HA with the pool functionality in XenServer or XCP-NG. Or you can use StarWinds vSAN and have true sHA for little overhead.
For a third party workload, I'd do that. But for a bespoke app, I bet he doesn't need to. You can make it all failover with nothing more than load balancing.
True, but its nothing more than a control function to "move" the workload to another host in the pool.
Right, but that's not needed typically with bespoke software. That's a kludge for third party software that isn't well designed.
-
@pete-s said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
Live migration for service, upgrades and such.
When would that be needed? Maybe I'm picturing a very different setup....
-
@pete-s said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
Live migration for service, upgrades and such.
This would be in the case of performing host updates only. You're not gaining true HA at the application layer. If the guest takes a dive, you're still recovering from backup.
-
@scottalanmiller said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
Live migration for service, upgrades and such.
When would that be needed? Maybe I'm picturing a very different setup....
Host updates that require a reboot. Few and far inbetween now-a-days.
-
@dustinb3403 said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
@pete-s said in Small colo infrastructure for SaaS:
@scottalanmiller said in Small colo infrastructure for SaaS:
In that case, why the live migration? Should not be needed at all, correct? If one node dies, the other just takes over?
Live migration for service, upgrades and such.
When would that be needed? Maybe I'm picturing a very different setup....
Host updates that require a reboot. Few and far inbetween now-a-days.
Even full reboot of the host is handled in my mental design.
-
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.
-
@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.
-
@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.
-
@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.
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.
