Database Reference
In-Depth Information
Servers.
When it comes to critical databases that support the business and business operations,
we have historically seen these implemented on SQL Server clusters. As new
technologies and solutions enter the market, by both Microsoft and other vendors such
as VMware, we will see a shift from this technology to others.
When a purely physical implementation of SQL Server AlwaysOn FCI is being run, one
variable that is often missed or not considered is the time it takes to replace the failed
hardware. When the underlying hardware fails, SQL Server AlwaysOn FCI will detect
this failure and restart the services on the standby node. However, at this point, the SQL
Server database hosting the business's most critical workloads now has two single
points of failure: the first being the shared storage, and the second being the hardware it
is running on. So the question to ask is, how long will it take to replace the physical
hardware, install, configure, and patch the Windows operating system, and then install,
configure, and patch the standby node of SQL Server? From our travels, the best any
customer has ever said is six hours, with hardware onsite. Not having hardware onsite
is a different story, and the vast majority of customers do not have standby servers.
When you virtualize SQL Server AlwaysOn FCI, you get the best of both worlds. SQL
Server protects the application and provides rolling patch upgrade capabilities.
vSphere HA watches and protects against hardware failure. How does this work? In a
virtualized implementation of SQL Server AlwaysOn FCI, when there is a hardware
failure, SQL Server AlwaysOn FCI will transfer services to the standby node and
resume servicing requests, exactly the same as it would in the physical world. vSphere
HA will detect the hardware failure and reboot the downed SQL Server on another
node in the vSphere cluster. The virtual machine will boot, Windows will start, and
SQL Server will initialize and reestablish quorum. Your database is protected once
again, in the time it takes vSphere to detect the hardware failure and reboot the virtual
machine. Protection is reestablished in minutes versus hours.
Although this may seem like a panacea, you must consider operational overhead when
implementing SQL Server AlwaysOn FCI on vSphere. The first is a firm requirement by
VMware to use raw device mappings, or RDMs, when doing SQL Server AlwaysOn
FCI between ESXi hosts.
SQL Server AlwaysOn FCI uses a shared SCSI bus between the virtual machines.
Because of this, there are certain actions that cannot be performed on these virtual
machines. Anything that involves a hot change to the virtual machine can disrupt the
heartbeat between virtual machines and will cause a node to failover. Some of these
actions include the following:
vMotion migration
Hot memory add
