Database Reference
In-Depth Information
Note
For more information on the availability modes for SQL Server AlwaysOn
AGs, read http://technet.microsoft.com/en-us/library/ff877931.aspx .
SQL Server AlwaysOn AGs support an Availability Group Listener (that is, a DNS
name and IP address) for each Availability Group. Point clients to the AG Listener for
them to access your SQL Server AG implementation, and the AG Listener will direct
them to the appropriate replica. The AG Listener is responsible for redirecting requests
when a SQL Server participating in a SQL Server AG is no longer available.
So what does a SQL Server AG implementation look like on vSphere? Pretty much any
way you want it to look. Whereas a SQL Server FCI uses a shared SCSI bus, a SQL
Server AG does not, which frees us from the tyranny of the shared SCSI bus. Because
the shared SCSI bus is not a factor, VMware will support the use of VMDK files,
vMotion, DRS, Storage vMotion, Storage DRS, Enhanced vMotion, vSphere HA, and
other features. In short, this is a great stack on which to run your mission-critical SQL
Server databases.
For the most current, up-to-date information on what is supported by VMware for SQL
Server AlwaysOn AGs, reference http://kb.vmware.com/kb/1037959 and review the
“Non-Shared Disk and SQL AlwaysOn AG” section in the link.
Putting Together Your High Availability Solution
Now that we have reviewed the features available within the vSphere platform and
those provided by Microsoft with SQL Server, it is time to have availability
discussions with the appropriate teams. We have found education is the key. vSphere
administrators do not know all the intricacies involved with maintaining a healthy,
highly available, disaster-resilient SQL Server. And DBAs are unaware of the plethora
of features available within the vSphere platform and how they enhance a SQL Server
implementation. Cross-education between groups is essential. Once these teams agree
upon a strategy, remember that both teams need to support the SLA. It is now time to put
together the menu for your end users. Table 9.2 provides an example of what your offer
sheet might look like. Put something down in writing that everyone can agree upon prior
to talking with the application owners and then share the document with them. This way,
everyone is working from the same document and there are no misunderstandings about
the services provided and the service levels associated with these services.
 
 
Search WWH ::




Custom Search