[DRBD-user] Best practice advice needed

Felix Frank ff at mpexnet.de
Wed Jan 2 10:34:41 CET 2013

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Hi,

On 12/28/2012 10:49 PM, Andreas Heinlein wrote:
> * Split it up into multiple DRBD devices, one for each service, and put
> the LVM underneath the DRBD layer to be able to resize when needed.
> Would mean several devices would have to be encrypted individually,
> which adds complexity, but it's not impossible.

this sounds good. If the partition underneath LVM is encrypted, why
would you need additional encryption layers?

Of course, your writes are passed unencrypted between your nodes, but
you do have a dedicated link of course ;-) so that should not be a cause
for concern.

> * Convert the filesystem to GFS or OCFS and run DRBD in dual-primary
> mode. Would allow for a load-balancing active/active-cluster in the
> future, but I'm afraid of side effects. For example I read that GFS does
> not fully support inotify/dnotify, which our mail service currently
> makes use of.

Not speaking from experience, but you're looking at a whole new layer of
performance issues adding to your encryption (did someone say
mailserver? :-)

> * Export the whole /srv via NFS, then remount subdirectories of it e.g.
> under /mnt/mail, /mnt/www... In the case of a service failure, the
> service itself could be moved from A to B, while accessing its data via
> NFS from A. Probably a weird idea not worth looking at.

Yes, that will likely end up too shrewd. Keep in mind that many efforts
of raising availability may in fact lower it when the complex things you
introduce go wrong at some point...

Long story short, my advice is to go with your first idea of creating a
drbd resource for each independent service, whichever way best befits
your setup.

Cheers,
Felix



More information about the drbd-user mailing list