One of the things that repeatedly seem to puzzle users about the DRBD is the question of whether to use internal or external metadata. Remember, DRBD sets aside a small area on a local disk (on every cluster node) where it keeps the Activity Log, the quick-sync bitmap, data generation UUIDs, and a few other bits and pieces for local housekeeping.
The specific aspect that is to be discussed here is the Activity Log. Without going into too much detail, let’s be satisfied with the factoid that DRBD “occasionally” (it’s a little more involved in reality) writes to the AL, and has to wait for that write to complete before it can handle user data again. This wait is the crucial point. It’s usually on the order of just a few milliseconds, but on busy systems this can add up to where it throttles throughput just a little.
Now, what makes I/O fast or slow (on rotational hard drives, solid state is a different matter)? That’s right, it’s disk seeks. So when we use internal meta data, so the theory goes, the read-write head has to do something in the data area, then move to the AL and do something there, then move back to the data area, and so forth. Which, intuitively, can be speeded up if you put user data and meta data on different spindles. Different “logical” disks won’t do, it has to be on a separate spindle, so read-write heads can move in parallel. Again, this is as the naïve theory goes. Use external meta data, devise a clever scheme on how to spread your meta data apart from your user data, and you’ll be fine. And you can call yourself a great wizard in storage subsystem tuning. Well, not quite, unfortunately.
Posted by Florian Haas 
Florian's blog 