Although I mentioned this functionality in a previous blog post, the impact that this type of use case will have on connectivity automation is so significant that it deserves to have it's own post.
The first time I heard the FAST Sideways concept mentioned publicly was by Brian Gallagher during an EMC World 2013 keynote. Brian and Steve Todd then talked about the topic in just a bit more detail during an EMCBackstage interview. Although I believe there will be a team of folks at EMC World this year taking about this concept in general, I’ll say the following about it from a Connectivity Automation perspective.
Fully Automated Storage Tiering (FAST) allows blocks of storage to be moved between different tiers of storage (e.g., Flash, FC, SAS) on the same Array. These placement decisions are driven by the FAST Engine that runs on the Array’s Service Processor (in the case of VMAX) which makes use of user defined policies. Because the placement decisions do not impact SCSI connectivity (e.g., LUN, LU ID), these changes are effectively invisible to the host and do not require connectivity layer changes.
FAST Sideways can be thought of as an extension to FAST but instead of operating within a single array, volumes could be moved from one array to another. These placement decisions will probably need to be driven by a FAST Federation engine that logically operates at a layer above the FAST engines running on each array. This FAST Federation engine will also probably make use of user defined policies to assist in placement decisions but unlike the FAST engine, it will also need to interact with connectivity elements (e.g., FC switches or Virtual Networks) in order to configure both array to array and host to array connectivity as shown in the following diagram set.
The diagram above contains two physical hosts, a host facing fabric, two storage arrays and a storage fabric at three different phases (i.e., Beginning, Intermediate, and Completed) of a FAST Sideways operation. The host facing and storage fabrics could either utilize completely different approaches to connectivity (e.g., the host facing fabric could be Fibre Channel (FC) based while the Storage fabric could be a VXLAN based Over The Top (OTT) Virtual Network). Although not shown in the diagram, both could utilize the same physical fabric.
FAST Sideways workflow – In this case, the user or the FAST Federation engine decides to move Host 2 to Array 2 because Array 1 is very busy and Array 2 is nearly idle. When this happens, three high level actions would need to occur:
- Establish connectivity between Array 1 and Array 2;
- Allow Host 2 to access its volumes on Array 2; and
- Remove connectivity between Array 1 and Array 2 once the data has been copied.
Each of the phases is described in more detail below.
Beginning – The Beginning portion of the diagram illustrates Host 1 (Blue) and Host 2 (Red) accessing different volumes (e.g., “Blue” and “Red” respectively) on the same storage array.
Intermediate – This diagram illustrates that connectivity has been established between Array 1 and Array 2. Once this connectivity has been established, volume replication may begin from Array 1 to Array 2 via any means available (e.g., ORS, SRDF, etc). Also at this point connectivity between Host 2 and Array 2 could be established. Once this connectivity has been established, Host 2 will need to discover Array 2 via a protocol specific mechanism that is described in a later section. Once Array 2 has been discovered, the volumes may be made available to the operating system via any means available (e.g., ALUA). At this point Host 2 could begin to access its storage on Array 2 (i.e., if ORS is in use).
Completed – This diagram illustrates Host 2 accessing its Storage on Array 2 and the connection between Array 1 and Array 2 has been removed.
All of that in mind, you can think of FAST sideways as one possible way to remediate chronic issues with an inability to meet IOPS and RT objectives.
Update: Helen Raizen (EMC) wrote a great blog post that describes the challenges related to Block Storage Migration. The functionality she describes could make use of the Connectivity Automation functionality I describe above.
Thanks for reading!
Comments