Cluster Server 7.4.2 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 Veritas InfoScale solutions for monitoring SQL Server
- About the VCS agents for SQL Server
- How VCS monitors storage components- Shared storage - if you use NetApp filers
- Shared storage - if you use SFW to manage cluster dynamic disk groups
- Shared storage - if you use Windows LDM to manage shared disks
- Non-shared storage - if you use SFW to manage dynamic disk groups
- Non-shared storage - if you use Windows LDM to manage local disks
- Non-shared storage - if you use VMware storage
 
- 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- About installing SQL Server for a high availability (HA) configuration
- Configuring Microsoft iSCSI initiator
- About installing SQL Server on the first system
- About installing SQL Server on additional systems
- Assigning ports for multiple SQL Server instances
- Enabling IPv6 support for the SQL Server Analysis Service
 
 
- 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- About configuring the SQL Server service group
- Before configuring the SQL Server service group
- Configuring a SQL Server service group using the wizard
- Configuring the service group in a non-shared storage environment
- Running SnapManager for SQL Server
- About the modifications required for tagged VLAN or teamed network
- 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- About the various interfaces available for performing application monitoring tasks
- Administering application monitoring using the Veritas High Availability tab- Understanding the Veritas High Availability tab work area
- To view the status of configured applications
- To configure or unconfigure application monitoring
- To start or stop applications
- To suspend or resume application monitoring
- To switch an application to another system
- To add or remove a failover system
- To clear Fault state
- To resolve a held-up operation
- To determine application state
- To remove all monitoring configurations
- To remove VCS cluster configurations
 
- Administering application monitoring settings
- Administering application availability using Veritas High Availability dashboard- Understanding the dashboard work area
- Monitoring applications across a data center
- Monitoring applications across an ESX cluster
- Searching for application instances by using filters
- Selecting multiple applications for batch operations
- Starting an application using the dashboard
- Stopping an application by using the dashboard
- Entering an application into maintenance mode
- Bringing an application out of maintenance mode
- Switching an application
 
 
 
- Section IV. Appendixes- Appendix A. Troubleshooting- VCS logging
- VCS Cluster Configuration Wizard (VCW) logs
- VCWsilent logs
- NetApp agents error messages
- Error and warning messages from VCS agent for SQL Server- Messages from the VCS agent for SQL Server Database Engine
- Messages from the VCS agent for SQL Server FILESTREAM
- Messages from the VCS agent for SQL Server Agent service and Analysis service
- SQL Server Analysis service (MSOLAP) service fails to come online with "invalid context of address" error
- Messages from the VCS agent for MSDTC
 
- Troubleshooting application monitoring configuration issues
- Troubleshooting Veritas High Availability view issues- Veritas High Availability tab not visible from a cluster node
- Veritas High Availability tab does not display the application monitoring status
- Veritas High Availabilitytab may freeze due to special characters in application display name
- Veritas High Availability view may fail to load or refresh
- Operating system commands to unmount resource may fail
 
 
- Appendix B. Using the virtual MMC viewer
 
- Appendix A. Troubleshooting
How the VMwareDisks agent communicates with the vCenter Server instead of the ESX/ESXi host
In addition to the ESX hosts the VMwareDisks agent can also communicate the disk deatch and attach operations with the vCenter Server to which the virtual machines belong.
In this scenario, in event of a failure, the VMwareDisks agent sends the disk detach and attach requests to the vCenter Server (instead of the ESX hosts). The vCenter Server then notifies the ESX host for these operations. Since the communication is directed through the vCenter Server, the agent successfully detaches and attaches the disks even if the ESX host and the virtual machines reside in a different network.
In a scenario where the host ESX/ESXi itself faults, the VMareDisks agent from the target virtual machine sends a request to the vCenter Server to detach the disks from the failed virtual machine. However, since the host ESX has faulted, the request to detach the disks fails. The VMwareDisks agent from the target virtual machine now sends the disk attach request. The vCenter Server then processes this request and disks are attached to the target virtual machine. The application availability is thus not affected.
See Modifying the ESXDetails attribute.
The configuration of VMwareDisks agent to communicate with the vCenter Server has the following limitation:
If VMHA is not enabled and the host ESX faults, then even after the disks are attached to the target virtual machine they remain attached to the failed virtual machine. This issue occurs because the request to detach the disks fails since the host ESX itself has faulted. The agent then sends the disk attach request to the vCenter Server and attaches the disks to the target virtual machine.
Even though the application availability is not impacted, the subsequent power ON of the faulted virtual machine fails. This issue occurs because of the stale link between the virtual machine and the disks attached. Even though the disks are now attached to the target virtual machine the stale link with the failed virtual machine still exists.
As a workaround, you must manually detach the disks from the failed virtual machine and then power ON the machine.
You must have the administrative privileges or must be a root user to communicate the disk detach and attach operations through the vCenter Server. If the vCenter Server user account fails to have the administrative privileges or is not a root user, then the disk detach and attach operation may fail, in event of a failure.
If you do not want to use the administrator user account or the root user, then you must create a role and add the following privileges to the created role:
- "Low level file operations" on datastore 
- "Add existing disk" on virtual machine 
- "Change resource" on virtual machine 
- "Remove disk" on virtual machine 
After you create a role and add the required privileges, you must add a local user to the created role. You can choose to add an existing user or create a new user.
Refer to the VMware product documentation for details on creating a role and adding a user to the created role.