IBM AIX Continuous Availability Features - IBM Redbooks
IBM AIX Continuous Availability Features - IBM Redbooks
IBM AIX Continuous Availability Features - IBM Redbooks
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
2.4.1 Virtual IP address support (VIPA)<br />
Prior to <strong>AIX</strong> V5.1, separate applications were required to provide high availability for a service<br />
IP address and its associated interface. If the network interface failed, then the application’s<br />
TPCP/IP session was often lost, resulting in the loss of application availability.<br />
To overcome this, support for virtual IP addresses (VIPA) on both IPv4 and IPv6 was<br />
introduced in <strong>AIX</strong> V5.1. VIPA allows the application to bind to a system-wide level virtual IP<br />
address, as opposed to a single network interface. VIPA is a virtual device often utilizing<br />
several network interfaces. VIPA can often mask underlying network interface failures by<br />
re-routing automatically to a different one. This allows continued connectivity and is<br />
transparent to the application and processes. VIPA also supports load balancing of traffic<br />
across the available connections.<br />
Another advantage of choosing a virtual device (as opposed to defining aliases to real<br />
network interfaces) is that a virtual device can be brought up or down separately without<br />
having any effect on the real interfaces of a system. Furthermore, it is not possible to change<br />
the address of an alias (aliases can only be added and deleted), but the address of a virtual<br />
interface can be changed at any time.<br />
Since its initial introduction in <strong>AIX</strong> V5.1, VIPA has been enhanced to make it friendlier, from a<br />
network administration perspective. It has also been enhanced so that failovers are<br />
completed faster, thus further improving availability.<br />
2.4.2 Multipath IP routing<br />
Prior to <strong>AIX</strong> V5.1, a new route could be added to the routing table only if it was different from<br />
the existing routes. The new route would have to be different by either destination, netmask,<br />
or group ID.<br />
Also, previous <strong>AIX</strong> releases did not provide any mechanism to associate a specific interface<br />
with a route. When there were multiple interfaces on the same subnet, the same outgoing<br />
interface for all destinations accessible through that network was always chosen.<br />
In order to configure a system for network traffic load balancing, it is desirable to have<br />
multiple routes so that the network subsystem routes network traffic to the same network<br />
segment by using different interfaces.<br />
With the new multipath routing feature in <strong>AIX</strong> V6.1, routes no longer need to have a different<br />
destination, netmask, or group ID list. If there are several routes that equally qualify as a route<br />
to a destination, <strong>AIX</strong> will use a cyclic multiplexing mechanism (round-robin) to choose<br />
between them. The benefit of this feature is two-fold:<br />
► It enables load balancing between two or more gateways.<br />
► The feasibility of load balancing between two or more interfaces on the same network can<br />
be realized. The administrator would simply add several routes to the local network, one<br />
through each interface.<br />
Multipath routing is often utilized together with dead gateway detection.<br />
2.4.3 Dead gateway detection<br />
The dead gateway detection (DGD) feature introduced in <strong>AIX</strong> V5.1 implements a mechanism<br />
for hosts to detect a dysfunctional gateway, adjust its routing table accordingly, and reroute<br />
Chapter 2. <strong>AIX</strong> continuous availability features 37