A resilient configuration consists of a primary controller and secondary controller that are programmed with resilient devices. In the event of a primary controller failure, the resilient devices on the primary controller fail over to the secondary controller. SDS shares the user and device data between the databases of the primary and secondary controllers. Therefore, when a device fails over to the secondary, the user's feature keys and most phone settings will remain unchanged.
When you perform a Data Migration or Data Repair operation, SDS synchronizes the user and device data for the resilient devices between the databases of the primary and secondary controllers.
You always synchronize data from the local, master controller to a remote, slave controller. Because user and device data is synchronized between resilient pairs, one of the controllers is the primary controller for the devices, the other is the secondary controller. Typically, the master is the primary controller and the slave is the secondary controller. However, you can also perform a synchronization where the master is the secondary controller and the slave is the primary controller.
When you perform a synchronization of user and device data between a resilient pair of controllers, you also apply one of the following synchronization policies:
Only Synchronize data where <local element> is the PRIMARY host for resilient devices, or
Synchronize data where <local element> is the PRIMARY and SECONDARY host for resilient devices
In Example 1, if you log into Controller A and perform a synchronization operation to Controller B with the resilient user-device synchronization policy set to "Only Synchronize data where <local element> is the PRIMARY host for resilient devices", SDS writes the selected user and device data from Controller A (Master) to Controller B (Slave) for DN 1000 and DN 2000. It will not write the changes for DN 3000 or DN 4000 because Controller A is not the primary controller for these DNs.
In Example 1, if you log into Controller A and perform a synchronization operation to Controller B, with the Resilient User-Device synchronization policy set to "Synchronize data where <local element> is the PRIMARY and SECONDARY host for resilient devices", SDS writes the selected user and device data from Controller A to Controller B for DN 1000, DN 2000, DN 3000 and DN 4000.
Example 2 illustrates that you can synchronize the user and device data from the secondary controller to the primary controller. If you log into Controller B and perform a synchronization operation to Controller A, with the Resilient User-Device synchronization policy set to "Synchronize data where <local element> is the PRIMARY and SECONDARY host for resilient devices", SDS writes the selected user and device data from Controller B to Controller A for DN 1000 and DN 2000.
When you perform a synchronization of resilient user and device data, the operation synchronizes the entries in the following forms by creating or modifying device entries:
Multi-Line IP Sets form
Single Line IP Sets form
Wireless IP Sets form
For resilient devices, the synchronization operation modifies the database of the resilient peer controller as follows:
Creates a device entry in the Multi-Line IP Sets, Single Line IP Sets, or Wireless IP Sets if the DN does not exist on the secondary.
Generates a log on the slave controller to indicate that SDS has detected a device that the slave controller recognizes as being resilient, but that the master controller does not recognize as being resilient.
Does not create or modify a device entry on the secondary if the provisioned family type (Multi-Line IP Sets, Single Line IP Sets, or Wireless IP Sets) does not match the family type on the primary controller. A failure log will be created on the secondary.
Deletes hunt groups and agent groups that are shown as resilient between the master and slave controller, but only exist on the slave controller.
