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