Standby controls
Standby controls define the policies for the group that the interface is a member.
A standby group is the collection of interfaces on different DataPower® Gateway products in the multicast domain that share the responsibility for one virtual IP address. When at least one member of a standby group can reach the multicast domain, the virtual IP group receives the traffic.
The multicast domain is defined by the group of interfaces that can receive traffic on the IP
address 224.0.0.2 (the all-routers
IP multicast group) from each other. If the
multicast domain becomes partitioned, which is an unusual situation, a member in each partition
becomes the active member to handle connections in its partition.
Standby group members share the responsibility for the virtual IP addresses. Each standby group has one active member and one or more backup members. The interface with the highest priority seeks to be the active member. When multiple interfaces have the same priority, one becomes the active member.
- Standby mode
- In standby mode, all connections go to the active member. The active member receives all TCP connections and processes all requests. The active member processes all requests and responses. If the active member becomes unreachable, the standby member becomes the active members. If you configure standby control for B2B high availability, you must retain the priority of 100 and enable preemption for both the active and backup DataPower Gateway products.
- Self-balancing mode with standby support
- In self-balancing mode, which requires the Application Optimization feature, the active member manages all TCP connections to virtual IP addresses. When a client initiates a new TCP connection, the active member uses the defined distribution algorithm to select a member to act as the connection endpoint. The active member tracks member capabilities to distribute traffic. The selected member completes the establishment of the connection. The active member forwards all segments of the TCP connection to the member that is acting as the connection endpoint.
Transition when active member becomes unreachable in self-balancing mode
Based on why the active member becomes unreachable in self-balancing mode, the transition from the active member can be graceful or nongraceful.
- In a graceful transition, such as for scheduled maintenance, most connections can be preserved if the DataPower Gateway that disconnects the connection remains available. In practice, quiesce the active DataPower Gateway to ensure that established connections complete before you start maintenance; for example, apply firmware. In some environments, the time for the takeover exceeds the client timeout value. Similarly, if the DataPower Gateway timeout value is aggressive, connections can be lost because the DataPower Gateway disconnected the connection because of a timeout.
- In a nongraceful transition, if the active member becomes unreachable, the backup member with the next highest priority becomes the active member. The active member might become unreachable because of network issues, restart, power outage, or similar cause.
Service weights in self-balancing mode
- Running at 100% CPU.
- Lost connectivity; for example, a pulled network cable.
- Ports are down.
Services that cannot operate in self-balancing mode
- Administrative services, which include the web management service, the XML management interface, Telnet, and SSH.
- The HTTPS handler for the API gateway. This handler is created based your configuration of the API Connect Gateway Service.
- FTP server handlers.
Service configuration in self-balancing mode for chained services
- The entry point to the second or later service in the chain must use 127.0.0.1 to ensure that the message is processed by the same DataPower Gateway.
- Disable persistent connections between the services in the chain.
B2B gateway services in self-balancing mode
- You might not be able to view the complete details of a transaction in the B2B viewer.
- You might not be able to get an ebMS status response message.
- The DataPower Gateway cannot always return an ebMS status response message to the external partner. Requests for the same transaction can be sent to a different member for processing, which results in different transaction states about the same transaction on different members.
- The DataPower Gateway cannot always identify a duplicate message. A duplicate message can be sent to a different member for processing. Therefore, no member can identify a duplicate message.
- The DataPower Gateway might not receive the expected acknowledgment message from an external partner that result in excessive message retransmissions because the acknowledgment message can be received by another member. In this case, the member that started the transaction considers the previous message transmission a failure and retransmits it.