Today I came across a question about virtualizing web servers and databases. It caught my eye because I'd asked a similar question back in November.
The question got me thinking about scalability. Whatever current woes running a database or any other application in a virtualized server may have now, they will eventually be solved or at least sufficiently mitigated to make it worth the penalty.
At this point we'll start seeing server applications that not only support virtualization, but require it. A virtual server can provide a standard environment that an operating system on traditional hardware doesn't quite match, and allows you to tune the resources available to a server without shutting down the machine. Imagine virtualization software that allows a live transfer of a system from one physical machine to another with no shutdown. This is already happening. What's interesting is where we go from here. I think the next logical step is clustering/load balancing and cloning.
These are features that are available now, but smaller businesses largely ignore. But I think that once all your major applications are on virtual servers, the clustering problem becomes much simpler. The load balancer will be a function of the virtualization software itself. Of course the individual application will have to support it as well, but this will become a core feature of any serious server application, even in the entry level editions. Setting up a cluster will be as simple as clicking a check box and typing in the cluster name. Maybe you won't even need to click the checkbox: you'll just give two or more servers the same dns name and the virtualization software will know what it means.
At this point, a small business with one server can add additional horsepower simply by buying a server (any server), plugging into the network, and telling their current virtual system to clone itself to the new machine. Large businesses can do the same thing.
For a practical example, let's look at the
new StackOverflow servers. One database and two smaller web servers. Under what I'm proposing each of those physical servers would carry a database instance and a web instance, each in a three-server cluster. If one goes down, the other two keep chugging happily away. Of course, if the current database server were to go down the site would be hurting.
But to be fair the planning would be different under my proposal, and Jeff probably would have purchased four machines more like the web servers, rather than one database and two web servers. This way he ends up with about the same power for about the same money. Perhaps even more power because he can add more memory cheaply. One server failure isn't a big deal now.
Even more significantly, as Jeff's traffic increases it becomes very easy to scale up the site infrastructure to match. All he needs to do to add a server is drop it in the rack and tell the virtualization software to create a new instance and hook it up. As it is, he's looking at having to do a major overhaul of his infrastructure in about two years.