[dm-crypt] LUKS in failover cluster
Sohl, Jacob (LNG-SEA)
jacob.sohl at applieddiscovery.com
Wed Oct 12 01:34:21 CEST 2011
> -----Original Message-----
> From: dm-crypt-bounces at saout.de [mailto:dm-crypt-bounces at saout.de] On
> Behalf Of Arno Wagner
> Sent: Friday, October 07, 2011 9:53 PM
> To: dm-crypt at saout.de
> Subject: Re: [dm-crypt] LUKS in failover cluster
> On Fri, Oct 07, 2011 at 05:54:48PM -0700, Sohl, Jacob (LNG-SEA) wrote:
> > Hi all,
> > I've been working on a design for an encrypted fileserver using
> > On a single server the stack is pretty simple:
> > SAN LUNs > LUKS > LVM > XFS > Samba Server
> > But I would like to have a second node for High-Availability
> > (SAN storage is available to both nodes). I'm looking at Red Hat
> > Suite with corosyn, rgmanager. rgmanager has the ability to manage
> > XFS and Samba resources. In the event of node failure, it will
> > all resources to the healthy node. But the resources are only
> > if the SAN volumes are decrypted:
> > cryptsetup luksOpen /dev/sdc1 crypt_vol
> > Is it possible to have the raw volumes decrypted on both systems,
> > during boot. So the LUKS device (/dev/mapper/crypt_vol) will be
> > available on the backup node in the event of primary node failure.
> > other resources - LVM, XFS, Samba - would only be on one node at a
> > so no filesystem access from the passive node. If this is not
> > then can you suggest another solution?
> You can map ("decrypt") the devices and never use them. The
> LVM/mount/whatever is completely optional.
> In fact the mapper tool (cryptsetup) does nothing except
> to decrypt the raw encrypted device to a raw decrypted device
> under /dev/mapper/.
Ok, thank you. That seemed logical, but I just recently started working
with encryption so I'm still learning.
> > Also, scalability is a requirement in my design, hence XFS. I was
> > thinking I needed to use multiple LUKS PVs in LVM to grow the
> > filesystem. But I would end up with multiple LUKS devices to keep
> > of. I recently found out that LUKS can resize.
> LUKS _cannot_ resize. The thing is that LUKS does not care about
> device size. So if you enlarge a device/partition with an intact
> LUKS header, "cryptsetup luksOpen" will just map the larger
> If you have multiple devices, you can "slave" the additional ones
> to a "master" device using something like "decrypt_derived".
> This just takes the master key from the opened "master" container,
> runns it though a hash and uses this as key for the "slave"
> > Would it be better to
> > create one LUKS device on top of LVM? Then create a filesystem on
> > (Though that would affect resource dependencies.)
> Sre you sure you need LVM at all?
Yes, I do need LVM. I'm dealing with ~50TB of data and the SAN admins
can/will only attach storage in 4TB increments. So I have to combine all
of the LUNS into one Logical Volume in order to create a 50TB+ XFS
filesystem. That's why I ask about encrypting multiple physical LUNS vs
a single Logical Volume.
> > But basically:
> > SAN LUNs > LVM > LUKS > XFS > Samba Server
> > Other people will be accessing/managing this system, so I want
> > manageability through simplicity.
> Hence the question whether you actually need LVM.
> It strikes me that typically LVM is not needed and
> just complicates matters.
> > Don't want to have the wrong volumes
> > (re)encrypted, headers damaged, etc.
> I think this setup is already too complicated for most people
> to manage. A full backup should be part of your plans.
> Resize with backup is actually easier, as you can just
> backup, kill everything and do a clean new config.
I will be making full backups with xfsdump. But it doesn't seem
practical to be moving 50TB around. Both LVM and XFS allow for designed
for online resize. I was planning to "pvcreate" an encrypted LUN then
expand the Logical Volume and Filesystem.
> > Anyways, thanks for your help.
> Just to make sure: You _have_ read the FAQ?
Yes I have read the FAQ. I guess I am just a little nervous about this
project. This is my first time working with encryption and 50TB of
critical client data is at stake. Just being thorough and making sure I
fully understand everything.
> > Jacob Sohl | Systems Engineer
> > Applied Discovery(r)
> > Mobile: 360-620-2695
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno at wagner.name
> GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> If it's in the news, don't worry about it. The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier
> dm-crypt mailing list
> dm-crypt at saout.de
More information about the dm-crypt