Sunday, 13 December 2009
Views on Automated storage tiering
Array design
I believe storage arrays and storage disk layout will be designed and planned a hell of a lot differently than they are planned today. Typically functional requirements will become less and less taken into account when planning storage for an application or planning array deployments from scratch. With introduction of automatic array tiering into mainstream I see design considerations being based more on the overall disk capacity requirements and potential capable over subscription limits that can be achieved, and also ensuring that relevant SLA's based on workload characteristic are guaranteed i.e. Between the Hours of 10-12 this batch process will get X amount of IOPs
This I relate to in the same context as planning deployment of workloads into a VMware farm that uses shared HW resource capability. The "farm" or "pool" of storage will become the associated norm with the shift of responsibility of the storage admin being more on calculating and understanding the running capacity and available expansion space on the array with the AST algorithm calculating and reporting back the available location where workloads can be moved to back to the storage bod. (it is safe to say though that AST is going to certainly be in manual mode for even the bravest of storage admins for a while).
No thy workload
In most storage environments today we plan and over allocate for the worst case IOPs or MBPs requirement of the workload and in the event of any potential issues arising they get dealt with in a reactive manor. If it does what it says on the Marketed Tin AST will make this type of planning irrelevant, we won't need to know the workload, it will move it for us.
If limited performance metric on app profile is available in the first place (which I expect), then AST enabled arrays will provide the option to monitor post deployment and then have the peace of mind that you can migrate with no downtime to the running workload. Meaning advanced tiering provides the Administrator with greater opportunity to turn reactive issues into a proactive scenario by having greater visibility of what the application does (and whether the vendor is lying about requirements).
Additionally I expect (and hope) vendors with AST functionality will provide tools which provide expected "Before and After" results of what will occur by moving storage that doesn't sit on on AST enabled array into an AST enabled environment. I also expect to see an onslaught of third party software companies providing such a facility (if they don't do this already).
Adoption rate
In my opinion the latest incarnation from EMC of FAST will most certainly not be deployed and adopted in aggressive fashion within Storage infrastructures for a while, the feature is not back supported into Enginuity for DMX3/4 so only the rare customer who has bought a VMAX or CX-4 recently will be one of the few capable of implementing this technology. Additionally FAST isn't free, expect to see people keep there hands in there pockets until this technology has been proven
Higher storage tier standbys
SSD's are an expensive purchase, and AST enables the possibility of being able to introduce sharing capability of SSD between workloads (if planned appropriately), you maybe in the position to oversubscribe the use of SSD between applications. If an app that runs in the day needs grunt in the shape of IOPs, it can share the same disk pool with an app that requires throughput out of hours.
Virtualisation and AST
Expect to see AST benefiting and working heavily at API level with VMware, i've already written back in July about a vision for this in the following post, the basis of this was that Virtual admins will not have as much concern with placing Virtual Machines upon the best suited storage. Today various LUN's and RAID VMFS volumes need to be deployed so VM's can be hosted to match application workload. We may see the need to have a generic based VMFS Volume and AST Technology move volumes based on workload requirements of VM's on that disk (in time)
Summary
Hopefully I have made some valid points on where I think AST will fit into environments and where it will change general design best practices, I do not use a AST enabled array and will not have the capability to for some time so excuse me if some of the above is already possible or being done.
Subscribe to Posts [Atom]
Post a Comment