One of the most common misconceptions about tiering that I hear is that it is “Difficult”. Other frequent comments include statements such as “Tiering requires IT managers to configure the tiers for a specific workload”, and “For flexibility and growth, caching is the answer”. These misconceptions are based on most people’s knowledge of tiering, which I will call “Macro” Tiering and is most prevalent in enterprise storage arrays.
The reality is that today’s solutions make tiering very simple, and in most cases are the better option for applications that would normally consider caching. With ever increasing growth in server storage, as well as scale out storage, we have seen tiering migrate from high-end external storage into server-based storage. This movement into servers necessitates changes in tiering algorithms and how they behave, as moving large files based on yesterdays activity or even last weeks activity is both inefficient and does not respond to the dynamic environment of most workloads.Misconception #1: Tiering is complex
This is easy to understand as historically tiering solutions have been complex. Tiering solutions today such as Enmotus’ FuzeDrive will allow you to configure your tiers in 5 minutes or less via easy to use wizard driven graphical interfaces. While the user has the ability to configure key settings such as promote rates and read/write policies, once configured, there is no need to make ongoing adjustments, as the tiering engine will continually load balance your volume and adapt it to dynamic data requests. While I applaud Microsoft for furthering the adoption of tiering in server based storage environments, unfortunately I feel that it is not doing much in terms of eliminating the stigma that tiering is complex. I heard one person describe the configuration of Microsoft’s tiering as “travelling over 12 miles of bumpy road in order to get to your final destination”. Like many legacy tiering applications, Microsoft tiering defaults to promoting your data once a day, the underlying assumption being that the data that was hot today will be hot tomorrow.
Misconception #2: Tiers needs to be configured to your workload
A good tiering solution will adapt automatically to a dynamic workload. They key is the solution must be both real-time and operate at the block level. Much like a cache, real time tiering reacts quickly and promotes data to the fast tier. Unlike cache, the data will remain there as long as it remains active, as there in no need to periodically flush the data out of cache. Block level operation means only the active portions of files are promoted to the fast tier, which means you can be efficient about how much fast tier your require. Database expert Brent Ozar offers a video explaining why even for database applications, you should just let tiering do its job.
Misconception #3: Tiering is inflexible
This one confuses me as tiering appears much more flexible than a cache. Tiering provides the opportunity to size your tier according to your storage, application and financial needs. If you are on a budget, go with the adage that about 5-10% of your data is active, and size your tier accordingly, and grow the size of your tier later if desired. If you have a larger budget, you can size your tier by how much you can afford knowing that as your tier gets larger your overall volume size increases as the fast tier is additive to your volume. Furthermore, a larger tier has no impact on CPU utilization, which means you have more CPU cycles for your applications instead of managing ever larger cache tables. Finally, solutions such as streaming data in media and entertainment applications as well as content delivery are much better served than a cache.
In Summary – a modern automated tiering solution is simple to configure and operates in real time, which allows it to adapt to your workload on the fly, and is flexible in terms of growth and size. With flash prices coming down dramatically, tiering stands to make an even larger impact as this will allow users to make even larger flash tiers, thereby ensuring that their active data is being serviced out of flash.