Virtualization is often thought to be an infrastructure topic, Recently, my colleague Liz Hatch and I presented a virtualization walkthrough to the Boston .NET User Group. At KMA, virtualization provides us with the essential scale to support relatively dense server volumes with a comparatively small physical footprint. We work principally on the Microsoft Virtual Server/Hyper-V platform, although most of the basic concepts are valid in VMware, Xen, or other virtualization hosts.
At KMA, virtualization allows us to support multiple operational needs:
· Multiple Software development systems
· Testing environments that replicate an entire ecosystem, including login servers, database, web, mail, and clients
· Demonstrations and proof-of-concept environment
In a virtualized environment, a single server can simultaneously support one or multiple guest systems.
In Hyper-V, each guest OS hard disk is maintained on the host as a .VHD file. As a result, its easy to snapshot, copy and rollback a server before or after deplying test software or running an new build.
IN addition to running Windows, there’s another possible approach. Hypervisors provide the essential support for server hardware to support multiple guest operating systems, but without a host operating system. Hypervisors make the most efficient possible use of the server hardware, since they don’t need to support a multiuser GUI, desktop applications, etc. However, we’ve found the comparative ease of use of Windows 2008 R2 makes allowing our developers to self-support their own development environments.
In large enterprise environments, production systems operate under stringent control to support high availability. However, this can mean that lower availability is thought to be OK for test or development regions. Hyper-V makes it easy for a developer to maintain, apply, and rollback their own virtualized images without relying on an overextended (or nonexistent) infrastructure support team. For developers, the “dev region” IS production.
In our virtualization design, we emphasize centrally hosted virtual servers as opposed to Windows 7-hosted Virtual PCs. The ubiquity of high speed Net connections, along with multiple VPN connections make accessing our central server core from the office, home, client site, or mobile location seamless. (For those few locations without remote connectivity, we make light use of local Virtual PC hosts for self contained demonstrations.) Central servers provide better security, backup, power, memory usage, and performance.
In addition, multi-instance applications like Microsoft Office SharePoint Server 2007 (MOSS) or SQL Server 2005/2008 allow us to achieve even greater server density on each single server.
In a departure from past practice, we no longer name guest servers to designate their host OS. (I had once used designators like VDEVSQL08-H03 to show that the server was hosted on “H03”.) But guest OS are no longer tied to a single host. Modern virtual machine management, like VMware vMotion System Center Virtual Machine Manager, make it easier than ever to switch a running guest OS to a new host on the fly, with no down time. As a result, hard coding the host name into the guest system name is no longer relevant.
Even with greater server density, multiple guests systems can rapidly consume more RAM than the host system supplies. Developers need to designate always-on vs. on demand systems, and work cooperatively to temporarily shut down or suspend unused systems.
I’ll have more on virtualization tips and tricks in a future post. Until then, thanks for reading.
