[gpfsug-discuss] Experiences upgrading in place to GPFS 4.1?
Marc A Kaplan
makaplan at us.ibm.com
Fri Apr 17 15:37:55 BST 2015
An "Encrypt-in-place" feature would not survive a serious, paranoid
security audit.
If sensitive data ever was written to a disk, then the paranoid would say
you can never be 100% sure that you have erased it.
That said, you decide how worried or paranoid you'd like to be and you can
do an almost in place encryption as James Davis suggests by
simply copying the unencrypted file to a new file that will be subject to
a GPFS encryption policy (SET ENCRYPTION) rule.
The safest way would be to copy-encrypt all the data to a new file system
and then crush all the equipment that was used to store the clear-text
files.
If crushing is too extreme, you might settle for a multipass sector by
sector soft scrubbing by writing both carefully chosen and random data
patterns.
Even then, unless you trust the manufacturer AND the manufacturer has
provided you the means to "scrub" all the tracks/sectors of the disk you
won't be sure... Suppose that some sensitive data was written to a sector
number that was later declared (partially) defective and remapped by the
disk micro-code, and the original sector is put in a bad sector list that
you can no longer address with standard disk driver software...
Or it could be on some NVRAM or a disk that a service technician swapped
out... Ooops... it went out the door... and is now in the hands of the
bad guys...
From: James Davis/Poughkeepsie/IBM at IBMUS
To: gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date: 04/17/2015 10:12 AM
Subject: Re: [gpfsug-discuss] Experiences upgrading in place to
GPFS 4.1?
Sent by: gpfsug-discuss-bounces at gpfsug.org
Hi Chris,
Based on your question I think you are aware of this already, but just in
case...
There is not currently an encrypt-in-place solution for GPFS encryption. A
file's encryption state is determined at create-time. In order to encrypt
your existing 100TB of data, you will need to apply an encryption policy
to the current (or a new) GPFS file system(s) and then do something like:
cp file file.enc #now file.new is encrypted
mv file.enc file #replace the unencrypted file with the encrypted file
This can be done in parallel using mmapplypolicy if you want. In 4.1.1
(forthcoming) I plan to provide an improved version of the
/usr/lpp/mmfs/samples/ilm/mmfind (a find-esque interface to mmapplypolicy)
that shipped in the last release; this should be an effective tool for the
job.
Cheers,
Jamie
Jamie Davis
GPFS Functional Verification Test (FVT)
jamiedavis at us.ibm.com
Daniel Kidger ---17-04-2015 08:16:54 AM---Hi Chris, The Crypto feature of
GPFS 4.1 requires the addition of just one extra
From: Daniel Kidger <daniel.kidger at uk.ibm.com>
To: gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date: 17-04-15 08:16 AM
Subject: Re: [gpfsug-discuss] Experiences upgrading in place to GPFS 4.1?
Sent by: gpfsug-discuss-bounces at gpfsug.org
Hi Chris,
The Crypto feature of GPFS 4.1 requires the addition of just one extra
RPM over the standard edition. Other RPMs remain the same.
It also requires licenses for "Advanced Edition". These are of the order
of 30% more expensive than the standard edition.
The model for GPFS encryption at rest is that the client node fetches the
encrypted file from the fileserver.
The file remains encrypted in transfer and is only decrypted by the client
node using a key it holds.
A result is end-to-end encryption as well as encryption of data at rest,
Encryption can be on a per file level if desired. Hence a way to migrate
from an existing non-encrypted. setup.
note inodes should be 4kB to make sure there is enough room to store the
encryption attributes.
A side effect of adding encryption is that you also need additional remote
key management (RKM) servers to handle the key management. These need
licensed software.
see
http://www-01.ibm.com/support/knowledgecenter/SSFKCN_4.1.0.4/com.ibm.cluster.gpfs.v4r104.gpfs200.doc/bl1adv_encryptionsetupreqs.htm
I am sure DDN can help you with all of this.
Hope this helps,
Daniel
Dr.Daniel Kidger
No. 1 The Square,
Technical Specialist SDI (formerly Platform Computing)
Temple Quay,
Bristol BS1 6DG
Mobile:
+44-07818 522 266
United Kingdom
Landline:
+44-02392 564 121 (Internal ITN 3726 9250)
e-mail:
daniel.kidger at uk.ibm.com
From: Frank Leers <fleers at gmail.com>
To: gpfsug main discussion list <gpfsug-discuss at gpfsug.org>
Date: 16/04/2015 23:21
Subject: Re: [gpfsug-discuss] Experiences upgrading in place to
GPFS 4.1?
Sent by: gpfsug-discuss-bounces at gpfsug.org
Hi Chris,
Since you mention GRIDScaler, I assume that you are a DDN customer and
that you have a support contract with them. If not, then feel free to
take the advice that follows with a measure of salt although it mostly
still applies ;-)
With 4.1, there are now 'Editions' of GPFS, which break out various
feature sets into a tiered arrangement, with each tier being licensed (and
possibly priced) differently.
Have a look here (Q 1.3) for the 4.1 licensing notes -
http://www-01.ibm.com/support/knowledgecenter/SSFKCN/com.ibm.cluster.gpfs.doc/gpfs_faqs/gpfsclustersfaq.html
With GPFS 3.5, you are most likely running the equivalent of the 'Standard
Edition' today. The crypto feature set comes with the 'Advanced Edition',
which is licensed differently.
Have a look at Chapter 15 of the Advanced Admin Guide for 4.1 as a primer
...
http://www-01.ibm.com/support/knowledgecenter/SSFKCN_4.1.0.4/gpfs4104_content.html
-frank
On Thu, Apr 16, 2015 at 1:33 PM, Garrison, E Chris <ecgarris at iu.edu>
wrote:
Hello,
My site is working up to upgrading our paired GridScaler system from GPFS
3.5 to 4.1. There is a mandate to provide encryption at rest, and that's
an advertised feature of 4.1. We already have over 100 TB of data,
synchronously replicated between two geographically separated sites, and
we have concerns about how the upgrade, as well as the application of
encryption to all that data, will go.
I'd like to hear from admins who've been through this upgrade. What
gotchas should we look out for? Can it easily be done in place, or would
we need some extra equipment to "slosh" our data to and from so that it is
written to an encrypted GPFS?
Thank you for your time, and for any sage advice on this process.
Chris
--
Chris Garrison
Indiana University
Research Systems Storage
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21994 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0018.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0019.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0020.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0021.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0022.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20150417/04bba1fb/attachment-0023.gif>
More information about the gpfsug-discuss
mailing list