Applies To:

Show Versions Show Versions

Manual Chapter: Additional Considerations for Redundant
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

For certain network environments, you might want to configure an active-active configuration. The basic configuration procedure is similar to the configuration procedure for an active-standby configuration, except that you must set the redundancy mode on both units to Active.
The remainder of this appendix explains some concepts about active-active configurations, the procedures for controlling failback and changing the redundancy mode, and some special tasks and considerations.
An active/active configuration offers the same protection from interruption of service as an active/standby configuration, and can offer decreased latency because traffic is handled by both systems simultaneously. However, to plan for the possibility of failure, each system in an active/active configuration should process no more than 50% of the load that would be carried in an active/standby configuration.
A common active-active configuration is one in which each unit processes connections for different virtual servers. For example, you can configure unit 1 to process traffic for virtual servers A and B, and configure unit 2 to process traffic for virtual servers C and D. If unit 1 becomes unavailable, unit 2 begins processing traffic for all four virtual servers.
Figure B.1 shows an active-active configuration in which units 1 and 2 are both in active states. With this configuration, failover causes the following to occur:
Unit 2 (already in an active state) begins processing the connections that would normally be processed by unit 1.
Part of configuring an active-active configuration is to assign a unit ID to each self IP address and virtual address that processes application traffic. For example, if unit 1 normally processes traffic for virtual servers A and B, then you must assign unit ID 1 to the floating self IP addresses pertaining to virtual servers A and B, as well as to the virtual addresses for virtual servers A and B. You can do this using the Configuration utility, by displaying the properties of a floating self IP address or virtual address and then selecting the relevant unit ID.
Likewise, if unit 2 normally processes traffic for virtual servers C and D, then you must assign unit ID 2 to the floating self IP addresses pertaining to virtual servers C and D, as well as to the virtual addresses for virtual servers C and D.
Later, if unit 1 fails over to unit 2, each floating self IP address and virtual address retains its own unit ID regardless of the actual unit on which those objects are running. That is, the floating self IP addresses and virtual addresses for virtual servers A and B retain their unit ID 1 designation while running on unit 2.
Note: In addition to associating a unit in an active-active system with a specific self IP address and virtual address, you can associate a unit with a particular SNAT.
Important: For an active-active system, you must assign a unique floating IP address to VLAN internal on each unit. Each unit shares its floating IP address with its peer (using ConfigSync).
When unit 1 becomes available again, you can initiate failback, which, in this case, means that the currently active unit relinquishes any processing that it is doing on behalf of its peer, and continues to operate in an active state, processing its own connections. From this point on, each unit in the active-active system handles its own unit-specific processing. For more information on failback, see Chapter 20, Configuring High Availability.
For an active-active system, suppose that when you initially ran the Setup utility on unit 1, you specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses, and when you ran Setup on unit 2, you again specified 11.12.11.3 and 11.12.11.4 as internal floating IP addresses. When you synchronize the configurations later, the addresses 11.12.11.3 and 11.12.11.4 should appear on both units as floating IP addresses.
The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 2.
The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address.
The back-end servers that normally send traffic to the internal address 11.12.11.4 on unit 2 continue to send their traffic to that same address, even though this incoming traffic is now processed by unit 1.
The back-end servers that normally send traffic to the internal address 11.12.11.3 on unit 1 continue to send their traffic to that same address.
Tip: You can configure additional floating IP addresses on the external VLANs of each BIG-IP system as well. This makes it possible for routers to route to a virtual server using virtual noarp mode.
With an active-active configuration, when a failover condition occurs, one unit takes over processing for the other. Then, by default, when the failed unit becomes available again, failback occurs automatically. That is, the recovered unit resumes processing for its own virtual servers, with no user intervention required.
If you manually initiated failover using the bigpipe failover standby command. In this case, failback can only occur when you manually initiate it.
If you configured the bigdb key Failover.ManFailBack key to require manually-initiated failback at all times. By default this key is set to disable, which ensures that the failback process is automatic. If you set this key to enable, you must always initiate failback manually, even when the failover event occurred automatically.
In either case, when a failed unit becomes available again, the peer unit continues to process connections for both units until you manually initiate failback.
To manually initiate failback, you can use either the Configuration or the bigpipe utility. Once failback occurs, each unit resumes processing for its own virtual servers. The normal time that it takes for failback to complete on an active-active system is 60 seconds.
2.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
Type the command failover failback.
Returning to active/standby mode from active-active mode is relatively simple in that only a few things need be changed. Use the Configuration utility to do this conversion, being sure to make these same changes on each unit of the redundant system.
1.
On the Main tab of the navigation pane, expand System, and click High Availability.
The Redundancy Properties screen opens.
2.
From the Redundancy Mode list, change the mode to Active/Standby.
3.
On the menu bar, click ConfigSync.
The ConfigSync screen opens.
4.
For the Synchronize setting, click Synchronize TO Peer.
5.
Click Update.
6.
On the menu bar, click Redundancy.
The Redundancy Properties screen opens.
7.
From the Redundancy State Preference list, change the preferred state of the unit to Active or Standby. For more information, see Chapter 20, Configuring High Availability.
8.
Click Update.
Once the system is running in active/standby mode, it is the active unit that manages connections for all local traffic management objects (such as virtual servers and SNATs), regardless of the unit associated with those objects. Therefore, it is not necessary to re-associate virtual servers, SNATs, or NATs with a specific unit when you transition from active-active mode to active/standby mode.
When the surviving unit takes over a virtual server of the failed unit (in addition to having its own virtual servers), the surviving unit must know which virtual server to use to process traffic that it receives from a back-end server. The way it knows this is by the floating IP address to which the response was sent. (As described previously, in an active-active configuration, each unit must have its own unique floating IP address.)
The floating IP address of unit 1 is 11.12.11.3, and the floating IP address of unit 2 is 11.12.11.4.
Server http_server normally handles traffic for unit 1, which has virtual server vs_http. Server smtp_server normally handles traffic for unit 2, which has virtual server vs_smtp.
You have configured the default routes of the servers accordingly. That is, you have set the default route of http_server to 11.12.11.3, and the default route of smtp_server to 11.12.11.4.
Continuing with our previous example of back-end server http_server, if the surviving unit receives a response from http_server (sent to 11.12.11.3, the unit 1 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by the unit 1 virtual server vs_http (now on unit 2).
Similarly, if the surviving unit receives a response from server smtp_server (sent to 11.12.11.4, the unit 2 floating IP address), the surviving unit knows, based on that IP address, that the traffic is to be processed by its own virtual server, vs_smtp.
Thus, if you have 20 servers and half of them normally serve the unit 1 virtual servers, you must configure the default route for those 10 servers to be the floating IP address of unit 1. For the remaining 10 servers in your network, which serve the unit 2 virtual servers, you must configure their default route to be the floating IP address of unit 2.
By setting the default routes of your back-end servers to the floating IP address of either unit 1 or unit 2, you ensure that if a unit becomes unavailable, any connections that the servers normally send to that unit are received and processed by the surviving unit, because the surviving unit has assumed the internal floating IP address of the failed machine.
Important: If you plan to run your redundant system in active-active mode, you must synchronize the configuration data again. For more information, see Chapter 20, Configuring High Availability.
For active-active configurations, you cannot switch an active unit to a STANDBY or an OFFLINE state if that unit is currently processing connections for the peer unit due to a failover.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)