Part 1. Configure the appliances for self-balancing
In order for the DataPower appliances to participate in frontend self-balancing, they need to be licensed. To verify AO licensing, complete the following steps, once for each appliance:
- Login to the WebSphere DataPower WebGUI as a privileged user and
navigate to Status > System > Device
Features. You can also get to this menu item by
device featuresin the Search box.
- Verify that the Option for Application Optimization
support is enabled and available, as shown in Figure
Figure 1. Device features
For each appliance, you need to pick a network interface to be set up for self-balancing. It is common practice to pick the same interface name, such as eth11, on each appliance.
- Starting with the first appliance, browse through Network > Interface > Ethernet Interface and select an active network interface you would like to enable for self-balancing.
- Switch to the Standby
Control tab and click Add.
- Specify a unique Group Number that is not currently in use within your network and with a value higher than 20 to prevent conflict with network routers and switches. This information is generally available from your network administrator and has to be the same on both appliances.
- The Virtual IP Address (VIP) you supply acts as an abstract virtual IP to service traffic to all devices within the standby group. Note that the VIP must exist on the same subnet as the appliance's real IP address and needs to be the same for both appliances.
- The Priority field decides which
appliance will assume the role of controller or
distributor for the cluster. The one with the highest
priority becomes the primary, and the one with lower
ranking is elected in case of a failure of the primary.
Therefore, leave that field at the default value of
100for the appliance you pick to be primary and set it to
90for the other.
- Set the Enable/Disable Self-Balancing
flag to on
and click Apply, as shown in Figure 2.
Figure 2. Standby control
- Repeat Steps 3 and 4 above for the second appliance.
If you set the Log Level to "debug" in the default domain of the appliances, you see messages showing the self-balancing function in action. The example in Figure 3 shows the secondary appliance doing health checks on the primary appliance every two seconds to verify that it is still up.
Figure 3. Self-balancing debug logs
To demonstrate the self-balancing operation on the DataPower appliances, you configure an XML Firewall service on each appliance to listen to incoming requests on the Virtual IP address defined previously and on a port that you specify. The primary distributor or controller takes care of load balancing the requests across the appliances in a way similar to an IP sprayer.
On each appliance, complete the following steps:
- Log in as a privileged user in the default domain and navigate through Administration > Configuration > Application Domain to create an application domain called "AO" in which you will configure the service.
- Switch to the AO domain and browse through Control Panel > XML Firewall and click Add Wizard.
- Select Pass Thru (testing only) and click Next.
- For the Firewall Name, enter
- Select loopback-proxy for the Firewall Type.
- Type in the Virtual IP address you defined previously in the
Device Address field, and use an unassigned
port in the Device Port field. Use the same VIP
and port values on each appliance.
Tip: You can refer to Status > IP-Network > TCP Port Status to find an unused port on the appliance.
- Commit the changes you made and click Done.
- Click on the SB_XMLFW XML Firewall service and
change the Request Type to XML
and click Apply (see Figure 4).
Note that you can also create the XML Firewall service on the primary appliance and export the configuration to the second appliance.
Figure 4. Self-balancing XML Firewall
- Set the Log Level to "debug" in the AO domain to
see the incoming messages in the logs. Click Save
Config to save your configuration.
Switch to the client workstation where you downloaded and installed the software tools earlier.
- Run the following ApacheBench command "ab" with 10 concurrent POST
requests, substituting the string
172.20.0.59:4000with the VIP and port you defined for your XML Firewall (see Figure 5). The referenced
xycohr.htmlfile is available from the Download section of this tutorial.
ab –n 10 –c 10 –p xycohr.html http://172.20.0.59:4000/
Figure 5. ApacheBench tool
- Check the system logs for the XML Firewall service on each
appliance. You see an even distribution of five transactions on
each. You may want to filter the logs by "multistep" to only
display the relevant information, as shown in Figure 6
Figure 6. XML Firewall logs
- Back to the default domain of the primary appliance, browse
through Network > Interface > Ethernet
Interface to disable the Ethernet interface in the
standby control group, simulating a failure of that appliance. If
you still have debug logging turned on in the default domain,
notice the secondary appliance detecting the primary being down
and automatically promoting itself as distributor or controller,
as shown in Figure 7.
Figure 7. Self-balancing failover debug logs
- Re-run the ApacheBench command from the client workstation. Notice
that all ten transactions are being received by the secondary
appliance, as shown in Figure 8.
Figure 8. XML Firewall failover logs
- Re-enable the Ethernet interface of the primary appliance in the standby control group and verify from the default domain debug logs that it re-assumes the role of distributor or controller. Also, if interested, re-run the ApacheBench command to verify the even spread of five transactions on each appliance.