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
Notes and recommendations
Note the following prerequisites before configuring application monitoring:
Verify that the boot sequence of the virtual machine is such that the boot disk (OS hard disk) is placed before the removable disks.
If the sequence places the removable disks before the boot disk, the virtual machine may not reboot after an application failover. The reboot may halt with an "OS not found" error.
This issue occurs because during the application failover the removable disks are detached from the current virtual machine and are attached on the failover target system.
Verify that VMware Tools is installed on the virtual machine.
Install the version that is similar to or later than that available with VMware ESX 4.1.
Verify that all the systems on which you want to configure application monitoring belong to the same domain.
Verify that the ESX/ESXi host user account has administrative privileges or is a root user.
If the ESX/ESXi user account fails to have the administrative privileges or is not a root user, then in event of a failure the disk deattach and attach operation may fail.
If you do not want to use the administrator user account or the root user, then you must create a role, add the required privileges to the created role and then add the ESX user to that role.
See Assigning privileges for non-administrator ESX/ESXi user account.
Verify that the SQL Server instances that you want to monitor are installed on the non-shared local disk that can be deported from the system and imported to another system.
If you have configured a firewall, ensure that your firewall settings allow access to ports used by Veritas High Availability installer, wizard, and services.
You must run the Veritas High Availability Configuration wizard from the system to which the disk residing on the shared datastore is attached (first system on which you installed SQL Server).
After configuring SQL Server databases for monitoring, if you create another database or service, then these new components are not monitored as part of the existing configuration.
In this case, you can either use the VCS commands to add the components to the configuration or unconfigure the existing configuration and then run the wizard again to configure the required components.
In case the VMwareDisks agent resource is configured manually, care should be taken not to add the operating system disk in the configuration. The VMwareDisks agent does not block this operation. This might lead to a system crash during failover.
If VMware vMotion is triggered at the same time as an application fails over, the VMwareDisks resource may either fail to go offline or may report an unknown status. The resource will eventually failover and report online after the vMotion is successful and the application is online on the target system.
VMware snapshot operations may fail if VMwareDisks agent is configured for a physical RDM type of disk. Currently only virtual RDM disks are supported.
Non-shared disks partitioned using GUID Partition Table (GPT) are not supported. Currently only Master Boot Record (MBR) partition is supported.
VMwareDisks agent does not support disks attached to the virtual machine using IDE controllers. The agent resource reports an unknown if IDE type of disks are configured.
In case VMware HA is disabled and the ESX itself faults, VCS moves the application to the target failover system on another ESX host. VMwareDisks agent registers the faulted system on the new ESX host. When you try to power on the faulted system, you may see the following message in the vSphere Client:
This virtual machine might have been moved or copied. In order to configure certain management and networking features, VMware ESX needs to know if this virtual machine was moved or copied. If you don't know, answer "I copied it".
You must select "I moved it" (instead of the default "I copied it") on this message prompt.
You must not restore a snapshot on a virtual machine where an application is currently online, if the snapshot was taken when the application was offline on that virtual machine. Doing this may cause an unwanted fail over.
This also applies in the reverse scenario; you should not restore a snapshot where the application was online on a virtual machine, where the application is currently offline. This may lead to a misconfiguration where the application is online on multiple systems simultaneously.
If you want to suspend a system on which an application is currently online, then you must first switch the application to a failover target system.
If you suspend the system without switching the application, then VCS moves the disks along with the application to another system.
Later, when you try to restore the suspended system, VMware does not allow the operation because the disks that were attached before the system was suspended are no longer with the system.
While creating a VCS cluster in a virtual environment, you must configure one of the cluster communication link over a public adapter in addition to the link configured over a private adapter. To have less VCS cluster communication over the link using the public adapter, you may assign it low priority. This keeps the VCS cluster communication intact even if the private network adapters fail. If the cluster communication is configured over the private adapters only, the cluster systems may fail to communicate with each other in case of network failure. In this scenario, each system considers that the other system has faulted, and then try to gain access to the disks, thereby leading to an application fault.
VMware Fault Tolerance does not support adding or removing of non-shared disks between virtual machines. During a failover, disks that contain application data cannot be moved to alternate failover systems. Applications that are being monitored thus cannot be brought online on the failover systems.
For cluster communication, you must not select the teamed network adapter or the independently listed adapters that are a part of the teamed NIC.
A teamed network adapter is a logical NIC, formed by grouping several physical NICs together. All NICs in a team have an identical MAC address, due to which you may experience the following issues:
The application monitoring configuration wizard may fail to discover the specified network adapters
The application monitoring configuration wizard may fail to discover/validate the specified system name