Category Archives: ONTAP

ONTAP 9.2RC1 is out

Continuing with their new standard six month release cadence, ONTAP 9.2RC1 was released today and I continue to be impressed with the feature payload NetApp has been delivering with each new release; here are the highlights:

  • FabricPools
    • Automated cloud-tiering of NetApp Snapshots to a target that speaks S3 (AWS or StorageGrid)
  • QoS Floors or minimums
    • Allows you to reserve performance for critical workloads, SAN on AFF only.
  • Efficiencies:
    • Inline dedupe at the aggregate level
      • Previously volume-only
      • Not applicable to post-process dedupe
      • AFF only
    • Advanced Disk Partitioning now available on FAS8xxx and FAS9xxx, for the first 48 drives.
  • NetApp Volume Encryption
    • Now available for FlexGroups

Here’s the list of supported platforms for ONTAP 9.2:

AFF A700s FAS9000
AFF A700 FAS8200
AFF A300 FAS2650
AFF A200 FAS2620
AFF80x0 FAS80x0

ONTAP Select, the software-only version of ONTAP gets a few nice improvements as well:

  • FlexGroups
  • 2-Node HA
  • ESX Robo licensing (This is a big deal for me and my customers)

Read the full release notes here.

NetApp Volume Encryption, The Nitty Gritty

It all begins in the configuration builder tool

This article focuses on the implementation and management of encryption with NetApp storage. Data at Rest Encryption (NetApp Volume Encryption or NVE for short) is one of the ways that you can achieve encryption with NetApp, and it’s one of the most exciting new features of ONTAP 9.1. Here’s how you go about implementing it.

If you’re a partner or NetApp SE, when building configurations, as long as the cluster software version is set to 9.x, there is a checkbox that lets you decide which version of ONTAP gets written to the device at the factory. As of 9.1, ONTAP software images will either be capable of encryption via a software encryption module, or not. There are laws around both the import and export of software that is capable of encryption, but that is beyond the scope of this article. I do know you can use the encryption-capable image in Canada (where I am located), so I’m covered. If you’re unsure about the laws in your country, consult your legal adviser on this matter.

Once this cluster-level toggle has been set and you add hardware into the configuration, there are two more checkboxes in the software section:

  1. NetApp Volume Encryption (off by default)
  2. Trusted Platform Module (TPM, on by default) ***Clarification Update*** – TPM NOT REQUIRED FOR NVE

The first one triggers the generation of the license key for NVE and the second one activates a piece of hardware dedicated to deal with cryptographic keys. One thing I’m still not sure of is (should you choose to remove the checkmark)  if the TPM is simply disabled or doesn’t physically exist in your NetApp controller, I have an email into NetApp to confirm this. [Update: The module is integral to the controller and disabled in firmware if being shipped to certain countries. Shout out to @Keith_Aasen for tracking that down for me.]

Okay, now for the more customer-relevant information…

To get started with NVE, you’re going to need a few things:

  1. A encryption-capable platform
  2. A encryption-capable image of ONTAP
  3. A key manager
  4. A license key for NVE

Encryption-capable platform

The following platforms are currently capable of encryption: FAS6290, FAS80xx, FAS8200, and AFF A300. This is limited by the CPU in the platform as it must have a sufficient clock-speed and core-count with support for the AES instruction set. I’m sure this list will be ever-expanding, but be sure to check first if you’re hoping to use NVE. [UPDATE: After some digging, I can confirm that all the new models support NVE, the entry-level FAS2650 included.]

Encryption-capable image of ONTAP

Provided you’re not in a restricted country as per the above, your image will be the standard nomenclature of X_q_image.tgz where X is the version number. The non-encryption-capable version will be X_q_nodar_image.tgz which I’ll simply refer to as nodar(e) (No Data At Rest Encryption) for the rest of this article. The output of version -v will tell you if you’re nodar or standard.

NetApp Release 9.1RC1: Sun Sep 25 20:10:49 UTC 2016 <1O>

NetApp Release 9.1RC1: Sun Sep 25 20:10:49 UTC 2016 <1Ono-DARE>

Key manager

The on-board key manager introduced in ONTAP 9.0 enables you to manage keys for use with your NSE drives, helping you avoid costly and possibly complex external solutions. Currently, NVE only supports using the on-board manager, so if you’re going to use NVE layered on top of NSE, you need to use the on-board one.

Setting this up is exactly one command:

security key-manager setup

You’ll be prompted for a passphrase, and that’s it, you’re done.

License key for NVE

If you didn’t get this license key at time of purchase, talk to your account representative or SE over at NetApp (though, hopefully, if you’ve bought one of the new systems announced at Insight 2016, they decided to include it since, at least for now, it is a no-cost license).

What next?

Now that you’ve got all the prerequisites covered, encrypting your data is very simple. As the name implies, encryption is done at the volume level, so naturally it’s a volume command that encrypts the data (a volume move command, in fact):

volume move start -volume vol_name -destination-aggregate aggr_name -encrypt-destination true

The destination aggregate can even be the same aggregate that the volume is already hosted on. Don’t want that volume encrypted anymore for some reason? Change that last flag to false.

If you’re creating a new volume that you want encrypted, that’s just as simple:

volume create -volume vol_name -aggregate aggr_name -size 1g -encrypt true

Wrapping up

NetApp Volume Encryption is pretty easy, but since it’s so new, OnCommand System Manager doesn’t support it just yet. You’ll have to stick to the CLI for now, although I’m sure the GUI will catch up eventually, if that’s your preferred point of administration. It should also be noted that while NSE solutions are FIPS 140-2 compliant, NVE has yet to go through the qualifications. Also, if FIPS is a requirement, the on-board key manager isn’t compliant yet either. Since with the on-board key manager the keys are literally stored on the same hardware using them, NVE only protects you from compromised data on individual drives removed from your environment through theft or RMA. If someone gained wholesale access to the HA pairs, the data would still be retrievable. Also, this is for data-at-rest only. You must follow other precautions for data-in-flight encryption.

Into the weeds

I did all my tests for this post using the simulator, and I learned a lot, but your mileage may vary. In the end, only you are responsible for what you do to your data. I had heard that if you have the wrong software image then you’d have to do a complete wipe of your HA pair in order to convert it. I have since proven this wrong (at least in the simulator) and I definitely can’t guarantee the following will be supported.

For my tests I had two boot images loaded: one standard and one nodar. What I learned is that you can boot into either mode, provided you don’t have any encrypted data. Even if you have the key manager setup and NVE is licensed, you can still boot back and forth. The first time you boot your system using the nodar image with encrypted data on the system, however, you’ll hose the whole thing. I did test first encrypting data, then decrypting it, then converting to nodar, and the simulator booted fine. When I booted into nodar with an encrypted volume, even going back to standard didn’t work. Booting into maintenance mode shows the aggregates with a status of partial and the boot process hints that they are in some sort of transition phase (7MTT?). Either way, I was unable to recover my simulator once I got it to this state, so I definitely advise against it in production. Heck, I’d advise you just to use the proper image to start with.

I hope you learned something. If you have any questions or comments, either post them below or reach out on twitter. I’m @ChrisMaki from the #NetAppATeam and Solution Architect @ScalarDecisions.

ADP(v1) and ADPv2 in a nutshell, it’s delicious!

Ever since clustered Data ONTAP went mainstream over 7-Mode, the dedicated root aggregate tax has been a bone of contention for many, especially for those entry-level systems with internal drives. Can you imagine buying a brand new FAS2220 or FAS2520 and being told that not only are you going to lose two drives as spares, but also another six to your root aggregates? This effectively left you with four drives for your data aggregate, two of which would be devoted to parity. I don’t think so. Now, this is a bit of an extreme example that was seldom deployed. Hopefully you had a deployment engineer who cared about the end result and would use RAID-4 for the root aggregates and maybe not even assign a spare to one controller, giving you seven whole disks for your active-passive deployment. Still, this was kind of a shaft. In a 24-disk system deployed active-active, you’d likely get something like this:

Traditional cDOT

Enter ADP.

In the first version of ADP introduced in version 8.3, clustered Data ONTAP gained the ability to partition drives on systems with internal drives as well as the first two shelves of drives on All Flash FAS systems. What this meant was the dedicated root aggregate tax got a little less painful. In this first version of ADP, clustered Data ONTAP carved each disk into two partitions: a small one for the root aggregates and a larger one for the data aggregate(s). This was referred to as root-data or R-D partitioning. The smaller partition’s size depended on how many drives existed. You could technically buy a system with fewer than 12 drives, but the ADP R-D minimum was eight drives. By default, both partitions on a disk were owned by the same controller, splitting overall disk ownership in half.

8.3 ADP, R-D


You could change this with some advanced command-line trickery to still build active-passive systems and gain two more drive partitions’ worth of data. Since you were likely only building one large aggregate on your system, you could also accomplish this in System Setup if you told it to create one large pool. This satisfied the masses for a while, but then those crafty engineers over at NetApp came up with something better.

Enter ADPv2.

Starting with ONTAP 9, not only did ONTAP get a name change (7-Mode hasn’t been an option since version 8.2.3), but it also gained ADPv2 which carves the aforementioned data partition in half, or R-D2 (Root-Data,Data) sharing for SSDs. Take note of the aforementioned SSDs there, as spinning disks aren’t eligible for this secondary partitioning. In this new version, you get one drive back that you would have allocated to be a spare, and you also get two of the parity drives back, lessening the pain of the RAID tax. With a minimum requirement of eight drives and a maximum of 48, here are the three main scenarios for this type of partitioning.

12 Drives:

ADPv2, R-D2 ½ shelf

24 Drives:

ADPv2, R-D2 1 shelf

48 Drives:

ADPv2, R-D2 2 shelves

As you can see, this is a far more efficient way of allocating your storage that yields up to ~17% more usable space on your precious SSDs.

So that’s ADP and ADPv2 in a nutshell—a change for the better. Interestingly enough, the ability to partition disks has lead to a radical change in the FlashPool world called “Storage Pools,” but that’s a topic for another day.

ONTAP 9.0 is here.

That’s right folks, not the 8.4 you were thinking was next, but straight to 9. With the jump to 9 in the versioning also comes a bit of rebranding. When referring to the OS of your FAS, you can finally simply say ONTAP, no more qualifying that with “7-mode” or “clustered” or even prefixing it with “Data”. Alongside this new version comes two variants, one that runs in the cloud and one that you can run in your VMware environment. ONTAP Cloud and ONTAP Select respectively. Currently ONTAP Cloud is AWS only, but all signs point to an Azure release in the very near future. ONTAP Select picks up where Edge left off.

I’ve had some helm time with the new version and the first thing you’ll notice is that System Manager has been cleaned up and rearranged. When you first login, you’ll now get the following dashboard with a quick view of your cluster:

Screen Shot 2016-05-30 at 4.58.02 PM

This dashboard is good for a quick glance at performance and capacity, but clicking around the other tabs still leaves something to be desired on the usability front, but only because there is just so much available in this interface. I feel like I’ve got the “advanced view” option permantly checked off. Personally I don’t mind all the various tabs and sub-tabs, but for your day-to-day operator, most of the options available aren’t necessary.

Moving over to the technical side of the equation, ONTAP 9 brings with it a few new exciting features. First of all, support for the new 15.3TB SSDs makes its way into the payload, as well as RAID-TEC triple-parity protection. As far as I know, NetApp will be first to market with these 15.3’s and I can’t wait to see them in the field. RAID-TEC, or RAID Triple Erasure Coding will really help out with the larger disk sizes. While it won’t be mandatory for the large SSDs, I highly recommend it for spinning drives >= 6TB. These drives currently have a max RAID group size of 14, but the introduction of RAID-TEC will increase that to 28 drives. This will not only double your RAID protection level and decrease rebuild times,  but most importantly the RAID tax won’t be so bad in the larger deployments. If you’ve already got these large drives deployed, you can move to RAID-TEC and larger RAID groups provided you have the disks to add to the aggregate.

In the realm of performance, NetApp is claiming a 60% increase in IOPS over 8.3.1, as well as the introduction of “Headroom for visibility of performance capacity”. What this means is that at a glance, you should be able to see how much more performance is left in your cluster. NetApp has also introduced a new data-reduction technology called Data Compaction. With this latest addition to the existing data reduction tricks, namely deduplication, compression, cloning and thin-provisioning NetApp is now boasting a 4:1 data reduction number and is backing it with a guarantee.

Finally, two more feature introductions for the compliance-minded folks out there. First you’ll be happy to hear SnapLock® software is back, and for those not looking to introduce the cost and complexity of an external key manager for NSE drives, NetApp has introduced an onboard key manager.


Make sure to check out some of the other posts on this subject by my fellow NetApp A-Team members:

***Note: ONTAP 9 is not out yet, but the details are. The exact release date is not public yet.