Server Virtualisation? Is 'Bod simply being obtuse; yes it is entirely possible but before you write this off as lunacy, I do have my reasons.
Firstly, server virtualisation is not actually a bad thing; it's been around for many years but the landscape today is actually more than a little concerning and I wonder if it will come to bite us really rather nastily over the next decade. The sheer number of virtual servers being built leads me to wonder about the long term sustainability of the current infrastructures and with the current virtualistion==cloud lazy thinking; I am really rather worried.
So how did we come to such a position? The seeds for this were sown in the early eighties when IBM launched the personal computer; prior to this (and yes I am ignoring the early adventures in personal computing by Apple, Commodore, Radio-shack and the likes), computers were large, complex and extremely expensive beasts managed by the computing department; access was very restricted and not many people had access. But with the personal computing revolution; our relationship with computers changed, indeed we actually started to develop a relationship with computers.
One person mapped to one PC; that's the very definition of personal computing but as these devices became more powerful, it became pretty obvious that they were capable of so much more but the big, multi-user, multi-tasking operating systems which ran on the large corporate mainframes were not available for these personal computers. So we ended up running larger and more complex applications on these devices but using the operating systems available on the desktop; these were single-user operating systems with limited multi-tasking capabilities. So an application per device paradigm became the norm and even when multi-tasking became available and more common; the paradigm had become firmly embedded.
And the lack of multi-user capablities really hampered the development of a centralised management and secure environment; so it became even more embedded. Add into that, a growth in CPU power far outstripping our ability to use it for a single application; we ended up in the position that we had rampant physical growth but with ridiculously low utilisation figures.
So in order to use this power and to manage it effectively; we have looked to server virtualisation to fix this problem allowing us to build virtual servers which more effectively use the available CPU or more to the point allow us to run multiple single application servers on a single physical server. It also allows concurrent management of these applications to be more easily achieved. Even the rise of the Intel-based Unix systems has not done little to break the paradigm of one application per server but instead of a physical server, we now talk about virtual servers.
It doesn't have to be this way and we only have to look at the way that virtualisation is used in the mainframe environment; you don't talk about running 1000s of server instances, you are more clever about how you virtualise. You may virtualise an environment but it will still only run a few actual virtual machine instances.You may group related applications into a single machine instance but not have those applications running as separate server-instances.
We could do this in the Intel-space; we should move away from the default position of one application per server instance, we should move to the position where we understand why we do so. There are applications which certainly work better when run in massively distributed and parallel environments but this is not every application. A database server can run more than a single database instance; a web-server can run more than a single web-server.
Okay, it's not server virtualisation itself which annoys me but the unthinking use of it and the traps that we are busy building for ourselves.
Turning desktop operating systems into powerful server systems probably was not the wisest move that the IT industry made but the short-term gains were probably too attractive, can we hope that we don't do the same thing with mobile device operating system? Actually, I am not that hopeful really; history does unfortunately have a habit of repeating itself.
It’s simply cheaper and easier to use one OS instance per application. Your change management is decoupled from every other application in the environment as is your testing. The attack surface you have to worry about is limited to that application plus the OS which is a known quantity. Your performance troubleshooting is made easier and if need be you can very easily take a copy of the machine and move it into another environment for testing and problem recreation. None of these things is as easy when you commingle your environments. The old way of doing things leads to a very rigid, structured, and inflexible environment which is fine if you value stability over all else but that’s not what most businesses want out of their IT systems today.
Andrew, actually what you build is a configuration management nightmare if you are not careful. Instead of applying security patches to a handful of systems; you have thousands of operating systems to patch. In fact, reacting to a serious security related incident can be much harder.
And lets imagine you decide to move from Windows 2010 to Windows 2012, if there was such a beast? It might well be quicker and easier to do so if you had fewer instances.
The rigid, inflexible environments you talk about; that’s myth. They can be just as flexible and agile as any other environment; don’t let your processes dictate your technology.
The reason that you have this perception is that generally the large systems have been deployed in banking environments and guess what; their change processes are just as inflexible for virtual environments. I can point you in the direction of certain investment banks who take weeks to deploy a virtual server environment due to process. I suspect their mainframe teams actually deploy test and development environments considerably quicker because they have less work to do to deploy.
And as for most businesses not wanting stability out of their IT systems? Are you sure? They want both stability and velocity…the current path to velocity may eventually lead us into a hare and tortoise situation.
Quite frankly, the tools are not there to allow us to generally effectively manage masses of virtual server instances.
I think there are lots of different options and ways. Normally virtualization digs a toe-hold in a small door, and then if it is accepted all the sudden it takes off and there is a view that everything must be virtualized if possible. The quickest and easiest method is just to look at VM’s as individual logical containers bounded by what they do. You can make as many logical containers with little cost (at the hypervisor layer) as you want so people tend to go overboard and make a bazillion of them.
Having said that there often is real value in separating things into smaller units. Often there is an overhead with making a bigger VM, multi-cpu’s in a VM has an overhead (that all the VM’s CPU’s have to be free simultaneously). Also think on some of the load balancing capability within a cluster of hypervisors. One can only move a VM from host to host, they can’t move a process within a VM. So if you have a mixed workload database with one heavily hit and other not. Making them discrete units could have benefit (provided licensing, etc also works out from a cost perspective).
If you are they type of organization that wants to get into the nitty gritty there is some value in being able really fine tune your environment. With lots of small VM’s I can tune how much capacity each will get, if I want to starve resources from a print server and give them to someone else I can do that; if I have a combination print server / database (not advocating to do that insane thing) the granularity of resources are for the entire instance.
Patching, while a very valid point isn’t very cut and dry. If you don’t have some form of automation, lots of servers mean lots of patches and probably lots of man hours. But also lots of discrete servers might mean fewer total validations as you don’t have to validate app coexistence with patches. Finding the dependency for patches is easier when there is only one app to find, rather than trying to find the lowest common dependency between 5x different apps running on the same server.
Virtualization is an enabler, it can either enable you to be flexible, quick to market, etc or enable you to do to really stupid things quickly. You will either be successful or not based upon how *you* manage it. (kind of like how I think about perl… you can either hack it up to something illegible or write some nice code)
I’d agree that the tools to manage VM’s are pretty poor at this time. We’ve probably got >1500 of them around (all server guests not VDI) and getting what I want out of them is not always fun, however I’ve got about the same number or more of physical boxes that are about as painful as well. Rather than maybe the tools are poor, is that the tools have access to so much more information and capabilities about VM guests but they still aren’t doing much more than physical tools do.
I don’t necessarily dispute much of what you say but how much of the workload management issue is due to the crudeness of the tools which are provided by the operating systems? It seems that this is something that the creators of Intel-based operating systems have ignored.
I wonder if this is a result of the one application per instance paradigm? If this is the accepted norm, then sophisticated granular workload management tools are not required at an operating system level? But if we look at the larger ‘traditional’ operating systems; we find many more sophisticated tools for managing workloads in a single operating system instance. There would be no problem in running a print-server, a mail-server and a database in the same instance if the operating system had better workload management.
Well think of it this way, in a hypervisor virtualized environment a guest is simply a process running. An os isn’t really able to manage what happens within a process only what resources a process can be given. So in a virtual environment the most granular performance management you can get is for the entire VM. True within a VM you can then use traditional methods to manage scheduling, etc inside it. The core reason is this: today one cannot split a process and run it on different physical servers, a process runs on one physical server at a time (however in app space you could use some MPI within a VM to access addtional resources on another box). The only way for a hypervisor to control the underlying processes would a paravirtualized configuration with parts of the hypervisor running within a VM which everybody is pretty much running away from these days.
There is no reason that you can’t virtualize a system and put a print, mail & db within the same guest and run it fine. You can use the same workload tools within a VM as you have in the past; but there is a good chance that if you have a cluster of hypervizors you can’t move the workload to other servers around as well. For good or bad, virtualization in general is about trying to push the max limits and reduce the idle time of assets. If you want your VM cluster to be able to move workloads around to maximize capcity, more smaller VM’s allow that to be done (at the expense of more VM’s to management, so pick your poison).
Think of it in the context of storage: in my view it’s easier to move a 100TB of storage from mirrored to raid5 when it’s chopped up into 10x 1TB luns rather than a single 10x TB lun. If I have to move 10TB at one time I have to have a 10TB free to land it, whereas chunked into smaller pieces of 10x 1TB luns my free space requirement to move might be just 1TB (or less) as a lun is migrated off I can then use it’s space for the next lun.
The workload management tools in most Intel-targeted operating systems are pretty crude; if they had better workload management tools, many of the virtualisation use cases could go away.
And if you are maximising efficiency; if you didn’t have to run large numbers of operating system instances and had decent workload management; it might be a even more efficient use of capacity due to reduction in overhead.