High Performance Drupal

Chapter 11. Drupal and Cloud Deployments

You’ve probably heard one of two things about “the Cloud”:

1. Cloud deployments are the future and the present; the be all and end all of flexible, dynamic, enterprise-grade, and agile infrastructure design.
2. Cloud deployments are entirely a marketing innovation and are championed by people who probably should be in the PR department, but somehow wandered into the wrong meetings too many times and are now on the technical staff.

You can easily hear both of these arguments at any major conference (usually in the same conversation and at high volume). You might say there is some disagreement in the community on the merits of the cloud. We will try to clear up some of the confusion in this chapter.

What Is the Cloud?

That this question must be asked is one reason some people find the concept of “the cloud” annoying. The term is used so often that it now means basically nothing (a phenomenon now known as “cloud washing”). For our purposes, we will be defining the cloud as a virtualized hosting solution, where VMs can be created and destroyed on demand via an API with no human interaction. This is a very common definition and fits clouds such as Amazon EC2 and Rackspace Cloud. Just to be absolutely clear, by “API” we mean a client-visible API that allows you to script automatic growth and shrinking of an array of servers.

Why Use the Cloud?

The major advantage of a cloud deployment is flexibility. If you need 10 web nodes today, 30 tomorrow, and 5 the next day, that’s something the cloud can give you that a typical hosting environment struggles with. This makes cloud deployments incredibly good for startups and any venture where traffic varies greatly. They can also be excellent for testing, as you often only need a VM for a matter of hours.

This flexibility is definitely revolutionary and is why the cloud is such a big deal right now. The ability to design a system that actively scales itself up (i.e., increases VM counts) as load increases allows for infrastructures that used to be impossible without a huge investment. Some clouds even allow you to integrate into an existing hardware infrastructure; for example, having a web node array to supplement your hardware web nodes during times of high load.

This ability to dynamically adjust your infrastructure, and to treat hardware as a service, opens up huge possibilities and is very exciting.

Infrastructure Overhead

One of the reasons that, despite all of these exciting aspects, some people are still annoyed with “the cloud” is that there is a significant cost to building up the automation required for using it well. This cost (technical overhead) is glossed over by many, and as a result, people end up with virtualized infrastructures that are not doing them any good (and may in fact be doing them significant damage). Let’s discuss an example.

Suppose you are currently testing your site with two web nodes and a database server, and you decide to move to a cloud deployment. You start the two web nodes and DB server on this cloud deployment. You don’t have any automation, so you must configure each of the web nodes by hand (at least partially—let’s say you have part of your web stack automated, but not all of it). What are you gaining at this point? Your new VMs are likely less powerful than the hardware you had before and they are certainly less reliable—remember that these clouds are designed for automation, and a VM “disappearing” is not unexpected. At least you can scale automatically though, right? No. Unless your automation is complete (meaning able to go from an “empty” VM or a saved image to a working web node without interaction), your response to a load increase will be very limited. You can manually start and set up new VMs, but that’s not going to be exceptionally effective. This is the big issue: to leverage the cloud, you must have fully working automation. There is a very real cost for this, and it’s a cost that is often ignored.

Prepackaged Clouds

There are other options besides trying to build this automation entirely yourself. There are providers that have built “managed clouds,” allowing you you to input your code and database on one side and have your site hosted on their reliable, autoscaling infrastructure on the other. The tools you are given are somewhat more detailed than this, but the idea of a black box for the infrastructure component is valid. Acquia Cloud and Pantheon are examples of providers offering prepackaged cloud services for Drupal.

The advantages to this are: you get some of the autoscaling benefits of cloud deployments, without the large investment in infrastructure building. The disadvantage here is flexibility. If your site doesn’t fit the provider’s expectations for build or usage, you will not have a good experience.

There is also a middle ground where you get to manage your own infrastructure, but many tools and scripts are provided to help you automate it. An example of this is RightScale. There is still a lot of infrastructure investment required for this option, but less than if you were to start from scratch, and they give you a significant amount of documentation.

Common Issues with Cloud Deployments and Their Mitigations

Obviously this isn’t a book on virtualization, and your issues with cloud deployments will vary widely by what type of site you are hosting, its usage, and what technologies you are using. However, we can go over some common issues and how to mitigate them:

Slow IO

This varies by provider, depending on what type of IO backend they use. Many cloud hosting providers have very slow IO backends when compared to a typical hardware-based RAID host. This often impacts database servers the most, but it can also slow down web requests depending on how many PHP files are touched during Drupal’s bootstrap. Mitigating this concern involves ensuring that you tune the real-path cache, possibly turning off apc.stat, and ensuring that your DB server has enough memory and is configured to fully cache your data. These topics are covered in Chapters 13 and 18.

Disappearing or failing VMs

Virtual machines on most cloud providers are treated as a variable resource. This isn’t a failure of clouds at all; it’s by design. Hardware as a service cuts both ways. When designing your infrastructure, you need to be able to both take advantage of this (increase resources when needed, reduce when not) and prevent the negative aspects from taking your site down. Test your high availability plan to ensure that it will really work, as it will eventually need to be used.

Limited IP failover

A common method of building high availability into a system is to have a floating IP address that moves between two servers in the event of a failure. This method is not supported (or not supported well) by most clouds—for example, some clouds have the ability to fail over IPs, but with a variable delay to the failover. Thus, alternate solutions are often required. Many providers have these solutions built into their clouds; if not, you may need application layer failover or DNS failover. We discuss this to some degree in Chapter 12.

In summary, there are very real advantages to cloud hosting and hardware as a service. It is very exciting to be able to handle load and build infrastructures that would never have been possible for smaller companies before. However, the hype around cloud hosting needs to be managed carefully. There should be a real reason for you to use cloud hosting, and you must actually plan for its use and the automation it requires.