It’s not very often that I use terms like “great”, “awesome” or even “love” when it comes to computer things any more, but when it comes to DRBD, I can’t help it. It’s a truely great piece of software that I just love to work with. It helped me solve a lot of problems I had to deal with in my job over the last couple of years – here’s a tribute …
The first time I played with DRBD was in summer of 2007. I was trying to build my first open-source HA cluster and needed “something” that took care of the data-replication part. After I tried DRBD, there was nothing else to look at because it did exactly what I needed and did a very good job.
DRBD is a linux kernel module that provides a block device and replicates data between two nodes. On one node, the device is writable, on the other node, the device cannot be accessed – it’s an active/backup, master/slave, primary/secondary, call it what you like, kind of setup. Nowadays (actually, for a couple of years already, you can even go active/active, but I’ve never really used that, so I won’t cover it here).
Not only does it do a great job in safely replicating your data to another machine, it also allows for data verification (in case you don’t trust the data on the backup node) and is 100% oblivious to applications. So basically “anything” can be made highly available with DRBD (and a cluster manager). It can even save you an outage if your disk dies.
Working with blocks, it does not matter to DRBD what you do on top of it. Whether you want to encrypt the device, use it as a raw device for a database or just create a standard file system is not interesting for DRBD. It will just sit there and replicate whatever blocks change.
So you say it can protect me from disk failures, huh? There’s a configuration called “on-io-error” and it can be configured to “detach”. This means that in case of a local I/O error on the active machine, DRBD will just detach the backing block device from the DRBD device and write changes to the backup node, read operations will also silently be served by the backup node. The application using the DRBD device won’t even notice that the physical disk failed. Once you replaced the disk, you may just attach the DRBD resource to the new disk and your customers will not even notice you had an outage. Well, maybe things will be a little slower temporarily, but that’s still way better than an outage in the middle of the day.
So, thank you DRBD. Thank you Linbit. For this well documented awesome piece of free software that made me sleep at night instead of rushing to fix things, that enabled me to run things on standard hardware instead of having to buy overly expensive SAN things, that even helped me overcome laziness in creating backups of my digital photos.