Here’s a newsflash: everyone is talking about cloud, but not everyone agrees on what cloud is exactly, including those who are actually implementing clouds today. And that is okay. Cloud is not for everyone right now, much like virtualization in the early days. If you remember, virtualization started mostly in test/dev, and then with small numbers of less mission critical production workloads, and only after proven success did it become more pervasive. That journey to the virtualized datacenter took almost 10 years. Cloud feels much the same.
What is different? The applications. In the journey to the virtualized datacenter, applications did not change much. Sure, it became easier and more cost effective to architect applications correctly by creating separate VMs for different applications, such as SQL Server, in both production and dev/test environments, but the applications themselves did not change much.
Amazon and the public cloud are changing the way applications are developed. They are no longer being developed as large, stateful, monolithic applications that need big stable virtual machines to run. Applications are being designed as a “cloud” of stateless, tiered sets of VMs, with each set handling a different function of the application (web front end, middleware business logic, database, etc.). And they are designed to be self-scaling and self-healing. If you need to serve more users as your service becomes more popular, you don’t have to re-architect the application or hot-add more CPU and memory to a running VM: just fire up a couple more web front end VMs to handle the load.
And cloud architectures give you the agility not only to respond quickly to scaling requirements, but also give you the ability to more effectively meet competitive business requirements.
There are two major trends for VM deployments in the cloud that are significantly different from what you face in your virtualized environment:
Private cloud often begins with adding self-service capabilites. Self service portals naturally lead to the creation of more virtual machines, which means more objects for the storage infrastructure to manage.
One of the advantages of private cloud is that you do not need to rearchitect all of your applications right away for the cloud like you do in the public cloud, making private cloud an easier move for enterprises to increase agility and business responsiveness. Private cloud also makes it easier to run applications that consist of both "traditional" VM running databases and "cloud" VMs running application logic and load balanced web servers.
But over time, applications are being rearchitected to the cloud model, starting the web, mobile and other "presentation" tiers, which generates more virtual machines for the same application. VMs in private and public clouds tend to be individually smaller, but greater in number since the applications are being modularized to scale automatically.This modular scalability poses a few problems for traditional storage: 1) provisioning hundreds of VMs and tearing them down rapidly becomes a bottleneck, 2) scalability becomes a challenge with limited numbers of LUNs/volumes and number of VMs that can be supported on a single system and 3) performance problems when deploying hundreds of VMs become magnified.
In traditional environments where the mission critical object is a single VM, it is easier to apply traditional QoS policies: there is only one object to apply the policy on. But in cloud applications, it may not always be clear where the bottlenecks are since the VMs suffer from the IO blender effect even more. Plus, the more manual QoS management becomes, the more fragile your environment becomes, not to mention the additional administrative complexity imposed.
Troubleshooting performance issues in virtualizaed environments deployed on traditional storage systems is often a laborious process involving spreadsheet magic, gut instinct, and moving VMs by trial and error to try to isolate a performance problem. Storage management tools will often report metrics at a LUN/volume level and offer no visibility at a VM level because the traditional storage side has no VM-level awareness. Once you find a solution, it may only work until the next change in the environment—one performance usage spike in a VM or creating/destroying sozens of new VMs can change the environment and the troubleshooting has to start over again.
The rate of change in a cloud environment is much faster than in a traditional virtualization environment. The nature of cloud applications is to create and destroy VMs at each tier to dynamically respond to demand. This will require more frequent troubleshooting and adds more variability to any root cause analysis. Solutions to performance problems will be useful for less time, since the environment is constantly changing.
While the IO blender problem is a major challenge in a virtualized environment, it becomes even more acute in a cloud environment where the number of VMs is increased as is the rate of change in the environment. Not having visibility from virtual machine management directly to the storage level becomes a critical gap in functionality, and threatens the success of cloud projects.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.