By: Scott Shaw | Updated: 2011-06-29 | Comments (2) | Virtualization
I hear the rumblings of DBA's facing the prospective of virtualizing their databases. Some have managed to stave off the inevitable while others have embraced it slowly one test or development database server at a time. I'm writing a series of tips as a guide from a DBA who has already been drowned in the virtual sea to DBAs who want to take the plunge. My team manages more than 365 virtual database servers in the healthcare field and my company has virtualized more than 3,000 servers. Still, I'm not writing from the perspective of someone who is an evangelist for virtualization, instead; I'm writing this because as a DBA you eventually won't have a choice. If your company has more than 4 people, you will virtualize your servers. It is better you understand and read the new map now than continue to wander in the wilderness.
As a disclaimer, these tips do not teach you how to virtualize your servers. These tips are meant to teach you how to manage and understand your virtual environment from a DBA point-of-view. At the end of this series of tips, you should be able to talk the lingo with your server and storage group so you can better argue for an architecture that fits your needs. You will also learn some of the pitfalls I've experienced as well as some of the successes. I hope it proves useful.
So, you might be asking, what is a virtual machine? Simply put a virtual machine is a computer within a computer. One machine is physical and the other one is software (virtual). The physical machine is called the host and the software-based machine is called the virtual machine, or VM. The devious part of this relationship is the VM machine doesn't know it's a VM. The VM is like a goldfish in a fish tank thinking it's in the ocean. The VM machine sees it has RAM, IO, network and CPU but what it doesn't fully realize is these are only given to it by the good intentions of the host. All of those things can be quickly and seamlessly removed, or added, at the host's whim. Furthermore, the virtual machine may be sharing these precious resources with neighbors it knows nothing about. A database server could have a file server right next to it and they would never meet yet, that file server could steal CPU cycles from the database server. I know, it sounds cruel, but if the VM is happy than we shouldn't see the harm in it.
Image Source: http://zone.ni.com/devzone/cda/tut/p/id/8709
As of this writing, there are 2 major Enterprise-level VM providers: VMware and Hyper-V. Of course there are more vendors who offer VM solutions, but you'll most likely use one of the above unless you are installing VM on your desktop. Research sites estimate that VMware owns between 50% to 80% of the market with Microsoft's Hyper-V and Citrix's XenSource gaining ground. You will find that despite the various vendor offerings, the VM architecture remains closely similar. One or more virtual machines are running on a host managed by a VMM (Virtual Machine Manager). Everything else is a confusing jumble of alphabet soup. I'll define a list of common VM terms later in the tip.
What are the benefits to virtual servers?
Now that we have a rough idea of what a virtual environment looks like, let's discuss some of the benefits. Firstly, borrowing a resource such as CPU's (in a virtual environment they are called vCPUs since a CPU is not physically attached to the VM - the physical CPUs are labeled pCPUs) can be a good thing when you have plenty to spare. What works in life can work in VM. If you have plenty and someone else has little, you might as well share. Sharing allows companies to optimize resources. The technical term for memory sharing is called ballooning and refers to the delegation of memory resources where it is most needed on the host. Ballooning takes away from the classic provisioning which is typical when configuring new systems. Some DBA's like this and some don't. We'll talk about that more later.VM offers fast provisioning of new systems. Remember a VM is simply software or, in simpler terms, a file. An administrator can create a template of a VM. The template contains all the settings and software necessary to create a new system. Companies no longer have to wait for ordering physical hardware, or make room in the datacenter rack for new installations. The other benefits to the VM provisioning model include reduced energy costs, reduced capital costs, more disaster recovery options and, arguably, reduced management and operational costs.
What are the downsides to virtual servers?
Wow! So VM's are the perfect solution for everything, right? No. The risks are both architectural and operational. The inherent consolidation of resources onto a single host is a risk. Because you can have a large number of virtual machines on a single host, a failed host will potentially cause an outage for many systems. The equivalency is power going out for a whole rack of servers.
How the VM team configures the environment is another risk. There are some settings in a VM environment (power management comes to mind) that, if enabled, can be disastrous for certain types of applications (SQL Servers come to mind). The teams managing the virtual environment may not understand the resource needs of your system and this can compromise both performance and stability. Finally, remember you are sharing resources in a virtual environment but, as we all know, different applications have different needs. An OLTP database has different resource needs than a file server particularly when it comes to IO. Disks are already the bottleneck and VM won't change the equation.
There are also issues pertaining to control. As a DBA managing servers in a virtual environment I now heavily rely on the storage and server teams for information concerning performance and recovery. They control the centralized infrastructure and have made the decision to implement the physical hardware so now, as the DBA, I need to make sense of the architecture and how it affects SQL Server.
Whether you like it or not if you're reading this then either your SQL Servers have already been virtualized or someone has told you they will be. It's ok. The following tips will either help you redefine your existing environment or prepare you for your new one.
- Ballooning - The act of moving over provisioned memory to another virtual machine.
- Host - The physical machine running one or more virtual machines.
- vCPU - A CPU assigned to a virtual machine. This could be only a single core.
- VM - Virtual Machine. The software emulation of a physical machine.
- VHD - A virtual machine file in Hyper-V.
- VMDK - A virtual machine file in VMware.
- VMM - Virtual Machine Manager. The software running on the host, which coordinates resources across one or more virtual machines. You may also hear this referenced as the hypervisor or ESX.
- vMotion - The process of moving a virtual machine from one host to another with no application downtime. This term is specific to VMware.
- Virtual SMP - Virtual Symmetric Multi-Processing. The ability of a virtual machine to use multiple physical CPU cores.
- Virtual machine defined on Wikipedia
- VMWare's Homepage
- Microsoft's Hyper-V Homepage
- Look for the next tip where I will discuss specific aspects of virtualizing SQL Server.
Last Updated: 2011-06-29
About the author
View all my tips