We sometimes get asked, “Why not simply use a mirrored SAN instead of DRBD®”? This post shows some crucial differences between mirrored SAN and DRBD.
Basically, the first setup is having two servers, one of them actively driving a DM-mirror (RAID1) over (e.g.) two iSCSI volumes that two SANs export; the alternative is using a standard DRBD setup. Please note that both configurations need some cluster manager (like Pacemaker).
Here are the two setups visualized, showcasing the main differences:
| # | SAN | DRBD |
|---|---|---|
| 1. | High-cost, single supplier. | Lower-cost, commercial-off-the-shelf parts. |
| 2. | At least four boxes (2 application servers, 2 SANs). | Two servers are sufficient. |
| 3. | DM-Mirror has only recently gotten a write-intent-bitmap, and at least had performance problems (needed if active node crashes) | Optimized Activity Log. |
| 4. | Maintenance needs multiple commands. | Single userspace command: drbdadm. |
| 5. | Split-Brain is not automatically handled. | Automatical Split-Brain detection – policies via DRBD configuration. |
| 6. | Data Verification needs to get all data over the network – twice | Online-Verify transports (optionally) only checksums over the wire. |
| 7. | Asynchronous mode (via WAN), not in a standard product. | Protocol A available – optional proxy for compression and buffering. |
| 8. | Black Box. | GPL solution, integrated in standard Linux Kernel since 2.6.33. |
So the Open-Source solution via DRBD has some clear technical advantages – not just the price. And, if that’s not enough, with LINBIT®, you get world-class support, too!
