While the actual payload hasn’t hit the street yet, here’s what I can tell you about the latest release in the ONTAP 9 family which should be available here any day now. **EDIT:
RC1 is here. 9.4 went GA today.
Lots of improvements to ONTAP’s object-tiering code in this release, it appears they’re really pushing development here:
- Support for Azure Blob, both hot and cool tiers, no archive tier support
- This adds to the already supported AWS-S3 and StorageGRID Webscale object stores
- Support for cold-data tiering policies, whereas in 9.2,9.3 it was backup and snapshot-only tiering policies
- Default definition of cold data is 31 days but can be adjust to anywhere from 2-63 days.
- Not all cold blocks need to be made hot again, such as snapshot-only blocks. Random reads will be considered application access, declared hot and written back into performance tier whereas sequential reads are assumed to be indexers, virus scanners or other and should be kept cold and therefore will not be written back into performance tier.
- Now supported in ONTAP Select, in addition to the existing ONTAP and ONTAP Cloud. Wherever you run ONTAP, you can now run FabricPools, SSD aggregate caveat still exists.
- Inactive Data Reporting by OnCommand System Manager to determine how much data would be tiered if FabricPools were implemented.
- This one will be key to clients thinking about adopting FabricPools
- Object Store Profiler is a new tool in ONTAP that will test the performance of the object store you’re thinking of attaching so you don’t have to dive in without knowing what your expected performance should be.
- Object Defragmentation now optimizes your capacity tier by reclaiming space that is no longer referenced by the performance tier
- Compaction comes to FabricPools ensuring that your write stripes are full as well as applying Compression, Deduplication