LVM-LUKS: Best practice for large encrypted volume?

Latest response

So, the auditors have mandated that our large (currently 6TB) volume be encrypted.

I will be building a new volume and moving the data over.

However, the volume will continue to grow, so I would prefer to continue to use LVM so we can add more disks as needed.

So, the question is LVM over LUKS, or vice versa?

I'm looking for stories from others who have done this -- including pitfalls and gotchas.

JB
Log in to join the conversation

Responses

R. Hinton's picture Guru 6827 points
17 June 2015 8:34 PM

Jim, a number of people will probably participate in this, but a few initial questions...
- What file system were you planning on using? ext4? xfs (like on RHEL 7.x), or something else?
- Will you be using a raid array (what sort of raid setup), or SAN attached storage? How fast is the HBA card if it is SAN?
-- If SAN, is it tier 1 or 2 storage?
- If not SAN, are the disks spinning disks, SSD, SATA, SAS etc?
- Will only one host read/write to the volume in question? Or is it presented to other hosts and shared amongst other systems?
- What sort of disk write speed would be the minimum acceptable speed for your volume? And read speed?

Those are some initial questions, and I anticipate others will have salient questions/tips/input.

Kind regards...

JB Community Member 22 points
17 June 2015 9:23 PM

This is on a RHEL 6.6 machine in a.VMware environment, using virtual disks. Planning on using ext4. The volume is shared using NFS to two application servers. The main activity is storing documents scanned by the users.

Good question about the read and write speed. -- and I don't have an answer. There have been no complaints about the current non-encrypted system.

R. Hinton's picture Guru 6827 points
17 June 2015 9:34 PM

Jim,

Some other thoughts, not directly addressing LUKS on top of LVM... Tom's reply below may satiate your requirement

Do you have tier 1 and tier 2 speed SAN available? I know of at least one entity who does have tier 1 and tier 2 SAN presented to their VMware systems.
- Side note, make sure /etc/updatedb.conf is configured to AVOID your nfs/san, or it will index it all for as many systems have indexing on (updatedb) active.
- Is the file system server serving small tiny files, or larger files?
- Check to see if anyone is "nagging" the file system. One example... We had one person once who was running "ls -lR" with a watch command against a directory at one time, along with persistent find commands. The "-l" will force the system to interrogate all inodes, whereas a flat 'ls' will not (but we gave them enough "feedback" to make them stop that bad practice).
- Is this specific file system shared by nfs something that anyone can access where you have a competition of production needs and a myriad of ad-hoc requests?
- Can the production-needed portions of the nfs server be segregated (would take time) and represented to production servers and the non-production directory tree be separated for non-production users (if this is even needed or even a factor)?

thomas.jones2@dodiis.mil's picture Guru 6435 points
17 June 2015 8:40 PM

We've done LUKS on top of LVM, but extending LUKS after extending the hosting LV has tended to be more involved than simply extending an encrypted LUN on an array. Array-level key-management also tends to be a bit less tiresome.

Thus, we've generally avoided the issue by using array-level encryption.

JB Community Member 22 points
17 June 2015 9:26 PM

We were hoping that our VMWare provider would encrypt at their level, but they don't want the responsibility if something goes wrong and data is lost :)

thomas.jones2@dodiis.mil's picture Guru 6435 points
17 June 2015 9:28 PM

Whoa. That raises all sorts of questions about why they're so un-confident in their array!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.