Server load balancing
With load balancing, inbound connections are automatically directed to the server instance that has the most available resources. To determine which instance handles a request takes into account the number of connections currently being handled by each instance and the availability of virtual storage (above and below the 16-MB line).
Load balancing is transparent to the client application. An application uses a port number to connect to an instance, and the instance determines whether it or another instance should handle the session. If another instance is a better choice, the session is transferred.
The client application can be configured with the port numbers of more than one member of the group. This configuration improves reliability by providing a fallback if the copy of the product that uses the base port number is not available. Load balancing increases the number of concurrent connections that the server can handle. As a practical matter, this feature supports far more connections by using RPCs to be concurrently handled. This feature is a key point, because connections by using RPCs exhaust the virtual storage resources of a server instance much faster than DB2 connections.
Sequence of events
Find the address space of the first server.
Verify whether sufficient virtual storage exists. If enough storage is available, the server is marked as a candidate.
Check the number of active connections.
Repeat steps 1 - 3 until all the server candidates are identified.
From the available candidates, the server that has the least number of active connections is selected. If a candidate is not found, the connection is rejected with an inadequate host resources error message.
The group concept
Load balancing is based on the concept of a group. All copies of the server on one system with the same group name are automatically members of the same group. A copy of the product can be a member of only one group at a time or it can be configured to be a stand-alone server and not as a member of a group. All address spaces in a group must reside on the same z/OS image.
The group name can be changed at any time, which means copies of the server can join groups or leave groups as needed.
Using a group director
You can also define a server as a group director. The load balancing group director does no work except route connections to other Servers. A group director passes connections to the best candidate server in the group, giving the user the option to not run application work in a server that accepts inbound connections. When using a group director, everyone connects to the group director, which then routes all of the connections to other Data Virtualization Manager servers.
If you have one Data Virtualization Manager server act as a group director for load balancing, this server would not perform application work, but would only route requests to other servers based on current loads. The server that is performing as a group director has the greatest stability. This method ensures that a connection is made even if some of the application servers are down. This method gives you the highest availability.
If you do not use a group director, the same Data Virtualization Manager server that is routing requests also does application work. If that server fails, all subsequent connection requests fail.