Use this Knowledge Script to discover clustered applications on physical computers and virtual machines. This script also discovers the cluster alias and adds it as a top-level resource object. This script facilitates monitoring of clustered applications. It removes the need to run the SetResourceDependency Knowledge Script or run multiple jobs on each clustered node per instance of the application. Also, application failovers are not required to discover servers on each node.
Although virtual servers are viewed and monitored as objects, features such as pinging the physical computer are not available. Other settings such as maintenance mode, custom server properties and security information storage are not applicable for virtual servers.
NOTE:The terms 'node' and 'cluster node' are similar to 'agent computer' or 'computer upon which the Microsoft Cluster service is running and where you will install the AppManager agent software for monitoring.
To install AppManager components for discovery of cluster resources:
Create a server object in the TreeView pane for each cluster node. For example, create a server object for an AppManager agent computer.
NOTE:Leave the option for discovering Windows components deselected.
Create a server group in the TreeView pane and move each newly created cluster node server object into that server group.
Install the AppManager agent software on each cluster node.
Install the following modules, which are required for monitoring, on each cluster node:
AppManager for Microsoft Windows (WinOS) module. Automatic discovery is enabled for this module, so it will run by default at the end of its installation.
Microsoft Cluster Service (MSCS) module. Then, run a Discovery_MSCS job on each cluster node in the TreeView pane.
Other cluster-aware modules (Microsoft Exchange2007, Microsoft SQL Server) and any other modules that you need to have monitored.
Run Discovery for the following cluster resources:
Run a Discovery_Cluster job on an active node in the cluster to identify the virtual server that the node is a part of and create a virtual Windows server in the console’s server group. Any Microsoft SQL or Microsoft Exchange virtual servers discovered will be added to the console’s server group.
Run a Discovery_NT job on the Windows virtual server. The discovery job will determine the owner of the "network name" resource and only run on that node to determine the shared disks used across the cluster.
IMPORTANT:Some shared disks used by the cluster nodes, including those mounted to remote computers, cannot be found at times because available programming interfaces do not show that information. These disks can still be monitored with the NT_DiskSpace Knowledge Script.
Run a Discovery_SQL job against any Microsoft SQL Server virtual servers previously discovered and added to the server group.
Run a Discovery_Exchange2007 job against any Microsoft Exchange virtual servers previously discovered and added to the server group.
Run the Discovery Knowledge Scripts for other modules, as needed. For those that have their own active and passive cluster resources, ensure the Discovery job runs on active nodes, then failover the resources to the other nodes and run another Discovery job to the now-active nodes.
Considerations for monitoring cluster resources:
Only shared physical and logical disks that can be identified appropriately are discovered by Discovery_NT under the Windows virtual server object. Local disks are discovered when Discovery_NT runs on a physical agent computer in the TreeView pane.
For AppManager modules that are not fully cluster-aware (those other than Microsoft SQL Server and Exchange 2007), you must use the AMAdmin_SetResDependency Knowledge Script to control when to run a monitoring job on a given node. Use this Knowledge Script to identify a resource that is active when the node is active in the cluster.
When a job is created on a Windows virtual server object, Microsoft SQL Server virtual server object, or Microsoft Exchange virtual server object in the TreeView pane, child jobs will appear to be running on each node in the cluster as well as the virtual server. However, the job will apply data and events only to the virtual server child job.
To correctly discover and monitor a Microsoft cluster, this Knowledge Script requires local Administrator access to each node of the Microsoft cluster. To do this, run the netiq service as a domain user account and a member of the local Administrator group on each member of the cluster. Without this access, the discovery fails because it relies on the Microsoft Cluster API to properly access cluster resources.
The Cluster Administrator can be used to administer a cluster, provided the account you are using has the required permissions and group memberships. The local Administrator account and local system account always have access to the cluster. You can use another account to administer a cluster with Cluster Administrator if the following requirements are true:
The account has permission to administer the cluster. You must use Cluster Administrator to assign permissions, not Windows Group Administrator.
The account is a domain account, which is a member of the local Administrators group.
The account is a member of the local Administrators group on each node of the cluster.
The account can be a member of other groups, such as global groups, as long as it is a domain account.
The Discovery_Cluster script will only generate events if the Raise event if condition occurs option on the Advanced tab for the Discovery_Cluster script is set to raise an event one time within one job iteration.
By default, this Knowledge Script raises an event when discovery fails.
Use the Discovery_NT Knowledge Script to discover Microsoft Windows resources on the server you want to monitor before you discover clustered applications.
If you delete or add a resource object, or if you make any other kind of change that might affect the monitoring of your resources, run both the Discovery_NT Knowledge Script and the Discovery_Cluster Knowledge Script again to update your list of resource objects. In addition, if you are running this module on AppManager 8 or higher, you can use the delta discovery feature in Control Center to run discovery on a schedule to more quickly detect changes to your environment.
Microsoft Clustered Servers
By default, this script is run once for each server.
Set the following parameters as needed:
|
Parameter |
How to Set It |
|---|---|
|
Raise event when discovery succeeds? |
Set to y to raise an event when the job succeeds in discovering clustered resources. The default is n. |
|
Event severity when discovery succeeds |
Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery succeeds. The default is 25. |
|
Event severity when discovery fails |
Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery fails for any reason. The default is 5. |
|
Event severity when discovery partially succeeds |
Set the event severity level, from 1 to 40, to reflect the importance of an event in which discovery returns some data but also generates warning messages. The default is 10. |
|
Event severity when discovery is not applicable |
Set the event severity level, from 1 to 40, to reflect the importance of an event when discovery is not applicable, such as a situation in which there are no clustered applications on the servers on which you run this script. The default is 15. |