Server Virtualization
Why it works so well
|
Virtual Server technology is not a new idea. The
act of creating a virtual representation of a physical computing platform has
been around since the days of the first time sharing mini-computers, where each
user could log on to the system and interact with the computer as if it was
their own physical machine. This
paradigm was also used in Sun’s launch of Java
and the JVM (java virtual machine) that promised the adage “write once, run
everywhere.” Interestingly enough,
Microsoft’s .Net languages also use a form of virtualization in that each
language compiles down to a common set of instructions (Microsoft intermediate
language) that are also hardware independent. The
main benefit of this virtualization is to abstract away the particular nuances
of each hardware platform and create an environment that is common and
consistent across a myriad of hardware platforms. This
allows applications and code to be written and compiled once, but run on many
different platforms.
The latest revolution in computational virtualization is
machine virtualization. In this
model, the whole computer itself becomes virtualized. A
virtual representation is created for each physical device on the computer.
Typically, a host machine will run a Virtual Environment much like any other
program or service. The virtual
machines will then run in the process space of the Virtual Environment on the
host machine. Devices like SCSI
hard drives, RAM and memory registers, CPUs and hardware I/O can all be
virtualized and setup in any way you want regardless of the actual physical
machine. You literally are running
a computer within a computer.
Obviously, we are still constrained by the performance of the host machine, but
the way in which the virtual machine operates can replicate a wide range of
scenarios. We also have the
ability to run multiple virtual machines from one computing platform. Given
enough CPU availability, memory, and disk space you can run several dozen
virtual machines on one piece of hardware (something many fortune 500 companies
have started doing.)
Once we fully understand the significance of this paradigm, a
whole new world opens up to us in how we approach software development, systems
deployment, maintenance, disaster recovery etc.. I
was first introduced to virtual servers a little less than two years ago.
I was attending a private partner training at Microsoft on the beta version of
BizTalk 2004, it was a week long intensive training session, and there were
about 40 of us partners there from all parts of the world. For
those of you not familiar with Microsoft BizTalk, it is a relatively
sophisticated server product and installing and using it requires a fair bit of
patience and a good understanding of Microsoft security and active directory. The
beta version installation was, how shall we say … “beta.”
When installing it for the first time I remember struggling for about a day and
half to finally get it installed correctly. I
was wondering how Microsoft was going to get this set up and running correctly
on over 40 different machines without having to completely wipe each machine
clean and Ghost a copy of a running platform.
So here we were at this training class, with the express
purpose of learning all the ins-and-outs of BizTalk server. Each
of us needed our own unique development environment to do the numerous labs and
exercises throughout the week. When
I first sat down to my workstation and looked at the set of instructions up on
the whiteboard, I saw that my first task was to make a copy of this large file
on the hard drive named something like “biztalk_training.vhd”.
I was curious why I needed to copy this file which was a little over a 1 GB. The
next set of instructions had us click on a desktop icon which immediately
brought up a full screen window and a set of boot sequence screens for a
windows server. I thought
“curious, I guess we are going to use some type of remote connectivity for our
lab work.” What I came to realize
over the next several hours was that I was actually logging into a windows
operating system WITHIN the windows operating system on the machine in front of
me. The big file I copied was the
virtual hard disk and complete hardware configuration for this virtual machine. As
the week went along and I learned to work with innermost parts of BizTalk
server 2004, which was impressive in its own right, I felt like I was having a
technology epiphany when it came to virtual server technology. I
was truly blown away and actually found myself excited about technology, the
way I was 25 years ago when I made my first pseudo program that landed an
artificial lunar module on my dad’s Heathkit 8088 breadboard computer.
At the end of the week, I found myself reflecting on the
amazing power of this new technology and what felt to me like a revolutionary
concept in software development and IT management. As
I started to think about the various ways I was going to implement this
technology I realized it crossed into almost every major functional task that I
performed in my role as a software architect, project manager and principal
consultant.
The first thing that came to mind was that I would now have
free reign in setting up new server environments and testing out new products
without fear of unnecessarily corrupting my personal machine or having to
scrape together yet another test machine.
I could simply load up my Virtual Server and create a new machine and load it
with the latest product I wanted to test. It
then occurred to me I could build different flavors of this machine and save
each one to use for upcoming projects as the need arose. I
could create servers that did EAI, Email, CRM, ERP … and the list goes on. Best
of all I could do this all from the comfort of my own personal machine.
I realized that once I invested the time to build these machines, which as we
all know sometimes is no small feat, that I could simply copy it for a coworker
or team member and they would have to invest less than 30 seconds to have the
same machine ready to go for their own special purposes.
My first project with using this technology was to build a
BizTalk server because I needed to do a proof-of-concept for a large custom
development project that I was just beginning to architect. The
beta BizTalk product had a pretty tricky install that required lots of
supporting services and products. If
you did not follow each of the several dozen steps exactly to the letter you
would have to start over. After
bungling a couple of installs I quickly realized that with virtual server
technology I could snapshot the server I was building when I got to a critical
stage in the install path where I frequently had problems. This
way, if the next install step failed I could quickly revert back to where I was
immediately before that step without having to start from scratch.
As I went about building my BizTalk machine I also made copies
of the virtual machine along the way. This
way I would have base platforms that I could then use to build upon later.
For instance, I created a base Windows 2003 machine and made a copy, I then
added SQL Server to this and made another copy, then I added Visual Studio to
the machine and copied that.
This way I would have a quick starting point for various platforms. If
I wanted to create a Sharepoint Server that required Windows 2003 and SQL
Server then I already had a clean machine with this installed on it.
Or if I wanted to create a Reporting Services machine that required Windows, SQL
and Visual Studio then I had one of those as well.
Each time I finished off creating one of these base machines I
ran Windows “sysprep” on the machine.
This tool, which is part of the Windows resource kit, will allow you to
reconfigure the name, UUID, SID (security id) of the machine in question. After
running sysprep.exe you are prompted at the next reboot for a new machine name. It
is necessary to take this step, versus just renaming the machine, because in
the process the machine will get a new SID and UUID which is unique to that
machine and necessary if you want to run it within the same network, and
especially Windows active directory, without conflicting with other virtualized
images you may have copied. I
found this out the hard way when I powered up two of my base machines that were
copies of the same base virtual image and the network was unable to recognize
the difference between the two of them and would not allow both of them to log
onto the domain.
One of the things I discovered while building my BizTalk
machine was that the virtual machine was much more responsive when I put the
virtual machine on a drive other than the one that the host OS was on. Additionally,
I found the performance to be significantly increased when using SCSI drives. I
also quickly realized that for the virtual server to be effective you need RAM
to spare. Originally my 512MB
laptop allowed me to work with the virtual server if I did not have a lot of
processes running in the virtual machine. But once I created a more powerful
virtual server, the memory limitations became pretty apparent.
I then upgraded the laptop to 1GB of memory and that allowed me to run one
virtual machine that performed as quickly as the host and 2 machines that had
acceptable performance but were noticeably slower than the host. The
virtual server technology also allows you to dynamically assign memory to each
guest machine, so you can increase or decrease memory allocated to the guest
machines as needed. I was able to
complete my BizTalk proof-of-concept successfully and best of all, when we got
into development several months later I was able to dig up the virtual image I
had created for the proof-of-concept and pass it along to the development team.
Following on the heels of my BizTalk project I had another
client project that had some very unique requirements in terms of the Microsoft
Server stack we were going to need to develop upon and deploy. This
new project was going to require us to install Microsoft CRM, BizTalk, Exchange
2003, Windows 2003 Active Directory into an existing server stack that already
had Microsoft Commerce Server 2000 integrated into Microsoft Great Plains on a
Windows 2000 domain. When I
started to review the project timeline and architecture I quickly realized that
when it came to the deployment phase we had no hope of meeting the deployment
window (48 hours) with a traditional deployment. It
had taken us nearly 2 weeks just to get Microsoft CRM and BizTalk to play
nicely with
Great
Plains. I could not imagine
having to perform this install on production machines in the middle of a data
center with live data and only 48 hours to complete it.
Another challenge we faced was the post-deployment risk
associated with having one of these servers going down in production. Normally
loosing a production server can be a trying experience. In this case, the
unique server stack presented an additional risk that was almost unacceptable. Because
of the server dependencies on a unique installation of active directory and the
fact we needed to build servers in a specific order with each server relying
upon unique information from the server built before it, we were exposed to
significant risk. If we lost any
machine in the server stack (starting with the AD controller) any subsequent
server in the dependency chain (build order) would have to be rebuilt from
scratch.
This could mean days of downtime
to a live commerce system just to replace one machine. By
deploying each server virtually and having a stored copy of each virtual
machine we could be guaranteed the ability to recreate the whole server stack
and not break the dependency chain.
It was at this point that I seriously started to consider
using virtual technology to deploy the WHOLE production platform for this
client. If this was possible I
would not only mitigate many production risks, but I would be able to reduce
project costs by creating a very straightforward deployment. My
primary concern at this point was project risk, and would I be exposing my
client to unmanageable risk in trusting this technology? Development
is one thing, but having seven production servers all running virtually?
My primary risks, as I saw them, was stability and
performance. I felt pretty
confident in the stability of the platform, since in the last couple months of
installing and configuring dozens of virtual servers not one had crashed. But
the performance issue was still an unknown, the virtual machines seemed to run
quick enough, but I needed some hard numbers. I
used a dual Xeon 2.8Ghz server with 3 GB of memory and a RAID 5 SCSI array as
my test bed. I first benchmarked
the system in its native OS for CPU processing speed, Memory Read/Write/Cache
and Disk Read/Write. I then
performed the same benchmarks within a VMWare GSX
(described below) server machine. Across
the board I got relative performance in the GSX virtual machine that was
90%-95% of the host physical machine.
I then started up another virtual
machine on the same server, both using 1GB of memory. The
benchmarks did not change, and I was very impressed. After
I presented the findings to the client and let them know that this development
and deployment strategy was going to save them approximately $25,000 in
additional service fees for a $75,000 project they gave an enthusiastic “yes”
to move forward.
For the next several months we developed the server stack with
7 virtual machines (Microsoft CRM, Microsoft Great Plains, Microsoft BizTalk,
Windows 2003 Domain Controller, Microsoft Exchange 2003, Microsoft Commerce
Server 2000, Microsoft SQL Server) running on three physical machines. We
were able to work through many issues with installation, configuration and
custom integration code that allowed us to thoroughly test and validate our
virtual production environment. Our
production cut-over also required a complex data migration requiring the
migration of 40,000 customers and all of their associated order history and
address information from three separate systems.
We were able to spend several weeks practicing and fine tuning our deployment
routine in our virtual environment until we were able to successfully execute
the deployment in less than 36 hours, leaving us a 12 hour buffer.
On the fateful weekend we undertook this deployment we had
some of the normal last minute issues, but we were able to successfully deploy
our solution on three physical servers and free up the existing 8 production
servers. Since that deployment,
the system has run flawlessly, and from what I understand in speaking with
Microsoft this is the only installation in
North America
leveraging all of these Microsoft server products in one environment. As
an interesting anecdote, we received an e-mail from the head of the Microsoft
Commerce Server team who wanted to speak to us about how we were able to
leverage all of these technologies together. When
I ended up speaking with them on the phone to talk about our solution it was
very hard to hide my enthusiasm for the fact that without VMWare this would
have never been possible. Microsoft was pretty amazed that we were
able to get all of these server products to integrate successfully in
production, it was something that no one else had been able to do yet.
The actual products
and vendors of virtualized server technology
There are two primary machine virtualization vendors; VMWare
(now owned by EMC) and Microsoft (who purchased the company Connectix and its
virtual pc technology.)
VMware is the predominant market player and has three main
products as described below.
VMWare Workstation: This
is intended for development use only, but is quite powerful, and has a
limitation of 4GB of memory that can be allocated across its virtual machines
for a given physical host. This
product can use either Windows or Linux as the host OS and it will support
either Windows or Linux virtually. This
product costs about $400.
VMWare GSX Server: This
is essentially the same product as Workstation, but allows up to 64 GB to be
portioned across its virtual machines for a given physical host and also has
features convenient for hosting in a production environment. This product costs
about $2500
VMWare ESX Server: This is VMWare’s enterprise product
and unlike Workstation and GSX, it runs under its own proprietary OS (a version
of Linux.) This product has many
advanced features not found in the other two products, most significantly its
LiveMotion add-on which will allow you to perform backups of the whole virtual
image while it is running. There are also many performance benefits as well. The
price of this package starts at about $15,000.
Microsoft’s foray into this market was through its acquisition
of a company called Connectix, which had its Virtual PC product. This
product is quite similar to VMWare’s workstation but, in my opinion is much
less user friendly product with much poorer performance.
Microsoft just recently released its server class product which they creatively
named “Microsoft Virtual Server.” Microsoft’s Virtual Server, not surprisingly,
will not run on Linux or support a virtual Linux environment. I
have deployed both VMWare GSX server and Microsoft Virtual Server to production
environments and there is not even a comparison. VMWare is by far a superior
product, both in terms of functionality, performance and stability.
Tips for
successfully leveraging Virtual Server technology
- Disk space and storage needs: Virtual Server
technologies have a voracious appetite for raw disk space.You will find yourself creating virtual machines for all
kinds of scenarios, and these virtual images gobble up disk
space.
You can configure them to have dynamically growing
virtual drives, but regardless, most virtual systems will end up
using several GB’s of data.
- Network Bandwidth:
If you need to move
virtual images from one machine to another it is helpful to have
a gigabit backbone to transfer images.
Trying to move a 30GB image through your corporate network can
become challenging on a 100MB connection going through several
routers or hubs.
- Memory:You
will want to have at least 1GB of memory on a host machine to
get decent performance out of your virtual machine.
Trying to work with less than that is fine for playing around, but if you
have serious development work to get done you will want more
memory.
- USB 2.0: If you
are deploying to a stand-alone machine, especially a server it
is very convenient to have a USB 2.0 port that you can just put
an external HD into and move images with.
I found myself stuck in a server room with a blade server
that only had USB 1.0 and no network connectivity.
Transferring 30GB of data across USB 1.0 requires a
enormous amount of patience.
- Backup:
Outside of VMWare’s ESX Server you can not dynamically backup complete
virtual images while they are running, and taking down a live
production server to back it up is not always feasible.
In this case you have to employ traditional backup
technologies, which you can simply install inside the virtual
machine itself.
It is still recommended that you make copies of your
virtual machines at regular intervals and have them stored in a
separate physical location.
