Virtualization of Enterprise Systems - Primer

eSaysSomething, iDontUnderstand, vCanHelp

Back to Virtualization and Cloud Index

I find that my best blog entries have two characteristics; they are a series of articles and they are written as I research and learn a new topic. So, right now I am researching virtualization so here we go with a set of articles based "ECM and Virtualization".

BTW, the subtitle of this post makes more sense if you say it with a German accent – it is no funnier but it makes a bit more sense…maybe.

It goes without saying that virtualization, as the technology behind most public and private clouds, is something that is in everyone's future. I for one have been using the wrong vWords in the wrong vPlaces and I'm guessing that most people that I work with don't know the vDifference because they are not correcting me. For this reason I decided that I needed a better understanding of the basic technology and real-life usage patterns. I jumped online and did a search for "VMware Primer" and “a vApp is a” and managed to find some high-level marketing overviews of vApps, VMware images, etc. I also found some great technical descriptions but I couldn't find a simple overview of the relationship between all of the parts and how they relate to an enterprise system like a traditional ECM solution.

Let me apologize to VMware ahead of time, my oversimplification of your products is more about making them relevant to this one specific case than it is about me not caring about your products.

In this series, I'll start with an overview of the relevant pieces of the virtualization stack, a description of each and then their relationship to a standard ECM deployment. Then once we have established technically how the stack fits into a vWorld we will look at what models can be used in relation to ECM and finally a practical look into what works in real life…aka, why you should care. I’ll also take some time to look at SharePoint online and how SharePoint in the cloud might work in your on- or off-premise virtualized ECM environment.

You'll notice that I'm not using the word ‘Cloud’ much at all, I'll avoid this word because it seems that no one quite understands what Cloud might actually mean (other than a meteorologist that is). Rather than entering into a ecumenical debate about what is a cloud and what is just suspended water vapor I'll focus on virtualization and you can decide what's vapor and what's just vapid.

So, let's start at a high level with the most relevant pieces of the VMware stack. In order to try to explain what each of these is I'm going to relate them to both their physical and ECM counterparts. In the table below I have listed each of the pieces in the virtual stack, on the left is what this thing would look like in non-virtualized world, on the right is a an example of this in ECM terms.

Physical World	Virtual World	ECM World
An application	An application	An application
A single server including the hardware, OS and apps.	A VMware image	The web server, database server or core ECM system
A gaggle of servers supporting a single enterprise application (database, app, web, core etc.) plus associated network connections and policies.	A vApp	All of the servers need to support a single ECM deployment (content database, content management server, web servers, etc.)
The replicator off the Starship Enterprise.	vCloud Manager - creates non-conflicting instances of the entire vApp. Includes VMware vShield for security.	Paying Professional Services to install, configure and deploy another instance of the ECM system.

I'm intentionally glossing over some key components of the VMware architecture which also includes desktop/application virtualization, lower level system tools, reporting plus higher level datacenter management tools. If they turn out to be relevant to the stack then I'll add them later – when I’m finished I hope to have a much more comprehensive breakdown of the stack.

Hopefully you get the general idea from this - a VM (shorthand for a VMware image) acts just like a server, a vApp is a collection of VMs bundled up with the associated network relationships and policies which can be replicated, distributed and deployed to represent a typical server collection. There are a multitude of tools used to manage all of these bits but the one that you are most likely to be interested in would be vCloud Director which lets you (or even your end users) provision and manage vApps.

The list of products in the VMware library is pretty long and I do not have time/the interest to discuss all of them but some seem to crop up fairly often so I’ll attempt to give you a single paragraph for each of these:

• vCenter - The vCenter product is still used in some cases but vCloud Director will typically provide a superset of the vCenter functionality, I’m pretty sure that vCloud Director actually makes calls to vCenter behind the scenes but I’ll have to look into this in some more detail.
• Virtual Appliances are a subset of the newer vApps. vApps contain virtual machines packaged together in a platform independent format called OVF., I'll explain more in my vApp entry later.
• vSphere - The other piece to consider is the vSphere platform which controls the sharing of processor, memory, disk space and networking on a single server host (the actual physical machine). vSphere is effectively the runtime engine that manages the VMs are they are being executed on the physical server, . Don’t confuse this with vCenter or vCloud Director which are used to provision and manage the VMs before they are executed.
• Hypervisor - In order to fool the virtual OS into thinking that it is running on a real server (it does not know it has been virtualized which seems immoral) a layer of software sits between the physical server and the VM. This layer is called the ‘hypervisor’ and it allocates the hardware resources to the individual VMs in a way that makes it transparent to the VM.
• vFabric – VMware have a suite of development and run-time tools for application development optimized for a virtualized environment. This includes Spring, Hyperic, GemFire, etc. I might not bother with these as I feel strangely drawn to the infrastructure and cloud topics not the app development.

In my next post I'll drill down one more level to look into vApps and vCloud Director and how they might relate to a typical ECM (or any other multi-server) deployment.

Comments

[Douq Millar]

Do you know when VMs originated? I go far enough back to know one of the earliest, if not earliest. 1967!

IBM developed an internal system in their Cambridge (Massachusetts) scientific center, in cooperation with MIT Lincoln Labs, for a core capability called CP67 (Control Program for IBM 360/67). The 360/67 was an extension of the 360/65 with a jazzy new feature called "virtual memory", namely DAT - Dynamic Address Translation. This was critical to making this VM work so multiple OS instances could occupy the same address range (no address translation in OS's in those days, OS owned physical addresses 0...max).

The motivation behind this was to solve a problem that plagued IBM simultaneously building new hardware (360 product line) and the OS's (multiple) to run on that hardware. Developers stood in line to get their one hour on one of the few prototypes around and this severely impacted schedules of software development. But since 360 itself was still under development IBM couldn't just spend and get more machines

So the idea was, what if multiple programmers could share the same (rare) physical hardware to do OS testing that wants to own the entire box. So dynamic addressing was the first step, but the 360 had a cute trick. Most of the OS used privileged instructions. If you ran the OS in non-privileged mode it would, in today's parlance, throw an exception when it tried to execute a privileged instruction. So the exception handler become the second core part of first VM, simulate the privileged instruction. So instead of talking to a real channel (the I/O link on the 360) emulate that channel translated to real channel requests, but with different device emulation for each instance of the OS running, i.e. virtual disks, card readers, printers, etc.

So now the OS could be fooled into believing it actually owned all the hardware resources when in fact it didn't, but if the emulation was correct the OS would never know and software testing and debugging could proceed.

Now this was in the era where 100Megs was BIG disk, so the disks for each VM just became files on the real disk, ta-da, sound familiar.

And so forth. It actually worked and I was lucky enough to actually get use CP/67, really using it just as a time-sharing system. (CMS, the component from Lincoln Labs functioned as the equivalent of the "shell", in today's parlance, so this is the "UI" you actually saw). Cambridge Scientific Center was in same building as MIT's Multics development so there was a lot of synergy between the groups.

So what happened to this pioneering innovation. Well, first (IMHO) it got lost in internal IBM politics. IBM had the "official" time-sharing product, TSS, which was, again IMHO, awful. But like a cat, despite it many flaws, it had nine lives and the blessings of IBM and overshadowed CP67 which was both superior and much more interesting, esp. to "system programmers" (the people at customer sites who had to install new OSs, so the testing was hugely useful, so live production didn't have to be disrupted)

So the CP67/CMS "product" was only available to universities and a few other think tanks, courtesy of the fact that Brown University was one of the first users and a certain alum, T.J. Watson happened to want to give Brown whatever it wanted, regardless of the product management in 360-land.

Eventually IBM did release this as a general availability product (VM/370, IIRC) but they never promoted and it died out. But the concept struggled on and now has this remarkable rebirth today.

I find it interesting that we see something like VMWare, clearly a hot item today, as something novel. One of the few advantage of "experience" (i.e. being older) is having the historical perspective to see many "new" ideas as having their roots in something long ago.

Just thought you might find this nugget of historical trivia interesting.