Reference Guide

1) Create controller team: Using the teaming interfaces, a team of controllers need to be defined
for leveraging High Availability features.
2) Create Region: the network devices for which the given controller has been identified as a
master are grouped into “regions”. This grouping is defined in the HP VAN SDN Controller
using the Region interface detailed in subsequent sections.
Once the region definition(s) are in place, the ROS would take care of ensuring that a master
controller is always available to the respective network element(s) even when the configured master
experiences a failure or there is effectively a disruption of the communication channel between the
controller and the network device(s).
Failover: ROS would trigger the failover operation in two situations:
1) Controller failure: The ROS detects the failure of a controller in a team via notifications from
the teaming subsystem. If the ROS determines that the failed controller instance was master to
any region, it would immediately elect one of the backup (slave) controllers to assume the
mastership over the affected region.
2) Device disconnect: The ROS instance in a controller would get notified of a communication
failure with network device(s) via the Controller Service notifications. It would instantly federate
with all ROS instances in the team to determine if the network device(s) in question are still
connected to any of the backup (slave) controllers within the team. If that is the case, it would
elect one of the slaves to assume mastership over the affected network device(s).
Failback: When the configured master recovers from a failure and joins the team again, or when
the connection from the disconnected device(s) with the original master is resumed, ROS would
initiate a failback operation i.e. the mastership is restored back to the configured master as defined
in the region definition.
ROS exposes API’s through which interested applications can:
1) Create, delete or update a region definition
2) Determine the current master for a given device identified by a datapathId or IP address
3) Determine the slave(s) for a given device identified by a datapathId or IP address
4) Determine if the local controller is a master to a given device identified by a datapath
5) Determine the set of devices that a given controller is playing the master or slave role.
6) Register for region and role change notifications.
Details of the RegionService and RoleService APIs may be found at the Javadocs provided with the
SDK. See Javadoc on page 9 for details.
Illustrative usages of Role Service API’s
- To determine the controller which is currently playing the role of Master to a given datapath,
applications can use the following API’s depending on the specific need:
import com.hp.sdn.adm.role.RoleService;
import com.hp.sdn.adm.system.SystemInforamationService;
…
public class SampleService {
// Mandatory dependency.
private final SystemInformationService sysInfoService;
24