There’s been a lot of talk lately about automated storage tiering (not least from myself) and there’s one piece of the puzzle I’m not completely sure has been explored in depth. Many of the posts refer to physically moving data between tiers of internal (or external) storage. In legacy environments where LUNs are comprised of disk slices – either whole slices or LUNs taken from RAID groups - then architecturally, moving all data for a specific LUN is a requirement. Clearly block-level migration is auto-tiering nirvana, where only those specific hot blocks are moved onto faster disk. But does this have to be achieved by physically moving that data? The answer is no.
Making Use of Cache
All shared storage arrays use cache memory of some sort in order to smooth out the unpredictability of I/O response time from physical media like hard drives. Read and write response times vary depending on the position of the drive read/write heads and the added overhead of latency. In addition, the use of RAID to stripe data across physical spindles requires cache in order to prepare a RAID stripe for writing to disk, with methodologies like RAID-5/6 requiring in-memory calculations of parity before committing data to its physical resting place.
Writes of data are always cached and it’s possible reads are too, if the piece of data still resides in cache from a previous operation or has been pre-fetched. So it is possible to simplify I/O operations as such:
- Write I/O – write to cache; confirm response to host; destage to physical disk asynchronously; leave I/O block in cache.
- Read I/O – read from cache if available; if not, read from disk; leave I/O block in cache
Cache for Tiers
Cache can be used to move data between tiers without actually moving data. Imagine all blocks (or chunks) of a LUN are tagged with a performance profile that determines which tier of disk the chunk should reside on. During normal operations, the chunk will be read, re-written and destaged to disk as normal. At some point, the chunk is marked to move to another service tier, say SSD rather than FC storage. At this point, the next time the chunk is written to cache, it gets destaged to a new location on SSD. Once completed, the old chunk is logically released from the FC drive. Voila! The data is moved without an additional I/O operation, but by simply utilising the normal I/O operation.
Of course, I’m simplifying the whole process here. In reality things are much more complicated. Vendors have developed sophisticated algorithms to pre-stage and de-stage data to and from cache to minimise mechanical drive impact and to maximise performance. RAID calculations have to be managed. In addition, this concept works well for active data but inactive data moving down tiers would still require additional I/O. Also, spare resources would need to be set aside to make sure chunks were readily available when data profiles changed. Otherwise there would be a risk of resource starvation as demand for one tier of storage outstripped supply.
Whilst this is a simple illustration, it does show that storage platforms in which the underlying architecture is designed to handle I/O and LUN layout at the block level, will have a massive advantage over legacy platforms using (previously good) methologies for storing data. I suspect vendors such as Hitachi/HP and EMC are having to spend a lot more time re-writing the fundamental operating principles of their enterprise storage products than they care to admit. Why else would FAST for blocks be announced a full 12 months before a committed availability date?
Pingback: Twitter Trackbacks for Enteprise Computing: Automated Tiering – Why Move The Data? « The Storage Architect [thestoragearchitect.com] on Topsy.com
Pingback: uberVU - social comments