Storage Systems - SQL Server 2012 Internals and Troubleshooting - page 93

Several storage vendors combine point-in-time technology with remote replication. These features
enable the administrator to take a clone or snapshot of the user databases (using VDI to create an
application-consistent data copy if desired) and send the data to a remote array.
As with asynchronous replication, point-in-time remote replication offers the advantage of low
server impact. Remotely sending a snapshot enables you to specii cally control the potential for data
loss. If you set the snap interval for i ve minutes, you can be reasonably certain that in the event of
unplanned failure you will lose no more than i ve minutes of changes. Identifying an exact amount
of expected data loss can offer huge advantages when negotiating the parameters of BCDR with the
business.
Windows Failover Clustering
Many SQL Server installations utilize Windows Failover Clustering to form high-availability SQL
Server clusters. These systems create a virtual SQL Server that is hosted by an active server and
at least one passive server. SQL Server 2008 and 2008 R2 failover clusters supported only shared
storage failover clustering. The SAN storage array allows all SQL Server clusters to access the same
physical storage and move that storage between nodes.
SQL Server failover clusters are based on the concept of “shared nothing”; the SQL Server instance
(or instances) can live on only one active server. SQL Server places an active lock on log and data
i les, preventing other servers or programs from accessing the i les. This is incorporated to prevent
data changes that SQL Server would have no way to detect. In addition to i le locks, the failover
cluster also actively prevents other systems from using the storage volumes by using SCSI reservation
commands.
Failover clustering can be set to automatically fail the instance over to a standby server when a failure
occurs. SQL Server failover clusters also support the use of geo-clustering . A geo-cluster uses stor-
age replication to ensure that remote data is in-sync with the source data. Storage vendors provide
a proprietary cluster resource dynamic link library (DLL) that facilitates cluster-to-storage-array
communication.
The use of a resource DLL enables a rapid failover between sites with little or no administrator
involvement. Traditional failover systems require the interaction of many teams. Returning to our
example, assume that Widget Company has just implemented a local SQL Server with a remote
failover system.
The system in use by Widget uses traditional storage replication. When the Widget DBAs try to
execute a failover they i rst need to contact the storage administrators so they can run failover
scripts on the storage arrays. Once the storage is failed to the remote site, the DBAs can bring
the database online. Because the server name is different, the DBAs need to reconi gure the data-
base to do that. Now the application owners need to point all the middle-tier systems to the new
server.
Even when the failover is planned it is extremely resource intensive to implement. The use of a geo-
cluster greatly simplii es the failover process. The failover is implemented automatically whenever
the SQL Server geo-cluster is failed over to a remote node. Unfortunately, SQL Server 2008 and
2008R2 only supported geo-clustering when both servers shared the same IP subnet.