All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Opinions about DRBD and suggestions for alternatives
Hi,
I have used AWS for 8-9 years at work and it has been super reliable. However, AWS is very expensive. :-) So I have been exploring cheap dedicated servers recently for personal projects. I am trying to think about a resilient deployment on cheap servers. Something where a server dies it's shouldn't be much of an issue. I want to use these servers to run Docker containers with persistent volumes.
My use case is like following: I have 1 cheap dedicated box with multiple Docker containers. If something happens to this machine, I just want to forget about it, change DNS and failover to another machine. A couple of hours of downtime is fine.
While researching about this I came across DRBD. It seems to be kind of defacto solution for an HA Linux deployment. Have you guys used DRBD recently? Have any opinions (good/bad) about it?
Any suggestions about alternative setups?
Comments
Have a look at a project like https://www.pulseha.com this should also allow you to keep the sites up without needing to change you DNS records. Other options are Heartbeat or I think Coralsync.
DRBD is a pretty neat tool, you can certainly use it for replicating Docker volumes.
Thanks for input guys!
I like https://lizardfs.com/
DRBD is by fact the best solution for distributed storage. Give a read on this:
https://about.gitlab.com/2015/03/09/moving-all-your-data/
Also,, consider some cons:
@LTniger Thanks for the Gitlab link. It was an interesting read!
Looks like an interesting project.
I have used DRDB for longtime. It's excellent when you want data on two servers replicated and identical for automatic fall back if one server dies ( think of a master(online)-master(offline) situation here ) . It's better on a rock solid network between the two ( usually direct physical connection between the two, but new version of DRBD are more resilient.
Your use case, you could try something like Ceph, that way you could have all servers up and storage would be share across all of them instead of one being idle not doing anything. There are multiple way to do it.
I have used DRBD, ensure you test your failovers thoroughly and understand what you have config.
once setup its pretty stable.
I use GlusterFS and Kubernetes for my clusters. GlusterFS for replicated and fault tolerant storage, K8s for orchestrating the containers. Usually three nodes for quorum
Thanks for the suggestion, what are the advantages of lizardfs over gluster?
I've heard of gluster just haven't used it yet. It looks like it runs on top of some other filesystem. What underlying filesystem do you use?
Distributed filesystem and DBRD are very different things. It depends what you want to do.
For me I think LizardFS is good to get up and running quickly, and for multiple independent clusters - performance wise it's great when the cluster isn't so huge. LizardFS downside might be not scaling too well. But then there's also Ceph if scaling is an issue.
Thanks for suggestions from all of you. However, right now I don't want to go into distributed file systems. Don't really have the budget for more than a couple of cheap dedi nodes anyways. :-)
Still, I would research and try out Ceph and Lizard for personal learning. My main apprehension with network-attached block storage is poor write performance. On AWS we all pay EBS tax. :-) I know it's redundant and very reliable, but write performance sucks!
For this project, I was planning to use directly attached SSDs for the DB workload, hence looking to us DRBD to limit to just 2 servers.
So I guess I will have to take both the Dedi boxes from the same provider. Does opting for something like vLAN will help with DRBD resiliency? Need to checkout it's cost implecations though.
What's your opinion on running DRBD on 2 dedi boxes from different providers and running the replication over the internet? Too risky?