Virtualization in todays IT world is practically a given. Whether you’re a fledgling developer writing applications to get that first break or a seasoned IT Architect designing a solution for a fortune 500 company, there’s a good chance you use virtualization in some aspect of your day to day life at work. You may not realize it but you’re probably using virtualization right now reading this article. The Java Virtual Machine that is used on the server to present some of the components that you see on this page is a form of virtualization, but not the kind we’re going to talk about in this series of posts.
With modern x86 processors approaching 18 cores and more, combined with Intel’s Hyperthreading technology we find ourselves with a TON of computing power in todays servers. With even a modest low end 2 socket server, you’re looking at up to 72 virtual CPU’s to work with. Applications and especially operating systems have been designed for years to take advantage of SMP (Symmetric Multi Processing) to spread the work among multiple processors and get more work done quicker. It didn’t used to be that way however. Back in the mid 80’s, Rockwell International designed one of the first 8 bit processors with two cores on the same chip. Later in the 2000’s, Intel and AMD went on to develop multi-core processors as well and for the most part, Intel has stayed on top of the game continuing to push the envelope in the x86 processor market. And lest we forget that Oracle (formerly Sun Microsystems) released their UltraSPARC T1 in March of 2006 with either 4, 6 or 8 cores. Additionally, each core had up to 4 threads for a total maximum number of 32 virtual CPU’s on a single socket. 2006 folks- this was a big deal!
With so many processors comes the fact that most of the time, servers sit idle and only utilize the bulk of their processing capability during peaks that typically come once a month or at year end processing times. Multiple studies conducted by Gartner and other organizations have observed that the average utilization of servers ranges from 6-12%. This means that 88-94% of the time they are doing little or no work. Not a very good return on investment is it? With Virtualization, we can maximize the utilization of the resources that have already been purchased and gain a lot of flexibility at the same time.
Another aspect of datacenter processing is the nature of their criticality. In the IT world, you have to be up all the time. There’s no room for unplanned outages due to unforseen circumstances like power outage or natural disaster. Planning ahead is the key and disasters have to be accounted for. This brings us to the reason for this article. Most companies will have a plan for how they will provide services in the event of a complete failure of their primary datacenter. Typically it will involve placing a set of servers and some storage at an alternate location to take over business functions in the event of a catastrophe. It isn’t enough to simply have servers and storage, there’s a layer of complexity in today’s business software that needs to be accounted for. Virtualization definitely falls into this category. I will be talking about how a disaster recovery solution based on Oracle VM for x86 can be designed, implemented and tested with little or no investment in capital hardware. What’s more- the very same recipie or “run book” you wind up using to design your simulated data centers can be used to implement the real thing!
In the next couple posts, I’ll lay out step by step how to put this together in a very basic form to see how the pieces work together. If will be a very slimmed down environment based on the work I’ve done as well as some really useful training from Greg King (principal technical consultant with Oracle VM product management) to put this together. The main reason for that is that my laptop only has 16gb of memory so I was somewhat restricted by that. You may not be as limited on horsepower so feel free to scale this out to look closer to what you’d implement in reality. My solution is based on all Oracle technology but yours doesn’t have to be. I chose Oracle VirtualBox as my virtual sandbox, Oracle Linux for the guest OS and Oracle VM for x86 for the simulated hypervisor.
In Part 2, I’ll start laying out the VM configurations.