Databases Reference
In-Depth Information
running on a virtual server, neither of which are coni gured with any high-availability services, and
yet now protect SQL Server against unplanned physical server failure.
This technology isn't a replacement for the application-level resilience that traditional failover
clustering brings; we already saw that while the hypervisor might be successfully running the
virtual machine, Windows or SQL Server may have stopped. However, this feature can provide
an increased level of availability for servers that may not justify the cost of failover clustering or
availability groups.
Host and Guest Clustering
To conclude this discussion of virtualization's high-availability benei ts, this section explains how
the traditional Windows failover clustering instances we're used to using i t in with it. Host clustering
is Microsoft's term for implementing the virtual server high availability covered in the previous
section; that is, should a physical host server fail, it will re-start the virtual servers that were run-
ning on it on another physical host server. It does this by using the Windows Failover Clustering
services running on the physical host servers to detect failure situations and control the re-starting
of the virtual servers.
Guest clustering is where Windows Failover Clustering is deployed within a virtual server to protect
a resource such as an instance of SQL Server and any resource dependencies it might have like an IP
address and host name.
This is deployed in the same way a Windows Failover Clustering would be in a physical server
environment, but with virtual rather than physical servers.
Support from Microsoft for clustering SQL Server in this manner has been available for some time
now, but adoption had been slow as the range of storage options that could be used was small.
Today however, there are many more types of storage that are supported, including the SMB i le
share support in SQL Server 2012 and raw device mappings by VMware, which is making the use of
guest clustering much more common.
Deploying SQL Server with Virtualization's
High-Availability Features
When SQL Server is deployed in virtual environments, trying to increase its availability by using
some of the features described becomes very tempting. In my experience, every virtualization
administrator wants to use online migration features, and quite rightly so. Having the l exibility to
move virtual servers between host servers is often an operational necessity, so any concerns you may
have about SQL Server's reaction to being transparently relocated should be tested in order to gain
coni dence in the process. You might i nd that you agree to perform the task only at quiet periods,
or you might feel safe with the process irrespective of the workload.
Likewise, the virtualization administrator is also likely to want to use the vendor's high-availability
feature so that in the event of a physical host server failure, the virtual servers are automatically
restarted elsewhere. This is where you need to carefully consider your approach, if any, to making a
specii c instance of SQL Server highly available. My advice is not to mix the different high-availability
technologies available at each layer of the technology stack. This is because when a failure occurs,
Search WWH ::
Custom Search