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

This networking technology is called a stretch virtual local area network , or stretch VLAN . The
stretch VLAN often requires that network engineers implement complex networking technologies.
SQL Server 2012 solves this through AlwaysOn Failover Cluster Instances. This new feature enables
each SQL Server to utilize an IP address that is not tied to the same IP subnet as the other hosts.
NOTE Multi-subnet SQL Server failover cluster network names enable the
RegisterAllProvidersIP property. This provides all the IP addresses that SQL
Server is coni gured to use. It is important that newer SQL Server client drivers
(such as the SQL Server Native Client) be utilized, as they support this coni gura-
tion. The use of older SQL Server client drivers requires advanced coni guration.
SQL Server AlwaysOn Availability Groups
The coni guration and setup of AlwaysOn Availability Groups is beyond the scope of this chapter.
From a storage perspective, Availability Groups offer a new, server-based method for replicating
data that is application centric rather than platform centric. As discussed earlier, storage systems can
use point-in-time data copies to facilitate data backup and performance isolation. Deciding between
application based failover and hardware based failover is an architecture choice.
Earlier versions of SQL Server utilized log shipping, and later SQL Server mirroring, to keep standby
SQL Servers updated with information. In the case of both log shipping and storage replication, the
remote database must be taken ofl ine prior to data synchronization. Availability Groups enable the
use of near-real-time readable secondary database servers.
The read-only data copy can facilitate reporting ofl oad or even backup. In addition, Availability
Groups support synchronous or asynchronous data replication and also multiple secondary servers.
You can coni gure one secondary as a reporting system that is hosted locally, and a second server
can be hosted remotely, thus providing remote BCDR.
From a storage perspective, note the following caveats: Each remote secondary server needs as much
storage capacity (and usually performance) as the primary database. In addition, it is critical that
your network infrastructure is designed to handle the increased network trafi c that can be gener-
ated by replicating data locally and remotely. Finally, all your servers must have enough perfor-
mance available to handle the replication. If your server is already processor, storage, or memory
bound, you are going to make these conditions worse. In these cases it is often advantageous to
enable storage-based replication. Think of AlwaysOn Availability Groups as a powerful new tool
that now enhances your SQL Server toolkit.
Risk Mitigation Planning
All of the replication and backup technologies described here are designed to mitigate risk. To prop-
erly dei ne the specii c procedures and technologies that will be used in your BCDR strategy, you
need to decide how soon you need the system online and how much data your business is willing to
lose in the process.