Cluster Server 8.0 Configuration Guide for SAP Web Application Server - Windows
- Section I. Getting Started
- Introducing the Veritas High Availability Agent for SAP Web Application Server
- About the Veritas High Availability agent for SAP Web Application Server
- How does the Veritas High Availability solution work
- Agent functions
- Installing and configuring the SAP Web Application Server for high availability
- Setting up SAP systems for clustering
- Configuring the Enqueue Replication Server
- Clustering an SAP instance
- Introducing the Veritas High Availability Agent for SAP Web Application Server
- Section II. Configuring the application for high availability
- Section III. Troubleshooting the Agent
- Troubleshooting the agent for SAP Web Application Server
- Troubleshooting common problems
- Reviewing SAP Web Application Server agent log files
- Reviewing error log files
- Troubleshooting the agent for SAP Web Application Server
- Appendix A. Sample Configurations
About configuring application monitoring with Veritas High Availability solution for VMware
Consider the following before you proceed:
You can configure application monitoring on a virtual machine using the Veritas High Availability Configuration Wizard for VMware. The wizard is launched when you click
on the Veritas High Availability tab in VMware vSphere Client.Apart from the Veritas High Availability Configuration Wizard, you can also configure application monitoring using the Cluster Server (VCS) commands. For more information, refer to the Cluster Server Administrator's Guide.
Veritas recommends that you first configure application monitoring using the wizard before using VCS commands to add additional components or modify the existing configuration.
Apart from the application monitoring configuration, the wizard also sets up the other components required for successful application monitoring.
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:
SSO configuration failure
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