Now you may not believe me, but there actually are situations when DRBD is not the right choice for meeting your storage needs. Since I’ve been asked to compile some of these and present them here, let’s take a look.
Don’t use DRBD when…
- All or most of your data is static. Front-end web servers are a prime example for this. Even though they usually serve highly dynamic content these days, your PHP documents and Perl scripts and JSP‘s usually don’t change that often. Using DRBD for that type of data isn’t much use. Use DRBD for your backend store instead. On the front end, you’ll do fine with rsync, although it doesn’t scale well for large sets of files. Give csync2 a shot.
- Your application requires sub-second failover. If you you deploy DRBD in active/passive (failover) mode, expect Heartbeat, RHCS, or the other cluster manager of your choice to take around 15-20 seconds for failover. Any subsequent recovery procedures by your application may add to that. It’s highly unlikely that you’ll go beyond 1 minute failover time when your setup is properly done, but if that really is way too much for you, turn away from DRBD/Heartbeat. For example, for databases, get MySQL Cluster, or Oracle RAC. By the way you can use DRBD for the latter, just not with Heartbeat.
- You are required to provide synchronous 3-way redundancy. In some environments, by legal requirements 2-node automatic failover is just not enough. Many aviation systems are an example, to my knowledge, as are life support systems in health care. For the time being, DRBD doesn’t go beyond 2 nodes synchronously (DRBD+does support 3 nodes, but that feature is for disaster recovery, not 3-way failover).. Edit: I wrote this post long before the release of DRBD 8.3. Since 8.3, DRBD is entirely suitable for use with synchronous replication across as many as 4 nodes.
- You only need replication for one particular purpose, and want extreme optimization. If, for example, a MySQL database is the only thing you’re ever going to replicate, you may be better off using MySQL replication. It’s pretty challenging stuff getting it to work with a master-slave setup that does automatically and reliably switch roles on node failure, but admittedly in enables you to do some advanced things DRBD doesn’t offer. If, however, you’re thinking about replicating PostgreSQL and Oracle and Samba and NFS and Xen backend devices too, then, well, DRBD may be not that bad a choice after all.
- You dislike your boss, and love anything that may cut into his or her bonus. Isn’t a pair of synchronous replication capable SAN boxes a lovely huge item on any hardware bill?