8.5.8. HA-SEA with Failover

The advantage of the network virtualization with shared Ethernet shown so far, is the extremely simple configuration. After creating trunking adapters on a virtual I/O server and creating the shared ethernet adapter with “vios mksea“, client LPARs can use the shared ethernet adapter via easy-to-create virtual ethernet adapters. A major disadvantage, however, is that the shared Ethernet adapters shown so far have no redundancy. If the virtual I/O server with the shared Ethernet adapter fails, or if the physical Ethernet adapter of the SEA has a problem, the client LPARs immediately lose their connection to the external network.

To solve this problem, the HA mode of shared Ethernet adapters was introduced. A second shared Ethernet adapter with the same configuration is created on a second virtual I/O server. At a time, only one of the two SEAs takes over the connection to the external network, the other SEA remains passive and waits for the currently active SEA to fail. The active SEA is the so-called primary SEA, the passive SEA is the so-called backup SEA.

Figure 8.9 shows a highly available shared Ethernet adapter configuration with a primary SEA on the left virtual I/O server and a backup SEA on the right virtual I/O server. The trunking adapters on both SEAs have the same VLAN configuration. Both have 2 trunking adapters with PVIDs 1 and 2, as well as the additional VLAN IDs 100 and 1001, as well as 350, 399 and 512. The two trunking adapters of the left virtual I/O server have a trunk_priority of 1, the two trunking adapters of the right virtual I/O server have a trunk_priority of 2. All trunking adapters of a shared Ethernet adapter must have the same priority! The lower the value of trunk_priority, the higher the priority (values between 1 and 15 are allowed). The most important SEA attribute for an HA configuration is the attribute ha_mode with the two possible values auto and standby for an HA failover configuration as shown in figure 8.9.

Note: The device names of the individual adapters do not have to match on the two virtual I/O servers. It makes administration a little easier if the names are the same on both sides, but this is not necessary and cannot always be achieved.

High-availability configuration with primary and backup SEA.
Figure 8.9: High-availability configuration with primary and backup SEA.

Since the left SEA has the higher trunking priority (lower value of trunk_priority), the left SEA takes over the forwarding of Ethernet frames to the external network. If the left virtual I/O server fails, the link of the physical adapter goes down, or the network card fails, the right virtual I/O server takes over the forwarding of Ethernet frames and becomes the new primary SEA as shown in figure 8.10. This is transparent for the client LPARs and usually only a few Ethernet frames are lost. Since most applications use TCP as the underlying transport protocol, some data packets are simply retransmitted.

Failure Scenario in an HA-SEA configuration.
Figure 8.10: Failure scenario in an HA SEA configuration.

In order that each of the two SEAs always knows the status of the other SEA, the two SEAs must be able to communicate with each other. So-called heartbeats are exchanged, which signal the current status to the other SEA. In the simplest case, VLAN 4095 is simply used via one of the trunking adapters. VLAN 4095 is reserved and cannot be configured by the administrator. Disadvantage of this simple solution:

    • Is not supported on all managed systems.
    • Cannot be used if the virtual switch is using VEPA mode.

As an alternative, a separate control channel can be configured. This is a normal virtual Ethernet adapter (not a trunking adapter), which can also be specified when creating a shared Ethernet adapter using the attribute ctl_chan. A separate control channel is supported on all managed systems.

The trunking adapter and control channel do not have to be connected to the same internal virtual switch. If VEPA mode is to be used, the trunking adapter and control channel even have to be connected to different switches. The virtual switch to which a control channel is connected must use the VEB mode!

We recommend using a separate virtual switch for the control channel, e.g. ETHCTRL:

$ ms addvswitch ms05 ETHCTRL
$