This solution requires you to have an external load balancing machine, such as IBM® eNetwork Dispatcher. Virtual IP addresses allow you to assign an address to the system rather than to a specific interface. You can define the same address to multiple servers, which allows many new options for load balancing.
Situation
Your production iSeries™ handles data entry from both remote and LAN clients. It has the company's critical application on it. As the company has grown, so has its demand on the iSeries server and the network. Because of the growth, it has become imperative that this iSeries server be available on the network without an unscheduled down time. If, for any reason, a network adapter becomes unavailable, other network adapters on the iSeries server should take over and the network clients should be unaware of any failures.
Objectives
The concept of availability has many different aspects of redundancy and backup for failing components. In this scenario, the goal is to provide network availability to the iSeries server for its clients in the event of an adapter failure.
Details
One way to handle the preceding situation is to have multiple physical connections to the LAN from the iSeries server. Consider the following figure.
Each physical connection has a different IP address. Then you can assign a virtual IP address to the system. This virtual IP address is the IP address by which all of its clients recognize it. All remote clients (clients that are not physically attached to the same LAN as the iSeries server) communicate with the iSeries server through an external load balancing server such as a network dispatcher. When the IP requests from the remote clients go through the network dispatcher, the network dispatcher routes the virtual IP addresses to one of the network adapters on the iSeries server.
If the LAN that the iSeries server is connected to has clients,
these clients will not use the network dispatcher to direct their locally
bound traffic because that will unnecessarily overload the network dispatcher.
You can create route entries on each client that are similar to the route
tables in the network dispatcher. However, this will be impractical if the
LAN has a large number of local clients. This situation is described in the
following figure.
As of OS/400® V5R2, local clients (clients that are attached to the same LAN as the iSeries server) can connect to the virtual IP address of the iSeries server through ARP. This allows local clients to have an adapter failover solution as well.
In
each case, neither local clients nor remote clients are aware of the failover
when it occurs. The system chooses which adapters and IP addresses are the
preferred interface for virtual IP address (VIPA) proxy Address Resolution
Protocol (ARP) agent selection.
Starting with i5/OS™ V5R4, you
can manually select which adapters and IP addresses are to be the preferred
interface for VIPA proxy ARP agent selection. You can select which interface
to use by creating a preferred interface list if an adapter failure occurs.
A preferred interface list is an ordered list of the interface addresses that
will take over for the failed adapters. You can use either iSeries Navigator
or the Change TCP/IP IPv4 Interface (QTOCC4IF) application programming interface
(API) to configure a preferred interface list. The preferred interface list
is also configurable for both virtual Ethernet and virtual IP address interfaces.
Using Figure 2 as
an example, remote clients are communicating with the local system using virtual
IP address 10.1.1.7. Suppose 10.1.1.4 is the initial local adapter being used
for this communication, and you want 10.1.1.5 to take over if 10.1.1.4 fails.
You also want interface 10.1.1.6 to take over if both adapters for 10.1.1.4
and 10.1.1.5 have failed. To control the order in which these interfaces are
used in a failover situation, you can define a preferred interface list for
virtual IP address 10.1.1.7. In this case, it is an ordered list of interface
addresses that consists of 10.1.1.4, 10.1.1.5, and 10.1.1.6.
The solution can also involve using two or more iSeries servers to support each other. If one of the iSeries systems become unavailable, then the second system can serve as a failover. The following figure shows the same setup using two iSeries servers.
The packet routing is the same as routing for a single iSeries server and its remote clients; however, there is a distinct difference for the local clients. If you have multiple iSeries servers using the same virtual IP address, you can only proxy for one of the iSeries servers. In this case, you will have the iSeries server with the two LAN connections serve as the proxy.