The load balancer distributes two types of workload requests in this example, FTP and HTTP traffic, both of which use the TCP protocol. (Keep in mind that UDP workload requests can also be distributed if wanted.) On SYSA, one FTP server is running, which is shared as a generic server between the two TCP/IP stacks. Also, on SYSA, an HTTP server is bound to stack S1. On SYSB, an FTP and HTTP server are running.
The load balancer must be configured with the IP address and port of the Advisor's load balancing connection socket. In this example, the TCP/IP stack on SYSB has defined 10.1.5.1 as a dynamic VIPA. In addition, this same address and port is defined to the Advisor on the lb_connection_v4 statement in the Advisor's configuration file. The load balancer also uses one of its interfaces to communicate with the Advisor. The IP address assigned to this interface must be coded in the Advisor's lb_id_list statement. In this example, the load balancer uses the interface assigned to the address 10.1.10.11. For information on how to determine which interface the load balancer will use to communicate with the Advisor, consult the specific load balancer documentation.
The load balancer advertises its cluster IP address, 10.2.1.21, so that clients that want to connect to specific applications in the sysplex will connect to this cluster IP address as a proxy. After the connection reaches the load balancer, to determine the actual target of the request, the load balancer consults the information that the Advisor has provided as well as possibly examining the content of the packet. The load balancer might substitute the target IP address in the packet header with the IP address of the member that is best suited to receive the new workload requests, or forward the packet as is using the appropriate MAC address. For example, if a connection request came to the load balancer (10.2.1.21) for port 21 using protocol TCP, the load balancer would forward the packet to either 10.1.10.22, 10.1.10.3, or 10.1.10.1, depending upon which member is the better candidate at that point in time.
To distribute FTP workload requests to the sysplex, a group called FtpServerFarm is defined to the load balancer. The load balancer maps the cluster IP address, 10.2.1.21, port 21, and protocol TCP to this group. In other words, if the load balancer receives a TCP connection with destination 10.2.1.21, port 21, it consults this group to find a member to which it can forward the connection. Within this group are three members that can handle FTP connections, representing target applications within the sysplex. One target can be reached at 10.1.10.22 on port 21, the second at 10.1.10.3 on port 21, and the third at 10.1.10.1 on port 21. The target applications represented by these members do not necessarily all have to be available at all times. The load balancer avoids trying to forward connections to target applications that are not currently available. Therefore, the list of target applications represented by the members in the group should be the entire set of possible members that could handle this workload, now or in the foreseeable future.
To distribute HTTP workload requests to the sysplex, a group called WebSrvrFarm is defined to the load balancer. The load balancer maps the cluster IP address, 10.2.1.21, port 80, and protocol TCP to this group. In other words, if the load balancer receives a TCP connection with destination 10.2.1.21, port 80, it consults this group to find a member to which it can forward the connection. Within this group are two members that can handle HTTP connections, representing target applications within the sysplex. One target can be reached at 10.1.10.22 on port 80, and the second can be reached at 10.1.10.1 on port 80.