Friday, 7 February 2020

How to SnapMirror a Large File from an Enormous Volume and Only Need the Large File Size Available on the Destination

Scenario: You have a database file in a volume on cluster1, and you want to get that file to cluster2. The problem is that the volume is too big to be SnapMirror-ed to cluster2 (there is not enough space on cluster2’s aggregates). So, how do you get just the file you want to move to cluster2?

The answer is to use FlexClone. We can:
- Flexclone the volume
- Delete everything but the “Large File” from the volume
- Split the clone
- Delete the clone snapshots
- SnapMirror the “Large File” to where it needs to go.

The following example illustrates this with fairly small files really, but hopefully you get the gist.

Example

Our volume has 7821MB used. And the aggregate utilization on cluster1 aggr_dp is 8037MB. The volume ‘tvol_001’ is made up of 6 *.db files.


cluster1::> vol show -volume tvol_001 -fields used,snapshot-policy
vserver volume   used   snapshot-policy
------- -------- ------ ---------------
svm1    tvol_001 7821MB none

cluster1::> aggr show -aggr aggr_dp -fields usedsize
aggregate usedsize
--------- --------
aggr_dp   8037MB


Image: tvol_001 with 6 database files

We create our flexclone volume tvol_001_clone. And see it makes little difference to the aggregate size.


cluster1::> volume clone create -flexclone tvol_001_clone -vserver svm1 -junction-path /tvol_001_clone -parent-volume tvol_001

cluster1::> aggr show -aggr aggr_dp -fields usedsize
aggregate usedsize
--------- --------
aggr_dp   8094MB

cluster1::> vol show -volume tvol_001_clone -fields used,snapshot-policy
vserver volume         used   snapshot-policy
------- -------------- ------ ---------------
svm1    tvol_001_clone 7799MB none


Then we create a cifs share to get to the flexclone and delete all the *.db files except database6.db. Notice the aggregate size does not change.

‌‌
cluster1::> cifs share create -share-name tvol_001_clone -vserver svm1 -path /tvol_001_clone


Image: Deleted everything except database6


cluster1::> vol show -volume tvol_001_clone -fields used,snapshot-policy
vserver volume         used   snapshot-policy
------- -------------- ------ ---------------
svm1    tvol_001_clone 6798MB none

cluster1::> aggr show -aggr aggr_dp -fields usedsize
aggregate usedsize
--------- --------
aggr_dp   8095MB

cluster1::> vol snapshot show -volume tvol_001* -fields owners,size
vserver volume   snapshot               owners         size
------- -------- ---------------------- -------------- ----
svm1    tvol_001 clone_tvol_001_clone.1 "volume clone" 0MB
svm1    tvol_001_clone clone_tvol_001_clone.1 "volume clone" 5545MB


Then we split the clone and see that the used size of the aggregate roughly increases by the size of the database6.db file.


cluster1::> vol clone split start -vserver svm1 -flexclone tvol_001_clone

Warning: Are you sure you want to split clone volume tvol_001_clone in Vserver svm1? {y|n}: y
[Job 107] Job is queued: Split tvol_001_clone.

cluster1::> vol clone split show -fields block-percentage-complete
vserver flexclone      block-percentage-complete
------- -------------- -------------------------
svm1    tvol_001_clone 65

cluster1::> vol clone split show -fields block-percentage-complete
There are no entries matching your query.

cluster1::> aggr show -aggr aggr_dp -fields usedsize
aggregate usedsize
--------- --------
aggr_dp   11122MB


Now we delete the clone snapshots. If we didn’t, we’d end up replicating the full size of the tvol_001, when we replicate tvol_001_clone, since the previous deletions were captured in the clone snapshot which would get mirrored too.


cluster1::> vol snapshot show -volume tvol_001* -fields owners,size
vserver volume   snapshot               owners size
------- -------- ---------------------- ------ ----
svm1    tvol_001 clone_tvol_001_clone.1 -      0MB
svm1    tvol_001_clone clone_tvol_001_clone.1 - 5545MB

cluster1::> vol snapshot delete -vserver svm1 -volume tvol_001* -snapshot *

cluster1::> aggr show -aggr aggr_dp -fields usedsize
aggregate usedsize
--------- --------
aggr_dp   8150MB


Not totally sure why the aggregate space went down after deleting the snapshots, could it be to do with aggregate deduplication (this lab is running ONTAP 9.4)? Answers on a postcard...


cluster1::> aggr show -field sis-space-saved
aggregate         sis-space-saved
----------------- ---------------
aggr0_cluster1_01 0MB
aggr_dp           5337MB


So, now we are left with our original volume (untouched) and the clone volume with the database6.db file in.


cluster1::> volume show -volume tvol_001* -fields used
vserver volume   used
------- -------- ------
svm1    tvol_001 7822MB
svm1    tvol_001_clone 2277MB


Now we SnapMirror the volume with the file in to cluster2. Essentially one action command and the volume is SnapMirrored!


cluster2::> aggr show -aggr aggr_dp -fields used
aggregate usedsize
--------- --------
aggr_dp   40MB

cluster2::> snapmirror protect -path-list svm1:tvol_001_clone -destination-vserver svm_dst1 -policy MirrorAllSnapshots
[Job 103] Job is queued: snapmirror protect for list of volumes beginning with "svm1:tvol_001_clone".

cluster2::> snapmirror show -destination-path svm_dst1:tvol_001_clone_dst -fields state,status
source-path         destination-path            state        status
------------------- --------------------------- ------------ ------
svm1:tvol_001_clone svm_dst1:tvol_001_clone_dst Snapmirrored Idle

cluster2::> aggr show -aggr aggr_dp -fields used
aggregate usedsize
--------- --------
aggr_dp   2325MB

‌cluster2::> volume show -volume tvol_001* -fields used
vserver  volume             used
-------- ------------------ ------
svm_dst1 tvol_001_clone_dst 2229MB


Finally, we can tidy up the SnapMirror relationship: break (on destination), delete (on destination), release (on source).


cluster2::> snapmirror break -destination-path svm_dst1:tvol_001_clone_dst
Operation succeeded: snapmirror break for destination "svm_dst1:tvol_001_clone_dst".

cluster2::> snapmirror delete -destination-path svm_dst1:tvol_001_clone_dst
Operation succeeded: snapmirror delete for the relationship with destination "svm_dst1:tvol_001_clone_dst".

cluster1::> snapmirror release -destination-path svm_dst1:tvol_001_clone_dst


Job done!

What’s New in ONTAP 9.7 (and Enhancements)

ONTAP 9.7 has been out since January 2020 (9.7 GA Package Build Date = 9th January 2020.)

Image: How to Upgrade to ONTAP 9.7 (since ONTAP 9.4 you can ‘Add (image) from Local Client’, no HTTP/FTP server required): ONTAP System Manager > Configuration > Cluster > Update

Below is just a snapshot of what’s new and the enhancements that are available with ONTAP 9.7.

Theme: Performance
- Introduction of End-to-End NVMe with new Mid-Range system (AFF A400)
- FlexCache enhancements including MCC and FlexGroup (origin) support
- ONTAP Select support of NVMe devices

Theme: Hybrid Storage
- Introduction of new Mid-Range system (FAS8300) and High-End system (FAS8700) storage systems

Theme: SAN
- Introduction of All SAN Array systems (ASA) enable with Symmetric Active-Active feature
- Enables instantaneous IO recovery from path or controller failure

Theme: Security
- Data-at-Rest Encryption by default: Leveraging HW or SW based encryption
- ActiveIQ Security Dashboard: Provides full orchestration of enabling security across cluster

Theme: Data Protection & Replication
- FabricPool Mirror: Enables mirroring the same data to multiple vendors for an additional level of resiliency
- NDMP support for large containers (FlexGroup) and for data tiering (Fabric Pool)
- SnapMirror Synchronous (SM-S) updates: Support for NVMe RPO=0, LUN cloning
- MetroCluster IP Enhancements: new platforms, tiering
-- MetroCluster FC on A400, FAS8300
-- MCC IP Open Network support
-- Mediator to enable AUSO for MCC IP
-- FabricPool and MCC-IP interoperability

Theme: Simplicity
- Redesigned system manager focusing on smart defaulting and visualization focused for the IT generalist
- Simplified Virtual Appliance (VSC) deployment by replacing API Services with REST calls for VM metrics, and using System Manager to create admin users (instead of RUC)

Theme: Scalable File System
- FlexGroup Enhancements
-- NFS v4.0 and v4.1 support
-- VAAI support
-- FlexVol to FlexGroup conversion

Image: ONTAP 9.7’s new and improved redesigned System Manager @ https://{CLUSTER}/sysmgr/v4 (Classic version is https://{CLUSTER}/sysmgr)

Thursday, 30 January 2020

Enabling ActiveIQ/AutoSupport with NetApp HCI 1.6 & 1.7

If you didn’t check the tick box to ‘Yes, I want to send cluster statistics to Active IQ to proactively monitor cluster health and performance’ when you were deploying your NetApp HCI, it is easy to enable this post deployment.

Image: HCI Review: Tick the Active IQ box: Final step before clicking Start Deployment

Pre-requisites

You’ll need these ports open on the firewall.

URLs for SF nodes to connect to AIQ (mNode = Management Node):
Source : Destination : Port : Description
mNode : sfsupport.solidfire.com : 22 : Reverse SSH tunnel for support access
mNode : https://repo.netapp.com/bintray/api/package : 443 : mNode service upgrades
mNode : https://netapp-downloads.bintray.com : 443 : mNode service upgrades
mNode : monitoring.solidfire.com : 443 : Storage cluster reporting to AIQ

You’ll also need the mNode IP/DNS name to connect to.
And credentials to login to the mNode.

Procedure Walkthrough

Step 1:
Connect to the mNode Management Services API (REST API UI):
https://{mNode IP or DNS}/mnode

Image: HCI/SolidFire mNode Management Services API

Step 2:
Click Authorize and submit credentials to log in.

Image: Authorize to the REST API UI

Step 3:
Click GET /assets
Click Try it out (changes to Cancel after you click)
Click Execute
Copy the value for the base asset ID (which is af82e8c4-e072-48e4-b438-c00c1ebe45f1 in the example below.)

Image: GET /assets

Image: The base asset ID

Step 4:
Click PUT /assets/{asset_id}
Click Try it out (changes to Cancel after you click)
Enter the following JSON payload:
{
 "name": "string",
 "telemetry_active": true,
 "config": {}
}
Enter the asset_id you obtained above.
Click Execute

Image: NetApp HCI set telemetry_active = true

Step 5:
That’s it!

You can re-execute the GET /assets above, and you should see:
"telemetry_active": true

Image: Telemetry Active = true

And if you login to -
- you should shortly see your cluster in there.

Wednesday, 29 January 2020

NetApp Aggregate Encryption: Some Examples and Some Questions Answered

When NetApp Aggregate Encryption came out with ONTAP 9.6, there was some excitement for two reasons (the second probably being the biggest reason):
- i: Create a new aggregate and enable NAE on it, and then all the new volumes created on the NAE aggregate are encrypted (by NAE).
- ii: NVE volumes do not participate in aggregate deduplication savings, but NAE volumes in an NAE aggregate do participate in aggregate deduplication savings.

If you have existing aggregates with data on them, enabling NAE isn’t as simple as just switching it on. Every volume in the aggregate needs to be encrypted with NVE first, then you can enable NAE on the aggregate. But, if the aggregate is NAE, and all the volumes are NVE, well, you won’t get those aggregate deduplication savings (which was probably the main reason for enabling NAE in the first place.)

Also, if you have a system with just one aggregate and existing data, you’ll be a little stumped because the SVM rootvol can’t be NVE encrypted, so unless you can make a tiny temporary NAE aggregate out of spares to vol move the SVM rootvol to and then back once the main aggregate is NAE (or find another trick), you’re stuck with a non-encrypted aggregated.

I always think things make much more sense with examples, so below are 11 examples which follow on from one another and hopefully aid understanding.

Clustershell Guided Examples

1) Enable Onboard Key Manager (OKM):


cluster1::> security key-manager onboard enable


Note: The passphrase needs to be 32 to 256 ASCII-range characters long otherwise you get:
Error: command failed: The onboard passphrase must be 32 to 256 ASCII-range characters long.

After configuring onboard key management, save the encrypted configuration data in a safe location so that you can use it if you need to perform a manual recovery operation. To view the data, use the "security key-manager onboard show-backup" command.


cluster1::> security key-manager onboard show-backup


2) Create a brand new NAE aggregate (encrypt-with-aggr-key true):


cluster1::> aggr create -node cluster1-01 -aggr n1_aggr1 -diskcount 10 -encrypt-with-aggr-key true

cluster1::> aggr show -fields encrypt-with-aggr-key -root false
aggregate encrypt-with-aggr-key
--------- ---------------------
n1_aggr1  true


3) Create a volume on an NAE aggregate with fairly default settings and see its encryption status:


cluster1::> vol create -vserver svm0 -volume vol01 -aggregate n1_aggr1 -size 1G -security-style unix

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted -volume vol01
vserver volume encryption-type encrypt is-encrypted
------- ------ --------------- ------- ------------
svm0    vol01  aggregate       true    true


4) Create a non-NAE aggregate for testing purposes:


cluster1::> aggr create -node cluster1-02 -aggr n2_aggr1 -diskcount 10 -encrypt-with-aggr-key false ‌

cluster1::> aggr show -fields encrypt-with-aggr-key -root false
aggregate encrypt-with-aggr-key
--------- ---------------------
n1_aggr1  true
n2_aggr1  false


5) Create an SVM on the non-NAE aggregate, and look at the SVM rootvol’s encryption status:


cluster1::> vserver create -vserver svm1 -aggregate n2_aggr1

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted -vserver svm1
vserver volume    encryption-type encrypt is-encrypted
------- --------- --------------- ------- ------------
svm1    svm1_root none            false   false


6) Q: Can we encrypt the SVM rootvol? Answer = NO

‌‌
cluster1::> volume encryption conversion start -vserver svm1 -volume svm1_root

Error: command failed: Failed to start conversion on volume "svm1_root" in Vserver "svm1". Reason: Operation is not supported on a Vserver root volume.


7) Q: Can we encrypt the non-NAE aggregate with an unencrypted SVM rootvol in it? Answer = NO

cluster1::> aggregate modify -aggregate n2_aggr1 -encrypt-with-aggr-key true

Error: command failed: Failed to modify the aggregate "n2_aggr1" since it contains non-encrypted volumes. Run the "volume show -encrypt false" command to get the list of non-encrypted volumes. Convert all of them to NVE (NetApp Volume Encryption) volumes and try again later.


8) Q: Can we vol move the unencrypted SVM rootvol to the NAE aggregate? Answer = YES

cluster1::> vol move start -vserver svm1 -volume svm1_root -destination-aggregate n1_aggr1

Error: command failed: The destination aggregate "n1_aggr1" is an NAE (NetApp Aggregate Encryption) aggregate. Non-encrypted volumes are not supported in such aggregates.

cluster1::> vol move start -vserver svm1 -volume svm1_root -destination-aggregate n1_aggr1 -encrypt-with-aggr-key true
[Job 130] Job is queued: Move "svm1_root" in Vserver "svm1" to aggregate "n1_aggr1". Use the "volume move show -vserver svm1 -volume svm1_root" command to view the status of this operation.

cluster1::> volume move show -vserver svm1 -volume svm1_root

                           Vserver Name: svm1
                            Volume Name: svm1_root
                 Actual Completion Time: Wed Jan 29 21:21:57 2020
                  Destination Aggregate: n1_aggr1
                        Detailed Status: Successful
                          Managing Node: cluster1-02
                    Percentage Complete: 100%
                             Move Phase: completed
                       Source Aggregate: n2_aggr1
                             Move State: done
             Is Source Volume Encrypted: false
     Encryption Key ID of Source Volume:
        Is Destination Volume Encrypted: true
Encryption Key ID of Destination Volume: 00000000000000000200000000000500eb33c6a732638615349e38f7259e9c200000000000000000

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted -vserver svm1
vserver volume    encryption-type encrypt is-encrypted
------- --------- --------------- ------- ------------
svm1    svm1_root aggregate       true    true


9) Create an NVE volume on the non-encrypted aggregate.


cluster1::> vol create -vserver svm1 -volume vol11 -aggregate n2_aggr1 -size 1G -security-style unix -encrypt true

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted -vserver svm1 -volume vol11
vserver volume encryption-type encrypt is-encrypted
------- ------ --------------- ------- ------------
svm1    vol11  volume          true    true


10) Convert the non-encrypted aggregate to NAE aggregate and check the encryption status of our NVE volume.


cluster1::> aggregate modify -aggregate n2_aggr1 -encrypt-with-aggr-key true

cluster1::> aggr show -fields encrypt-with-aggr-key -root false
aggregate encrypt-with-aggr-key
--------- ---------------------
n1_aggr1  true
n2_aggr1  true

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted -vserver svm1 -volume vol11
vserver volume encryption-type encrypt is-encrypted
------- ------ --------------- ------- ------------
svm1    vol11  volume          true    true


11) Q: Can we convert the NVE volume on the NAE aggregate to aggregate encryption-type? Answer = NO (but you can vol move it to an NAE aggregate to give it the aggregate encryption-type)

The only way to convert the NVE volume to aggregate encryption-type is to vol move the volume to another NAE aggregate (you could then move it back again if you so wish.)

cluster1::> vol move start -vserver svm1 -volume vol11 -destination-aggregate n1_aggr1 -encrypt-with-aggr-key true

cluster1::> vol show -fields encryption-type,encrypt,is-encrypted,aggregate -vserver svm1 -volume vol11
vserver volume aggregate encryption-type encrypt is-encrypted
------- ------ --------- --------------- ------- ------------
svm1    vol11  n1_aggr1  aggregate       true    true


Image: NVE v NAE

Also see my post from 24 July 2019:
NetApp Aggregate Encryption (NAE) in ONTAP 9.6: How to Configure