InfoScale™ 9.0 Cluster Server Agent Developer's Guide - AIX, Linux, Solaris, Windows
- Introduction
- Agent entry point overview
- About agent entry points
- Agent entry points described
- About the action entry point
- About the info entry point
- Considerations for using C++ or script entry points
- About the agent information file
- About the ArgList and ArgListValues attributes
- Creating entry points in C++
- About creating entry points in C++
- Syntax for C++ entry points
- Agent framework primitives
- Agent Framework primitives for container support
- Creating entry points in scripts
- About creating entry points in scripts
- Syntax for script entry points
- Agent framework primitives
- VCSAG_GET_ATTR_VALUE
- Agent Framework primitives with container support
- Example script entry points
- Logging agent messages
- Building a custom agent
- Building a script based IMF-aware custom agent
- Creating XML file required for AMF plugins to do resource registration for online and offline state monitoring
- Testing agents
- Static type attributes
- About static attributes
- Static type attribute definitions
- AdvDbg
- ArgList
- State transition diagram
- Internationalized messages
- Troubleshooting VCS resource's unexpected behavior using First Failure Data Capture (FFDC)
- Appendix A. Using pre-5.0 VCS agents
Considerations for the application
The application for which an agent for VCS is developed must lend itself to being controlled by the agent and be able to operate in a cluster environment. The following criteria describe an application that can successfully operate in a cluster:
The application must be capable of being started by a defined procedure if new agent is of type OnOff or OnOnly. There must be some means of starting the application's external resources such as file systems that store databases, or IP addresses used for listener processes, and so on.
Each instance of an application must be capable of being stopped by a defined procedure if new agent is of type OnOff. Other instances of the application must not be affected.
The application must be capable of being stopped cleanly, by forcible means if necessary.
Each instance of an application must be capable of being monitored uniquely. Monitoring can be simple or in-depth so as to achieve a high level of confidence in the operation of the application. Monitoring an application becomes more effective when the monitoring procedure resembles the actual activity of the application's user.
For failover capability, the application must be capable of storing data on shared disks rather than locally or in memory, and each system must be capable of accessing the data and all information required to run the application.
The application must be crash-tolerant. It must be capable of being run on a system that crashes and of being started on a failover node in a known state. This typically means that data is regularly written to shared storage rather than stored in memory.
The application must be host-independent within a cluster; that is, there are no licensing requirements or host name dependencies that prevent successful failover.
The application must run properly with other applications in the cluster.
The applications configured under VCS control must not write data on stdout and stderr stream. This may interfere with VCS agent functionality. For such applications to run under VCS control, you must redirect the application's stdout and stderr stream.