For greater resiliency, each instance of the interface software can communicate with two Operations Sentinel servers at the same time. The first Operations Sentinel server to connect with the interface software is the primary server; the second Operations Sentinel server to connect is the secondary server.
The interface software employs dynamic port assignment using MCP port subfiles, whereby two parallel message streams may be sent to two separate Operations Sentinel servers. These two port subfiles are established in LISTEN mode.
In a resilient primary and secondary Operations Sentinel environment, the first Operations Sentinel server to make a connection to the configured port number receives a working service port (subfile) and is designated as the primary Operations Sentinel server. The interface software recognizes a subsequent connection attempt and the second subfile is allocated to the secondary Operations Sentinel server.
If the Interface software detects that the primary Operations Sentinel server has disconnected for any reason, it will close the primary connection, promote the secondary server to primary, open a new subport, and wait for a new connection from a server.
The following scenarios can apply in an environment with primary and secondary Operations Sentinel Servers:
By using the same SP-AMS database and Operations Sentinel configuration, a secondary Operations Sentinel server will run the same displays and produce the same logs as the primary Operations Sentinel server. In addition, the SPAMS automation environment, including dynamic variables, are always current (except during the short delay of switchover).
The interface software only submits commands to the MCP from the primary Operations Sentinel server. If both servers’ SP-AMS databases react to a host output message by sending a command to the host, only the command from the primary server is accepted.
Note: External alarms and cross-system automation require particular attention when both primary and secondary Operations Sentinel servers are connected to the interface software. You must ensure that external alarms are not duplicated and that cross-system automation commands are submitted only from the primary Operations Sentinel server.
The interface software processes Operations Sentinel initialization commands from both the primary and secondary Operations Sentinel servers so that Status initialization is provided whenever either server connects with the interface.
By running different configurations on each Operations Sentinel server, you can distribute control of the managed MCP systems between both Operations Sentinel servers. You control the desired primary/secondary association of Operations Sentinel servers to systems through selective enabling of monitoring and logging. If the primary Operations Sentinel server goes down, the secondary Operations Sentinel server assumes primary control of all systems defined in its configuration.
Both the primary and secondary Operations Sentinel servers have unrestricted ODT terminal access to systems in their respective configurations, regardless of whether they are designated as primary or secondary.
You can use the SWITCH PRIMARY and CLEAR PRIMARY commands to control which Operations Sentinel server is treated as the primary server.
For more information on resilient Operations Sentinel environments, see the Operations Sentinel Administration and Configuration Guide.