Designate Alarm Manager Server(s) for a Remote Application

You can designate a workstation other than the primary configuration server to manage the Alarm Manager's tasks.

In a remote application, the Alarm Manager can be configured to run on a workstation other than the primary configuration server. As described in the topic Primary Service Servers, it is prudent to spread services out over several different workstations to avoid down time in the event of a server failure.

The Alarm Manager runs as a server on one workstation and as a client on the other workstations in the system.

It is recommended that at least two servers be arranged: one as the primary Alarm Manager server; the other as a backup server in case the primary Alarm Manager server fails. The servers you choose must be added to the Config.ini configuration file under the [ALARMMANAGER–Servers] section. Workstations not specified as Alarm Manager servers will act as clients.

The following example demonstrates the correct way to configure the Config.ini file when designating servers to manage the Alarm Manager for the application.

Config.INI

[ALARMMANAGER-Servers]

Name = SAMPSON

Name = JAMES

 

In this example, the results will be that workstation "SAMPSON" will be the primary Alarm Manager server, while "JAMES" will be the backup Alarm Manager server; if "SAMPSON" should fail, "JAMES" will act as the primary Alarm Manager server.

It is strongly recommended that you specify the servers and clients by name rather than by IP address. This is particularly important in networks where workstations may be dual-homed, or where dynamic IPs are assigned.

The same configuration of the Config.ini file must be present on every workstation that is running the remote application.

Note: In larger remote applications with a number of workstations, it might be wise to configure the Config.ini file prior to adding the application to all of the workstations that will be running it. This way identical Config.ini files will get copied to each of the workstations when they receive all of the application files from the server during synchronization. In the case of a pre-existing application, you can use VTS's locking scheme to lock and update the Config.ini file, which also propagates the modified configuration file to all workstations running the application.

It should be noted here for developers accustomed to earlier versions of VTS that the name of the Alarm Manager service has changed from "Alarms" to "AlarmManager". Any section headers for entries in .ini files that are intended for the former Alarms service will have to be updated to reflect this change (e.g. [AlarmManager-Servers], not [Alarms-Servers]). Further, the custom configuration file for the Alarm Manager (AlarmManager.ini) was formerly called "Alarms.ini". Existing applications with an "Alarms.ini" configuration file will still work.

 

Topics in this section:

Alarm Manager and Synchronization