Let’s work in this new entry creating a Oracle SBC solution in High Availability (HA) in our virtual environment. To accomplish this, we will need to start using 2 additional network interfaces that are specific and dedicated to being used as redundancy connections between the Oracle SBCs allowing the processes and sessions to synchronize.

This is a visual representation of the Oracle SBCs working in HA and the IP addresses planned to be used with this new config:

Oracle SBCs will have to have different names to differentiate the and as mentioned before wancom interfaces are dedicated for management and control purposes, in our case:

• wancom0 is defined in bootparam as the administrative interface
• wancom1 will be defined as a control interface with subnet 1.1.1.0/252 (having only 2 valid hosts, IP ending in .1 will be assigned to SBC1, .2 will be set for SBC2)
• wancom2 will also be defined as a control interface with subnet 2.2.2.0/252 (having only 2 valid hosts, IP ending in .1 will be assigned to SBC1, .2 will be set for SBC2)

All the following configuration defined in the next paragraphs is set in the SBC 1, at this point VM machine Having this in mind lets start with the configuration, and the first thing to do is changing the hostname and the IP address we were using in wancom0:

Remember that any changes in bootparam requires a reboot as this is not RTC.

When having Oracle SBCs in productions its important to set up the configuration for virtual MAC addresses and primary/secondary for network interfaces for the simplicity of this blog we will focus in the redundancy configuration required.

Next step is creating wancom1 and wancom2 physical interfaces:

Now setting the IP address defined previously (remember that primary IP is defined for SBC1 and secondary IP defines settings for SBC2):

Lets perform the last steps, creating the redundancy config as shown below:

Redundancy configuration is not RTC, which means that requires a reboot to have all that was configured activated, at this point LabOSBC1 was rebooted and shut down, why? Lets take advantage of our virtual environment, cloning the current SBC1 to create SBC2, remove all the config and add only the necessary to set up this high availability environment.

Here are the screens taken to accomplish the cloning in VirtualBox:

1. Select the current SBC1 and right click on it and select Clone:

2. Change the Name and the “MAC Address Policy to Generate new MAC addresses for all network adapters”

3. Select Full Clone

4. After a few minutes the new VM is now created, start it and lets proceed with the next steps:

As this VM was cloned from LabOSBC1 all settings equal, this new VM can be accessed using the IP address 192.168.1.201, lets change the IP address (what it was planned for LabSBC2 and the hostname):

Now lets remove all the configuration in this SBC and reboot:

Before proceeding to have the redundancy working correctly, there are a few things that needs to be validated:

• Target names match with the redundancy config issued in LabOSBC1
• Management IP address (wancom0) is reachable from both Oracle SBCs
• License information match
• Have the time sync in both SBCs (preferable using NTP)

After all those settings were validated lets proceed to request the config on LabOSBC2 from LabOSBC1, here is a view from both SBCs:

After performing the acquire-config, LabOSBC2 requires to issue reboot activate to have all the config activated.

Let’s do some connectivity testing (pinging from LabOSBC1 to LabOSBC2 and vice versa):

Issuing show health SBCs provides information about which one is active, and the processes that are synchronized:

Last action to perform is switching over the SBCs (make LabOSBC2 active) issuing the command notify berpd force:

notify berpd force can be executed in any SBC (active or standby)

show health provide a log on the SBC switchover history.

This concludes this entry.