Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Opinions about DRBD and suggestions for alternatives
New on LowEndTalk? Please Register and read our Community Rules.

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

  • reditredit Member, Host Rep

    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.

  • FHRFHR Member, Host Rep

    DRBD is a pretty neat tool, you can certainly use it for replicating Docker volumes.

  • Thanks for input guys!

  • LeviLevi Member
    edited August 2018

    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:

    • A efkin split brains, you can loose data if you don't know what you do, pretty easily;
    • Scarce debug. If you encounter errors related to DRBD, you will have hard time to debug them;
  • @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.

  • jlayjlay Member
    edited August 2018

    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?

    jlay said: 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

    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?

  • edited August 2018

    @simpleguy8288 said:

    Looks like an interesting project.

    Distributed filesystem and DBRD are very different things. It depends what you want to do.

  • Corey said: Thanks for the suggestion, what are the advantages of lizardfs over gluster?

    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.

    larivee said: 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.

    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?

Sign In or Register to comment.