Sample Application | Configuration for the Sample Application |
|
|
In the active application:
1.Invoke the HA state handling callback function
2.Increment the counter and write it to the local checkpoint
3.Start the AMF initiated health check (as a result, the health check callbacks are dispatched by AMF periodically)
4.Stop responding to the health check after certain number of health checks
5.Send an error report with "component failover" as the recommended recovery
In the standby application:
1.Read the local checkpoint and update the counter value when standby assignment happens
2.Each update to the local checkpoint by the active results in a callback to the standby
3.Start tracking the protection group associated with the assigned CSI
4.Start and stop passive monitoring of the component
When the active application sends an error report, the standby application receives the active assignment
The new active application resumes incrementing the counter value
The new active application receives the protection group callback and stops tracking this protection group.
The previous active application is terminated
A new application is instantiated (as a part of repair)
The new active component then unregisters and finalizes with AMF
A.2 Configuration for the Sample Application
The configuration for the sample application is captured in the System Description File. It comprises of the following entities:
zA service group (SG) that comprises 2 service units (SU) in a
zA single service instance (SI) is configured to be assigned to the SG
zThe two SUs come up in the payload nodes (safNode=PL_2_3 and safNode=PL_2_4 respectively).
The sample application also provides scripts (available in /opt/motorola/ncs/dev/source/avsv directory on the development host) to control the component life cycle. These are:
zcomp_inst.sh script (to instantiate the sample application)
zcomp_term.sh script (to terminate the sample application).
36 | Availability Service Programmer’s Reference (6806800C44B) |
