This is rather dependant on SS version. So what used to happen before 4.2.2.* is that a client would be unable to mount the filesystem in question and would give an error in the mmfs.log.latest for an SGPanic, In 4.2.2.* It appears it will now mount the file system and then give errors on file access instead. (just tested this on 4.2.2.3) I'll have to read through the changelogs looking for this one.
Depending on your policy for encryption then, this might be exactly what you want, but I REALLY REALLY dislike this behaviour. To me this means clients can now mount an encrypted FS now and then fail during operation. If I get a client node that comes up improperly, user work will start, and it will fail with "Operation not permitted" errors on file access. I imagine my batch system could run through a massive amount of jobs on a bad client without anyone noticing immeadiately. Yet another thing we now have to monitor now I guess. *shrug* A couple other gotcha's we've seen with Encryption: Encrypted file systems do not store data in large MD blocks. Makes sense. This means large MD blocks aren't as useful as they are in unencrypted FS, if you are using this. Having at least one backup SKLM server is a good idea. "kmipServerUri[N+1]" in the conf. While the documentation claims the FS can continue operation once it caches the MEK if an SKLM server goes away, in operation this does NOT work as you may expect. Your users still need access to the FEKs for the files your clients work on. Logs will fill with Key <key> could not be fetched. errors. Ed Wahl OSC ________________________________________ From: [email protected] [[email protected]] on behalf of Simon Thompson (Research Computing - IT Services) [[email protected]] Sent: Thursday, April 06, 2017 4:20 AM To: [email protected] Subject: [gpfsug-discuss] Spectrum Scale Encryption We are currently looking at adding encryption to our deployment for some of our data sets and for some of our nodes. Apologies in advance if some of this is a bit vague, we're not yet at the point where we can test this stuff out, so maybe some of it will become clear when we try it out. For a node that we don't want to have access to any encrypted data, what do we need to set up? According to the docs: https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s cale.v4r22.doc/bl1adv_encryption_prep.htm "After the file system is configured with encryption policy rules, the file system is considered encrypted. From that point on, each node that has access to that file system must have an RKM.conf file present. Otherwise, the file system might not be mounted or might become unmounted." So on a node which I don't want to have access to any encrypted files, do I just need to have an empty RKM.conf file? (If this is the case, would be good to have this added to the docs) Secondly ... (and maybe I'm misunderstanding the docs here) For the Policy https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru m.scale.v4r22.doc/bl1adv_encryptionpolicyrules.htm KEYS ('Keyname'[, 'Keyname', ... ]) KeyId:RkmId RkmId should match the stanza name in RKM.conf? If so, it would be useful if the docs used the same names in the examples (RKMKMIP3 vs rkmname3) And KeyId should match a "Key UUID" in SKLM? Third. My understanding from talking to various IBM people is that we need ISKLM entitlements for NSD Servers, Protocol nodes and AFM gateways (probably), do we have to do any kind of node registration in ISKLM? Or is this purely based on the certificates being distributed to clients and keys are mapped in ISKLM to the client cert to determine if the node is able to request the key? Thanks Simon _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
