In the first blog of this series on optimizing application performance in the cloud, we outlined a number of core vCloud Air features that enable you to meet high performance and availability requirements of your workloads. In this blog, we’ll examine the built in high availability and resiliency of vCloud Air.
High availability is an expectation in the cloud – always on, always available, anywhere at any time. One key difference between vCloud Air and other popular public clouds is our definition of “high availability.” Most large public clouds speak only of the availability of their service, meaning you can access their data centers 99.9.…% of the time, but their responsibility ends there. Or they may give you specific guidelines for how you have to architect your application around their features to create a set of highly available virtual machines (VMs). Either way, to make your application highly available you have to fully understand the provider’s cloud architecture and design your application to optimally span multiple data centers and other provider-specific services. If you are building a new application, that may not be such a big deal, and you would not be faulted for believing that every application is being completely rewritten and moved to the cloud. The technology press is gleefully hyping the end of private data centers. But all one needs to do to disprove this theory is to start counting the number of off-the-shelf applications still in use, or better yet, the number of applications still running on mainframes, RISC, or Windows NT/2000/2003 to see that there is actually a huge number of applications that obey the first half of Newton’s First Law (“Objects at rest tend to stay at rest…”).
So what do you do with all those existing applications that cannot be completely redesigned to run in this exciting new world of the cloud? After all, it would be nice if the cloud benefits of agility and flexibility, spending OpEx versus CapEx, and focusing on the applications instead of “racking and stacking” and endless infrastructure POCs extended to our traditional applications, too, correct?
vCloud Air is built on infrastructure that is architected for High Availability leveraging proven vSphere High Availability (HA), vSphere vMotion, and the Distributed Resource Scheduler™ (DRS). These technologies allow us to migrate live workloads and/or automatically restart VMs in the event of host maintenance or unexpected issues, as well as maintaining a consistent level of high performance across hosts when applications from multiple tenants get busy.
- With vSphere vMotion, we can migrate live VMs to transfer your workloads during maintenance, without downtime. We handle this for you in vCloud Air today so you will probably never even know it is happening and our maintenance windows will not disrupt your applications.
- During the keynote at VMworld 2015, we demonstrated a live vMotion of a VM from an on-premises environment to vCloud Air. Today, vCloud Air is one of only a few major cloud vendors that uses live migration to do maintenance. Just imagine doing a live migration to move your application to and from the cloud! Called cross-cloud vMotion, this is still in Technology Preview, but stay tuned.
- DRS continuously monitors CPU and memory utilization across a cluster of vSphere hosts, allocating resources among VMs and rebalancing performance during high-volume peak times.
HA delivers the availability required by most applications running in VMs, independent of the operating system and application running in it. Windows or Linux; off-the-shelf or custom developed; single VMs or many: HA provides uniform, cost-effective failover protection against hardware and operating system outages within your virtualized IT environment. HA can:
- Monitor VMware vSphere® hosts and VMs to detect hardware and guest operating system failures.
- Restart VMs on other vSphere hosts in the cluster without manual intervention when a server outage is detected.
- Reduce application downtime by automatically restarting VMs upon detection of an operating system failure.
Other cloud providers require you to build availability in to your application. If you are lucky this can be as simple as putting a load balancer in front of multiple VMs in the same tier to achieve some basic level of availability. But often this requires redesigning the application and paying for the load balancer. For example, one best practice from cloud providers is to design your application such that it runs concurrently in two different data centers or zones. Very few people would argue that this approach is not sound, in theory: VMware has been working with customers for years to do exactly this with metro storage and stretched vSphere clusters. But the challenge is not creating stretched infrastructure. The biggest problem is re-factoring an application to make it work when parts of the application might stop and start in different data centers at any given time. Making this work takes orchestration and a level of self-awareness for applications; features that are not so easy to just bolt on.
Now expand that thinking to another cloud availability enabler: splitting your application in to microservices. Again, the thought here is a good one: each microservice is supposed to be able to scale independently and should run independently of the other microservices such that a loss of part of the service does not affect the other pieces of your application. Lovely, yes? Maybe…maybe not. Do not take this the wrong way: we are not saying microservices are bad. In fact, I think microservices offer a host of advantages over monolithic applications. But you cannot simply divide your application into multiple VMs and declare victory. Going back to our previous example we have now gone from a rather simple, monolithic application that ran in a single data center to a whole host of smaller applications that are split amongst multiple data centers. There is complexity there and a very real risk/reward trade-off that needs to be balanced along with deciding whether your staff is up to the challenge.
This is why we built vCloud Air to run your applications as-is, providing availability SLAs all the way down to a single VM instance, and balancing resources across multiple tenant needs with DRS. You should not be required to rebuild your application to get the flexibility and agility that cloud can provide. Of course, vCloud Air customers usually do not just stop at moving applications to vCloud Air. Once in the cloud they start to explore features like our Advanced Networking Services and using APIs, automation, and CI/CD tools to deliver services faster. And, where it makes sense, customers do look at application redesigns as well, but with vCloud Air it is not because they must redesign to ensure the application is always available.
Watch this short video that goes into more detail about the advantages of HA with vCloud Air.
Additionally, check out our blog on how storage can optimize workload performance during peaks or spikes in traffic.
If you’re ready to get started with the hybrid cloud, visit vCloud.VMware.com.
Be sure to check out the vCloud Air Community, where you can join or start a discussion, watch our latest vTech Talk video, enter for a chance to win swag in our monthly giveaways and more. Get started here!