#Convert a non-NAE aggregate to an NAE aggregate

1 messages · Page 1 of 1 (latest)

turbid nexus
#

Is it possible to first do an volume encryption on your existing volumes with "volume encryption conversion start" command and when the volumes in the aggregate are encrypted using the command "storage aggregate modify -aggregate aggregate_name -node node_name -encrypt-with-aggr-key true"' ?

I don't seem to find any explanation about this in the documentation whether it is doable or not.
Running ONTAP Version is 9.13.1P7

Thanks!

#

So principely i want to encrypt existing volumes and then do aggregate encryption so we can do inline or background aggregate-level deduplication

tawny wing
#

In order to enable aggregate encryption all volumes on the aggregate must be encrypted using NVE. Note that the volume encryption conversion start takes significantly longer than “vol move -vserver xx -volume yy -destination-aggr zz -encrypt-destination true” but you need to have space for the move

If you wish to convert all to NAE, you’ll do this anyway since that conversion command only works to convert to NVE.

So:
Convert all to NVE
Flip the aggregate bit to allow NAE
Convert all volumes to NAE

turbid nexus
#

What do you mean by flip the aggregate bit ?

Cause in my understanding encrypting the volumes NVE each volume gets an encryption key whilst the NAE is 1 key for the whole aggregate.
Which in turn if you first encrypt the volumes using NVE you can not convert all those keys to 1 key for NAE ?

Or am i missing something here

#

So i guess the proper way for NAE is with volume moves ?

tawny wing
#

No. The aggregate isn’t really encrypted. Misnomer. After all volumes are NVE then you modify the the aggregate (aggr modify -aggregate xxx -encrypt-with-aggr-key true). It won’t work unless all volumes on the aggregate are encrypted.

After the bit is set, you may begin the process of converting the volumes to NAE.

Search through discord for my posts. I had a detailed one exactly about this a few weeks ago.

Convert volumes to NVE
If on 9.14 this includes SVM root
If earlier, move all SVM roots to one aggregate.
Flip aggr bit for encryption on all aggregates. If 9.13 or earlier, move SVM roots to encryption:
Volume move start -vserver xx -volume svm_xx_root -destination-aggr nae-aggr -encrypt-with-aggr-key true
If needed flip boot on last aggregate. Then do the vol moves to flip from NVE to NAE

#

Verify status of things

Vol show -fields volume, vserver, encryption-type, encrypt

The encryption type will be volume or aggregate (possibly none) and encrypt will be true or false

odd sable
#

In other words: If you don't have an empty aggregate available, you need to encrypt all your volumes twice:

  1. unencrypted vol --> NVE vol
  2. NVE vol --> NAE vol

It's really unfortunate but atm there is no other way. The "aggr-NAE-bit-flip" is only valid for any new volume being created on the aggr after NAE has been enabled. So you need to re-encrypt your NVE vols again (by using vol move).

If you manage to empty one aggr (by moving all volumes away to another aggr) you can enable the bit there first, and then directly encrypt your vols using the NAE key by moving it to the empty NAE aggr.

#

Also two notes:

  • If you have cross-volume deduplication enabled on your SSD-aggrs you need to be careful, because by using NVE you will lose the savings. Only after encrypting it the second time with the NAE (and then scanning all the old) you will regain the savings.
  • If you have many thick volumes (space-guarantee=volume) don't just paste in all the vol-move commands. Only 8x concurrent vol moves are possible per node so all the other vol moves need to wait. That would be of no issue but all the waiting vol-moves already allocated space for the destination-volume on the aggr, meaning if you paste in like 200x vol moves you could easily fill up all the available space.
tawny wing
#

I’ve worked plenty of customers with this process. Most (not all though) had enough space on the aggregates to “volume move in place”. In other words we would do something like:
set diag
vol show -fields size, used, available, space-guarantee aggregate -sort-by aggregate, used
If any volumes were thick (volume space guarantee) we would for the process change to thin so the move goes faster and would not require “full” volume space, only what is actually used.
Beyond that, we would basically process 1-2 moves at a time per aggregate keeping the destination the same as the source.

odd sable
#

Yeah, I'm mostly doing the same.
I create a big vol-table, sort by used-size and create the cmds in Excel (always moving to the original aggr). Then paste in all the volumes <1TB. For everything bigger we need to monitor aggr-space.

tawny wing
#

Bingo. We have a bingo

odd sable
#

Currently 116 vols in my vol move list, hope most is done on Monday 🐌

tawny wing
#

Customer: 3 sites. Each site over 400 volumes!

odd sable
#

For all the vols in SSD-aggrs the moving is faster but we have not much space left. I really need to be careful because of all the cross-vol dedup. That's usually not much fun.

tawny wing
#

Probably should mention to revise efficiencies on aff after the moves also

odd sable
#

This customer has 11x cluster. They decided "hey we want data-at-rest encryption for everything!"
The big nearstore with almost 1PB is already done. 😮‍💨

#

took only a month

#

Moving on with the primary systems. 🙌

turbid nexus
#

Thanks for responding.
The original question was regarding a tech refresh with one of our customer where there was the option to do it via a headswap with ARL.
But that is meanwhile out of the question because customer wants to use this tech refresh to re-ip his storage environment

#

So plan is to make a 4 node switched cluster (is a 2 node switchless cluster atm) and do the encryption with vol moves