Configuring Hot Backup

Backup Settings

To access the backup settings pane, click Backup Settings, under the Server section in the ISM

In the Backup Settings page, provide a value for the Location of Backup field with the host name and port number of the ISM that is monitoring this instance of ISM.

ISM can be deployed to automatically fail over to another waiting machine usually referred to as a "hot backup" host. Simple fail over relies on iWay's native functionality to emit and respond to "heartbeat" messages which signify normal operation of the primary server. More sophisticated backup can be configured through the Backup Extension on the backup server.

Using the Backup Settings page, provide a value for the Location of Backup field with the host name and port number of the ISM that is monitoring this instance of ISM, as shown in the following image.

The following table lists and describes the parameters that are found in the Backup Settings page:

Parameter	Description
Location of backup	Location of the live system failover partner. This is the server that would be monitoring the iway server. Specify as host:port to which heartbeat signals are sent. The port should match the port on the backup listener configured on the system which is monitoring this server.
Heartbeat port	The port to listen on for the live system heartbeat. This entry applies only when operating in backup (-b) mode.
Threshold	Period for backup to tolerate no heartbeat. This entry applies only when operating in backup (-b) mode.

In this example, this ISM is being monitored by a computer named otherbox on port 1559. Do not fill in the other fields since these fields are not considered for the backup extension which is being explained here. These fields instruct the ISM that it is a full backup, and prevents any processing until a monitored signal on the heartbeat port detects a failure. This means that distributed backup cannot operate on a computer that is monitoring for full backup.

While the ISM is operating, a heartbeat is sent to the backup ISM. In this case it is sent to otherbox.

Configuring the Backup Listener

The backup listener on the otherbox machine performs the task of monitoring the iWay server, serverA. To participate in distributed backup, a backup listener needs to be added and configured. The listener properties are explained below:

Property Name	Property Type	Property Description
Port*	integer	Port(socket) number on which messages are exchanged. This needs to be the same as the one set under host:port under backup settings.
Local Bind Address	string	Local bind address for multi-homed hosts: usually leave empty. Note: The Local bind Address is used for multiple homed networks, and is not further considered here.
Threshold	integer	Period (seconds) for backup to tolerate no heartbeat. For instance, if the heartbeat were set to 6 (seconds), then the listener would wait for 6 seconds to generate a signal say, DEAD if the server did not return any response (heartbeat). The default is 60 seconds. The time needs to be set as per the network speed requirements. Refer Notes below.
Whitespace Normalization	choice	Specifies how the parser treats white spaces in Element content. Choose preserve to turn off all normalization as prescribed by the XML Specification. Choose condense to remove extra white spaces in pretty printed documents and for compatibility with earlier versions. Note: This parameter is available only in iSM 6.x or higher.
Record in Activity Log(s)	boolean	If set, activity on this channel will be recorded in the activity logs, else the activity will not be recorded. Note: This parameter is present only in 6.x or higher.

Note: A hear tbeat is generated every tenth of a second by the monitored ISM and sent to the monitoring server. When the server being monitored does not send a heartbeat, even after the period specified by the 'Threshold' value, the monitoring server sends a final message to reconfirm that the server being monitored is 'DEAD'. In the event of not receiving a response, the monitoring server determines that the server is 'DEAD' and generates a message accordingly.

The listener generates messages that can be handled by a normal ISM workflow or workflows of varying complexity. The dispatched messages are in XML, and take the form:

<signal>state</signal>

where

state: Can be LIVE, DEAD, or CLOSE.

The following table describes each state in more detail.

State	Description
LIVE	The monitored ISM has gone live. This message appears when the monitored ISM resumes or begins operation. If the monitoring ISM starts first, this message will be dispatched when the monitored ISM starts.
DEAD	The monitored ISM has not sent a heartbeat for the threshold duration, and the monitored ISM was previously in LIVE state.
CLOSE	The monitored ISM has signaled that it is terminating normally. If it restarts you will receive a LIVE message. Once a monitored ISM signals CLOSE, missed heartbeats are ignored: heartbeats are monitored only when the monitored ISM is in LIVE state.

The dispatched messages are used to process the signals coming from the monitored iWay server. This can be done by:

Using the control agent (XDControlAgent) your workflow can post internal messages to start or stop other named listeners on the monitoring server. In this manner the monitoring ISM controls the startup and shut down of listeners on its own server as the state of the ISM being monitored changes. The agent accepts a list of configured listener names and posts a start or stop message, as selected in the Action parameter.
Using an email emit agent to send email notifications when the server comes down or starts up.

You are not limited to using the control agent. Any form of messaging system that can alert a manager about a change in status or request to perform specific actions will suffice.

Selecting the appropriate action to take based on the dispatched message(s) is accomplished by standard ISM routing and switching control, based on an analysis of the incoming message.

Top of page

Procedure: How to Create a Backup Listener

To create a Backup listener:

Start the ISM.
Once the ISM is open, click Registry in the top frame. The Registry section is displayed.
Under the Components section on the left side, select Listeners. The Listeners pane is displayed.
Click Add, to add a new listener.
Select the listener type BACKUP from the drop-down list, as shown in the following image.

Configuration parameters for the listener are displayed.
Fill in the properties according to the information below and click Next, as shown in the image below.
Port*: 1559

Local blind address: Leave this empty

Threshold: 60

Whitespace Normalization: preserve

Record in Activity*: true
Enter the name of the listener as “Backup” and leave description empty.
Click Finish to create the listener. The backup listener is created.

Procedure: How to Configure the Backup Listener Channel and the System Being Backed Up

This example will illustrate how a backup listener monitors a system.

Construct an inlet consisting of a backup listener on the machine which is performing the backup. Let the backup listener be configured on the machine which is performing the backup.
Construct a process flow which consists of a QAAgent configured with the properties in the following image.
Add the process flow, QAprocess, to a route called QAroute, as shown in the following image.
Construct a channel called testbackup, which consists of the inlet QAroute and a default outlet.
Build and deploy the channel.
Start the channel.
Let ServerA be the machine which needs to be backed up.
Stop ServerA then Start it from the command line.
Restart the server using the “restart” link in the ISM console.
The channel testbackup on the server that is taking the backup, otherpc, processes a message upon server stop and processes another message when the server is started up. The parameters of the messages exchanged can be viewed using the trace files created by the QAAgent. The following entries in the files created by the QAAgent say, out_trace1.txt and out_trace2.txt show the signal state:
```
<?xml version="1.0" encoding="UTF-8" ?><debug>Out_trace.txt
<document> <signal errors="0">CLOSE</signal> </document> 
<?xml version="1.0" encoding="UTF-8" ?><debug>Out_trace.txt 
<document> <signal errors="0">LIVE</signal> </document> 
```
The message can also be processed using xpath(/signal) as described in the next section. Similarly, the channel processes messages when the 'restart' option is clicked from console.