“Why would you want to virtualize a
server?” is a question I surprisingly still hear, particularly from
people with no experience of having used virtualization technology. A
typical follow-on comment is often “I’ve heard you can’t virtualize
database servers.”
A few years ago, that question and comment were
probably worth asking when IT teams were discussing virtualization of
servers running SQL Server. SQL Server is a resource hungry application
that needs particularly large amounts of memory and fast storage to
process big workloads, and a few years ago, virtualization technology
sometimes struggled to deliver those resources. As an example, some of
the ways virtualization software presented storage to a virtual server
meant it was inherently slow, and some virtualization software
architecture meant it could only assign relatively low amounts of memory
to a virtual server. Because of these issues, it was quite a few years
before organizations I worked in considered mixing SQL Server with
virtualization.
However, these technical limitations quickly
disappeared, so the pace of adoption increased, justified by benefits
that business and technical teams couldn’t ignore any longer. The
following sections describe the main benefits of using virtual servers:
Business Benefits
Selling the idea of virtualization to a
business is easy; in fact, it’s too easy. Even worse, I’ve had finance
directors tell me that I can design only
virtualized infrastructures for them regardless of what the IT teams
want — or, more worryingly, need! From a business perspective, the major
driver for using virtualization is obviously cost reduction. While the
cost of physical servers has dropped over time, the number we need has
increased, and increased quite quickly too. Today, even a relatively
small business requires several servers to deploy products such as
Microsoft’s SharePoint Server or Exchange Server, with each server
performing perhaps a compartmentalized role or high-availability
function. Therefore, even though server hardware became more powerful,
their “average utilization” dropped — and often to very low values. For
example, I’m willing to bet that if you checked one of your domain
controllers, its average CPU utilization would constantly be under 30%.
That means there’s 70% of its CPU utilization that could be used for
something else.
Therefore, it was no surprise when even systems
administrators, IT managers, and CIOs started to question why they had
10 servers running at 10% utilization and not 1 running at 100%. The
potential cost savings, often described by businesses as the savings from consolidation,
can be realized with virtualization by migrating from multiple
underutilized servers to a single well-utilized server. In addition to
cost savings, other benefits of consolidation can have a big impact on a
business too. For example, at one company where I worked, we
virtualized a lot of older servers because the facilities department
couldn’t get any more power or cooling into a data center.
In reality, the savings aren’t as straightforward
as the 10 times 10% utilization example, but it does demonstrate why
both business teams and technical teams began taking a big interest in
virtualization.
Technical Benefits
For IT teams, adopting virtualization
has also meant needing to learn new skills and technologies while
changing the way they’ve always worked to some degree. However, despite
these costs, IT teams across the world have embraced and deployed
virtualization solutions even though it likely represented the biggest
change in their way of working for a generation. This section looks at
the benefits that drove this adoption.
One of the main benefits comes from consolidation.
Before virtualization was available, data centers had stacks of servers
hosting lightweight roles, such as domain controllers, file servers,
and small database servers. Each of these functions had to either share a
physical server and operating system with another function or have its
own dedicated physical server deployed in a rack. Now, using
virtualization we can potentially deploy dozens of these low-utilization
functions on a single physical server, but still give each its own
operating system environment to use. Consequently, server hardware
expenditure decreases, but also equally and perhaps more importantly, so
do power, cooling, and space costs.
Another technical benefit comes from how virtual
servers are allocated resources, such as memory and CPU. In the virtual
world, providing sufficient physical server resources are available,
creating a new virtual server is purely a software operation. When
someone wants a new server deployed, no one would need to install any
physical memory, storage, or CPU hardware, let alone a completely new
physical server.
Likewise, an existing virtual server can have
additional resources such as extra CPUs or memory allocated to it at the
click of a mouse — providing the physical host server has the
capacity—then the next time the virtual server reboots it will see and
be able to use the additional resources.
Both deploying a new virtual server and allocating
addition resources can be done in seconds, drastically increasing the
flexibility of the server environment to react to planned and un-planned
workloads.
Encapsulation
The final technical advantage we’ll discuss is a benefit of something virtualization does called encapsulation.
Despite how they appear to the operating system and applications
running within the virtual server, when virtual servers are created,
their data is stored as a set of flat files held on a file system;
therefore, it can be said that the virtual server is “encapsulated” into
a small set of files. By storing these flat files on shared storage,
such as a SAN, the virtual servers can be “run” by any physical server
that has access to the storage. This increases the level of availability
in a virtual environment, as the virtual servers in it do not depend on
the availability of a specific physical server in order to be used.
This is one of the biggest post-consolidation
benefits of virtualization for IT teams because it enables proactive
features to protect against server hardware failure, regardless of what
level of high availability support the virtual server’s operating system
or application has; more about these are discussed in the
Virtualization Concepts section. This type of feature won’t usually
protect against an operating system or database server crashing, but it
can react to the physical server the virtual server was running on
un-expectedly going offline.
This level of protection does incur some downtime
however, as the virtual server needs to be restarted to be brought back
online. For those looking for higher levels of protection, VMware’s
Fault Tolerance feature lock-steps the CPU activity between a virtual
server and a replica of it; every CPU instruction that happens on one
virtual server happens on the other.
The features don’t stop there. Some server
virtualization software allows virtual servers to be migrated from one
physical server to another without even taking them offline, . This feature can be critical to
reducing the impact of planned downtime for a physical server as well,
whether it is for relocation, upgrading, etc.
There are, as you’d expect, limitations to how
this can be used, but generally it’s a very popular feature with system
administrators.
SQL Server 2012 and Virtualization
Many people ask me how SQL Server
behaves when it’s virtualized. The answer is that it should behave no
differently to when it runs on a physical server, especially when it’s
deployed in a properly resourced virtual environment, just like you
would do with a physical server. However, virtualized instances of SQL
Server still need adequate, and sometimes large, amounts of CPU, memory,
and storage resources in order to perform well. The challenge with
virtualization is making sure the resources SQL Server needs to perform
adequately are always available to it.
Additionally, virtual servers running SQL Server
can benefit from some of the features that encapsulation brings, which
we’ve just discussed; however, it’s at this point that some
virtualization features, such as snapshotting a virtual server, Microsoft does not support using
with SQL Server.
However, regardless of all the resource allocation
activity that happens between the physical server and virtualization
software, it’s true to say that SQL Server itself does not change its
behavior internally when run in a virtualized environment. That should
be reassuring news, as it means that SQL Server will behave the same way
whether you run it on a laptop, a physical server, or a virtual server.
Nor are any new error messages or options enabled within SQL Server
because of it running on a virtual server, with the exception of Dynamic
Memory support that’s described in a moment. That’s not to say that you
don’t need to change how you configure and use SQL Server once it is
virtualized; in fact, some of the server resource configurations are
more important in the virtual world, but they are still all configured
with the standard SQL Server tools.
The one feature in SQL Server 2012 that does
automatically get enabled on start-up as a consequence of being in a
virtual environment is hot-add memory support. This feature was released
in SQL Server 2005 and originally designed to support physical servers
that could have hundreds of gigabytes of memory and large numbers of
processors, yet could still have more added without them being powered
down or rebooted. Once additional memory had been plugged in and the
server hardware had brought it online, Windows and SQL Server would then
auto-detect it and begin making use of it by expanding the buffer pool.
While this sounds like a clever feature, I suspect very few users ever
had both the right hardware and a need to use it, so the feature never
gained widespread use.
Fast-forward a few years and Microsoft’s Hyper-V
virtualization technology shipped a new feature called Dynamic Memory.
By monitoring a virtual server’s Windows operating system, the Dynamic
Memory feature detects when a virtual server is running low on memory;
and if spare physical memory is available on the host server, it
allocates more to the virtual server. When this happens, the hot-add
memory technology in Windows and SQL Server recognize this new “physical
memory” being added and dynamically reconfigure themselves to use it —
without needing to reboot Windows or restart SQL Server.
This behavior was available in the Enterprise and
Data Center Editions of SQL Server 2008, but support for it has expanded
in SQL Server 2012 to include the Standard Edition. This expanded
support demonstrates how closely Microsoft wants its virtualization
software, operating system, and database server software to work
together. The expectation by Microsoft is that use of this feature will
become routine once it’s made available to the Standard Edition of SQL
Server.
Limitations of Virtualization
Like all technologies, virtualization
has limits, restrictions, and reasons not to use it in certain
situations. Some virtualization vendors would like you to virtualize
every server you have, and in fact, some now even claim that today
that’s possible. However, this all-virtual utopia is likely to be
challenged by your applications, IT team, and budget.
Why might you not virtualize a new or existing
server? The original reason people didn’t virtualize has rapidly
disappeared in recent years: a perceived lack of support from
application vendors. In hindsight, I attribute lack of adoption more to a
fear of not knowing what effect virtualization might have on their
systems, rather than repeatable technical issues caused by it. The only
actual problems I’ve heard of are related to Java-based applications,
but fortunately they seem rare and SQL Server doesn’t use Java.
Another rapidly disappearing reason for
restricting the reach of virtualization is the resource allocation
limitations that hypervisors put on a virtual server. Despite VMware’s
technology supporting a virtual server with as many as 8 virtual CPUs
and as much as 255GB of memory as far back as 2009, most people weren’t
aware of this and assumed virtual servers were still restricted to using
far less than their production servers needed. As a result, it was
domain controllers, file servers, and other low-memory footprint
workloads that were usually virtualized in the early phases of adoption.
Today, the capabilities of virtualization software
has increased considerably; VMware’s software and Windows Server 2012
now support 32 virtual CPUs and 1TB of memory, per virtual server! This
means even the most demanding workloads can be considered for
virtualization. The only current exceptions are what are considered to
be “real time” workloads — that is, applications that process or control
data from an external source that expects reactions or outputs within a
specific number of milliseconds rather than a certain number of CPU
clock cycles. To do this normally, the application requires constant
access to CPU resources, which is something that virtualization software
by default removes. You can enable support for real-time workloads in
some virtualization software but doing so removes some of the management
flexibility and resource utilization benefits virtualization has.
