[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
> 
> Hi,
> 
> 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
> RHEL6.x.
> > 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
failover
> > (SAN storage is available to both nodes). I'm looking at Red Hat
> Cluster
> > Suite with corosyn, rgmanager. rgmanager has the ability to manage
> LVM,
> > XFS and Samba resources. In the event of node failure, it will
> migrate
> > all resources to the healthy node. But the resources are only
> available
> > if the SAN volumes are decrypted:
> >
> > cryptsetup luksOpen /dev/sdc1 crypt_vol
> >
> >
> >
> > Is it possible to have the raw volumes decrypted on both systems,
> maybe
> > during boot. So the LUKS device (/dev/mapper/crypt_vol) will be
> > available on the backup node in the event of primary node failure.
> The
> > other resources - LVM, XFS, Samba - would only be on one node at a
> time,
> > so no filesystem access from the passive node. If this is not
> possible
> > 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
> track
> > 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
> device.
> 
> 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"
> device.
> 
> > Would it be better to
> > create one LUKS device on top of LVM? Then create a filesystem on
> that?
> > (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.
Thanks again,
Jacob Sohl

> 
> Arno
> 
> >
> > 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
1E25
> 338F
> ----
> 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
> http://www.saout.de/mailman/listinfo/dm-crypt




More information about the dm-crypt mailing list