You may have assumed from my previous post on VPLEX that I am negative towards the concept of storage federation. That couldn’t be further from the truth. In fact, ever since I was involved in deploying ESX onto enterprise storage infrastructure (some 4 years ago), I’ve been waiting for the day true federation would arrive. Here’s why.
Static Configurations
Think back to the time before server virtualisation (yes, there was one). Physically static servers failed over to other physically static servers located in remote data centres. Once deployed, servers very rarely moved unless there were major physical data centre issues or an upgrade was being performed. In fact, even when server upgrades occurred, it was typical to acquire a new server and rebuild the application and data on that new hardware to remove any issues with new server drivers, hardware firmware and so on.
Mobility Rules
Server Virtualisation changed all those restrictions. By abstracting the hardware to generic devices it was possible to place a VMware host on shared storage and have any connected VMware server run that guest. Very quickly the toolset of features improved to make that host movement transparent and as simple as clicking a button. This meant servers could be accommodated on any hardware and scaled within the hypervisor.
Storage Restrictions
Unfortunately storage wasn’t so quick to keep up. The static model of a single physical server in two locations worked well with storage replication technologies that required only one copy of the data to be active at any one time. Moving an application to another data centre was typically a disaster recovery process and consequently a small outage was acceptable as the storage arrays “failed over” their LUNs to the remote location. Once the DR issue was solved, the data could be “failed back’ to the original location. It wasn’t usual to move servers between data centres as a standard operational process.
Virtual Machine environments weren’t well catered for. Failover of replicated storage wasn’t a transparent process; there was a tradeoff between LUN size and the maximum number of LUNs a hypervisor could support; this made it more complex to architect a Virtual Machine environment with enterprise storage. Even with vMotion on VMware, where a VM host could be moved transparently across physical hypervisor servers, the storage couldn’t be moved easily. In fact, the storage restrictions were solved by implementing storage vMotion, rather than have the array achieve the data migration itself.
Step in Federation
This is where storage federation comes in. It enables any and all copies of a LUN to be updated from multiple locations at the same time. This means that both the hypervisor and the storage can be load balanced across multiple locations and physical hardware without having to bulk copy the data all the time. Here’s a simple example to demonstrate the process.
Imagine a 1TB LUN on a storage array acting as a single datastore and supporting 20 production virtual machines. In the “old” model, moving that LUN to another location would require impacting all 20 virtual machines and making another location the primary target of I/O operations. There was no ability to go “sub-LUN” and to move individual machines to another location. Storage vMotion could be used, but that would require replicating the entire VM to another LUN/datastore. Any attempt to load balance the VM guests would be constrained by the time required to continually move data around the infrastructure. In addition, moving a replicated VM from one LUN/datastore to another would mean compromsing DR until that LUN had been fully replicated to another location.
Now under a federated environment, that 1TB LUN would be updatable from any location, meaning individual VM hosts on the datastore could be updated from multiple locations at the same time. This means there is a massive increase in the flexibility of managing workloads across physical locations, offering the ability to workload balance for business and operational benefits.
Summary
Ultimately, federated storage environments will be the future. Products like VPLEX are only the start. The ultimate goal will mean workloads can be run anywhere, any time. That will be cool.
