Cluster Server 8.0 Implementation Guide for Microsoft SQL Server - Windows
- Section I. Introducing Veritas InfoScale solutions for application high availability
- Understanding the InfoScale solutions for application high availability
- About the VCS agents for SQL Server
- How VCS monitors storage components
- How application availability is achieved in a physical environment
- How is application availability achieved in a VMware virtual environment
- Managing storage and installing the VCS agents
- Installing SQL Server
- Understanding the InfoScale solutions for application high availability
- Section II. Configuring SQL Server in a physical environment
- Overview
- Configuring the VCS cluster
- Configuring the SQL Server service group
- Configuring a SQL Server service group using the wizard
- Making SQL Server user-defined databases highly available
- Verifying the service group configuration
- Administering a SQL Server service group
- Configuring an MSDTC service group
- Configuring the standalone SQL Server
- Configuring an Active/Active cluster
- Configuring a disaster recovery setup
- Section III. Configuring SQL Server in a VMware environment
- Configuring application monitoring using the Veritas High Availability solution
- Administering application monitoring
- Administering application monitoring using the Veritas High Availability tab
- Administering application availability using Veritas High Availability dashboard
- Understanding the dashboard work area
- Section IV. Appendixes
- Appendix A. Troubleshooting
- Error and warning messages from VCS agent for SQL Server
- Troubleshooting application monitoring configuration issues
- Troubleshooting Veritas High Availability view issues
- Appendix B. Using the virtual MMC viewer
- Appendix A. Troubleshooting
Typical SQL Server disaster recovery cluster configuration
A Disaster Recovery (DR) configuration enables you to restore application data and services in the event of a catastrophic failure. A typical DR solution requires primary and secondary sites, and clusters within those sites. The clusters at the primary and secondary sites are a part of the global cluster. The cluster at the primary site provides data and services during normal operation, and the cluster at the secondary site provides data and services if the primary site fails. VCS continuously monitors and communicates events between clusters. Inter-cluster communication ensures that the global cluster is aware of the state of the global service group at all times.
The illustration displays an environment with a DR solution that is prepared for a disaster. The primary site consists of two nodes, System1 and System2. The secondary site consists of two nodes, System3 and System4. Each site has a clustered setup with the nodes set up appropriately for failover within the site.
Note:
The figure depicts a typical configuration. The number of systems at the primary and secondary site clusters need not be the same.
Data is replicated from the primary site to the secondary site. Replication between the storage is set up using a replication software. In case of a NetApp environment, replication between the filers at the primary and secondary sites is set up using NetApp SnapMirror for SQL. If the Microsoft SQL Server server on System1 fails, SQL Server comes online on node System2 and begins servicing requests. From the user's perspective there might be a small delay as the backup node comes online, but the interruption in effective service is minimal.
When a failure occurs, such as an earthquake that destroys the data center in which the primary site resides, the DR solution is activated. VCS fails over the entire service group to the cluster at the secondary site. System3 at the secondary site takes over, and the data that was replicated to the secondary site is used to restore the application services to clients.