FabricPool is by now a well-established method to decrease the costs of your primary storage by moving cold “chunks of data” to an object store. I specifically use the word “chunks” because the word “blocks” is overloaded with strong connotations of SAN and iSCSI protocols. Similarly, I avoid the word “files” because the FabricPool technology is not file based either. FabricPool maintains a heatmap of the ONTAP WAFL blocks and evaluates the heatmap against a policy. Let’s then correctly state the definition of the phrase “chunks of data”. A chunk of data is an ONTAP WAFL block, and this WAFL block is decoupled from the file system / LUN syntax. In other words, it works the same for both NAS and block file systems. FabricPool evaluates WAFL blocks after the Storage Efficiency engine has had a chance to dedupe / compress data, which means that less space is consumed on the secondary tier. Additionally, FabricPool is very opportunistic when it comes to retrieving cold data. Let’s assume that a WAFL block was copied to the secondary tier, but the original WAFL block has not yet been overwritten by ONTAP. A READ request will serve the data from the primary tier – something that is only possible due to the deep integration between WAFL and the secondary storage tier.
What makes FabricPool and StorageGRID so attractive from a business perspective is the fact that there is no FabricPool license requirement! You can tier as little or as much data as you want from ONTAP to StorageGRID for free. Sometimes StorageGRID is dedicated to being the FabricPool target, other times StorageGRID is the primary storage for S3 workloads and does double duty as a FabricPool target. Traffic classification policies can throttle less critical workloads to prioritize tier one applications and FabricPool traffic. In this architecture, multiple ONTAP clusters, across multiple locations, could tier off cold data to a single, large, cloud like infrastructure. The benefits are significant. Depending on how you classify cold data, up to 80% of data blocks could be candidates for tiering. ONTAP automatically keeps track of the amount of cold data in a file system using a default period of thirty-one days. This information (the amount of cold data) is displayed in System Manager under the local tiers overview, even if FabricPool is not configured and no tiering is taking place.
Managing a large enterprise, with multiple sites and various technologies, including internal and public clouds, requires some new tools. Recently I got the opportunity to play with Cloud Manager. If you are excited about a fresh GUI experience, I recommend giving Cloud Manager a try. One important consideration and something that has not changed with the introduction of Cloud Manager is that on-premise tiering (ONTAP FabricPool to StorageGRID specifically) is still free. As a matter of fact, Cloud Manager can discover and manage existing tiering relationships between ONTAP and StorageGRID. What this means for you is that a beautiful new interface exists that bridges the on-premise infrastructure with any cloud based footprint you may have.
Here is a summary of my lab environment from Cloud Manager after having removed the cluster name. I tiered off over 14 TB of data.
Cloud Manager uses a Digital Wallet to maintain any required licenses. My wallet is empty as all the tiering is on-premise between ONTAP and StorageGRID.
Cloud Manager can do a lot more than tiering on-premise. It can span public and private clouds and orchestrate multiple types of business relationships, including backups/restores and replication. In a future post, I will explore more ways to use Cloud Manager to backup / replicate data to StorageGRID.
When you use StorageGRID as the FabricPool target, you automatically maximize the efficiency of your primary storage with no additional licenses needed. The state of this union is still strong.
