One of the subjects that was raised again at last week’s A3 IT Question Time in London was that of storage tiering. To recap, the concept is pretty straightforward; you install storage within an array or architecture that has multiple levels of performance and data is placed on the appropriate tier based on its performance requirements. In more complex environments, data can be dynamically moved between tiers as required. However I believe the tiering model as it exists today has come to the end of its useful life. The reasons for this include:
- Rigidity – Tiering is a fixed model. You install categories of storage in the array and your server gets whatever performance level that tier can provide. However each of those tiers are fixed steps (for example the difference between 15K & 10K drives) which means inevitably, some hosts are receiving more IOPS capability than they demand, and that’s wasted resource. Dynamic tiering helps with this but of course is typically implemented over a measurement period in days rather than seconds or milliseconds. If a workload profile changes, adding “adding more IOPS” means physically installing and de-installing disks. This issue can be mitigated somewhat by adding in disk to match the workload profile as part of a growth plan, but that still means effort in planning and internal data migration.
- Waste – To achieve dynamic tiering means having spare capacity available to promote or demote data. This immediately means disk space is being under-utilised just in case a requirement to move data arises. Creating many levels of tiering also creates waste because it is difficult to guess in advance what amounts of each tier will be required at array deployment time.
- Complexity – Tiering models are just too complex to manually interact with. As environments scale and change dynamically, the tiering model needs to be reviewed frequently, even when dynamic/automated tiering is implemented. Having many tiers across multiple architecture from multiple vendors means a lot of work in getting a consistent architecture.
Storage Performance Hierarchy
- DRAM – very, very fast, but volatile and expensive. Not a great scale out solution.
- Persistent DRAM – emerging technologies like that from Diablo, where NAND is build in the DIMM form-factor, accessible on the motherboard, with good scale and persistence.
- Flash – in many guises – PCIe SSD, custom NAND cards, SLC SSD, MLC SSD. Persistent storage with large capacity and scale. Still a little expensive though.
All of the above provide low latency with predictable response times. Then there are the hard drives. These scale from 15K RPM, through 10K, 7.2K and 5.9K and increase in capacity as speeds reduce. Perhaps with new recording techniques we’ll see even slower drives, with much larger capacities.
As we can see, we’re not just stuck with spinning disks. There is the opportunity to build arrays from a range of devices offering a balance of performance versus capacity.
Putting it all Together
What we want in the future is an infinitely scaleable array that delivers I/O to a service level, rather than a fixed physical storage tier. This means assigning latency and IOPS to each LUN. Even at the simplest level, we have the ability to use our DRAM and Flash layers to stage reads and writes so they are delivered to the host with the guaranteed service level assigned to the data. For example, imagine providing a guaranteed 5ms response on I/O write to a host. In the traditional model, once the data is in non-volatile cache, the I/O would be acknowledged and de-staged to disk/flash. But why do the acknowledgement immediately? Why not hold it until the 5ms requirement and do it then? There are some issues to be resolved around data integrity in this model, but those exist already today and are catered for by the array.
Delivering to a service level already exists; SolidFire, a vendor I’ve mentioned many times, already does this. However at the moment, their solution is based purely on Flash, because, unsurprisingly, Flash gives the most predictable performance while delivering high numbers of IOPS. The evolution from SolidFire is to build a system that knows how many IOPS can be delivered from any underlying hardware (adding up disk, flash, DRAM) and match that to the IOPS requirement per LUN. This would truly be Software Defined Storage (SDS).
The Architect’s View
Our array vendors may already be working on the next generation of storage that really does deliver to SDS and quality of service. I’m hoping that there’s promise in solutions like ScaleIO to deliver to the infinite tiers model. When we get to that point, our work in the physical storing of data will be pretty much done, and we can all move onto the next stage of getting more value out of all of this stuff we’re keeping.
Comments are always welcome; please indicate if you work for a vendor as it’s only fair. If you have any related links of interest, please feel free to add them as a comment for consideration.
Subscribe to the newsletter! – simply follow this link and enter your basic details (email addresses not shared with any other site).
Copyright (c) 2013 – Brookend Ltd, first published on http://architecting.it, do not reproduce without permission.