Configure the load balancers with the location (IP address and port) of the Advisor. For maximum availability, this address should be defined as a DVIPA.
In a sysplex subplexing environment, this step requires additional actions. For information about the changes to this step, see Configuring the external load balancers in a subplexing environment.
If you are using TLS/SSL, the load balancers are client applications in a z/OS® Load Balancing Advisor environment. You must configure the load balancers with the same TLS/SSL protocol and cipher suite (if encrypting data) with which the Advisor is configured. Client certificates should be configured on the load balancer, and also defined in the z/OS SAF-compliant security product if that level of authentication is required. See the load balancer documentation for instructions.
You might be able to customize features of the load balancer's communication with the Advisor. The SASP protocol defines two features that the load balancer implementation might or might not allow to be configured. One determines whether the load balancer polls the Advisor for updated data, or whether updated data is pushed to the load balancer. The other determines whether only members that have updated data should be sent to the load balancer, or whether all members should be sent to the load balancer regardless of whether their data has changed or not. To determine whether these features can be customized, and how to perform the customization if available, consult your load balancer's documentation. If the load balancer is capable and configured to request that the Advisor push updated information to the load balancer, the Advisor will update the load balancer at least every update interval. If the load balancer is capable and configured to poll the Advisor for updated information, the Advisor will recommend to the load balancer that it poll every update interval. However, the load balancer can choose to disregard this guideline. Consult the load balancer documentation for the expected behavior in these circumstances.
You might want to consider having redundant load balancers configured alike for availability reasons. If so, you need to be aware of the load balancer's unique load balancer identifier (LB UID), sometimes referred to as the UID or UUID, which uniquely identifies a load balancer. Duplicate LB UIDs are not allowed and connection attempts to the Advisor from a load balancer using the same LB UID as an existing connection will force the existing connection to be broken and replaced by the new connection. Redundantly configured load balancers either need to have unique LB UIDs, if you want them to serve as hot standbys that are connected simultaneously along with the load balancer they are backing up, or if they are configured with the same LB UID, they must remain unconnected from the Advisor until the original load balancer fails.
Some load balancers might be capable of using either dispatch or directed mode when forwarding packets to their destinations. External load balancers typically use a cluster IP address to represent the set of applications being load balanced. Client applications use this cluster IP address as the destination IP address for their requests. When a load balancer uses dispatch mode, the destination IP addresses for incoming IP packets is not changed. Instead, the load balancer forwards the packet to a target z/OS system by using the MAC address of a network adapter on that system. The receiving z/OS system inspects the destination IP address of the packet, and if it matches one of the IP addresses in its HOME list, accepts the packet. As a result, with dispatch mode, all target z/OS systems must have the load balancer's cluster IP address defined in their HOME list. However, it is important that these addresses are not advertised externally through dynamic routing protocols. One way to accomplish this is by defining these IP addresses as loopback addresses on z/OS.
With directed mode, the load balancer converts the destination IP address (that is, the cluster IP address) to an IP address owned by the target z/OS system, using technologies such as network address translation (NAT). When IP packets for these connections are sent back to clients, the load balancer converts the source IP address (that is, the target z/OS system's IP address) back to the cluster IP address that the application had used on its request.
While dispatch mode eliminates the need for performing NAT, it does have some special considerations. For example, in Figure 1, both SYSA and SYSB have the same server, FTPD, bound to the same port number using INADDR_ANY. The packet will have the cluster IP address (both SYSA and SYSB are in the same cluster), so the load balancer will use the MAC address to decide to send the packet to SYSA or SYSB, and TCP/IP will then route the packet to the server.
With directed mode, either the destination IP address (server NAT) is modified in the packet itself, or both the destination and source IP addresses (server NAT and client NAT) are modified in the packet. The packet must return through the same load balancer that will recognize the changes and do the reverse mapping, so a packet can flow from the original destination to the original source.
Configure each load balancer with the members that represent the individual target application instances, or system members that generically represent a system in the sysplex, or both. Members that can share the same type of workload are defined under the same group. For example, TN3270E Telnet servers are defined under one group, and HTTP servers in another. Application members are defined by specifying an IP address, a nonzero port, and a nonzero protocol. System members are defined by specifying an IP address, and specifying the port and protocol to be zero. Members that have only a port of zero or only a protocol of zero (that is, one but not both are zero) are not considered valid members and will not receive any data from the Advisor. The IP addresses of the members must represent valid, reachable addresses within the sysplex that are unique to a specific sysplex system. This excludes such addresses as the loopback addresses, and other non-advertised addresses.