Network adapter redundancy groups

The status of a network adapter redundancy group changes when at least one adapter in the group is flapping or has a status of down, disabled, not present, or testing.

Note:

By default, a value of testing for the network adapter’s status results in a Down notification. You can modify this behavior with the Testing Notification Mode.

In addition, you can create a network adapter redundancy group where the status calculation considers the state of the system containing the adapter. System status is useful when the group's members come from multiple systems. You determine the behavior by the topology you create. When all the network adapters in a group come from the same system, you can make the group PartOf a UnitaryComputerSystem. This prevents the unresponsive status of the system from affecting the status calculation.

The following examples use ASL code fragments to show several different network adapter redundancy groups.

In the first example, both network adapters are part of the host named host_1. Because of this, the redundancy group is inserted into the PartOf relationship with the host. If host_1 is unresponsive, IP Availability Manager does not generate any notifications about the redundancy group. If the group is not part of the system, IP Availability Manager would notify AllComponentsDown when host_1 is unresponsive.

Also, note the use of the LayeredOver relationship from the network adapter redundancy group to the system. This information is used to draw maps of network adapter redundancy groups in the Global Manager:

rg = create("NetworkAdapterRedundancyGroup",
   My-Redundancy-Group");
//
// Turns off system status calc
rg->PartOf += object("Host", "host_1"); 
//
// For service map 
rg->LayeredOver += object("Host", "host_1");
//
rg->ComposedOf += object("Interface", "IF-host_1/1"); 
rg->ComposedOf += object("Interface", "IF-host_1/2");

In the next example, the network adapters are from different systems. Because of this, the redundancy group is not inserted into the PartOf relationship with any system. As a result, the status of this redundancy group is based on the status of the adapters and the responsive state of their containing systems:

rg = create("NetworkAdapterRedundancyGroup",
   My-Redundancy-Group");
//
rg->ComposedOf += object("Interface", "IF-host_1/1");
rg->ComposedOf += object("Interface", "IF-host_2/2");
//
// For service map 
rg->LayeredOver += object("Host", "host_1");
rg-> LayeredOver += object("Host", "host_2");

In the next example, the network adapters are from a single system, but the system status is considered in the status calculation because the group is not a part of a system:

rg = create("NetworkAdapterRedundancyGroup",
   My-Redundancy-Group");
//
// For service map
rg->LayeredOver += object("Host", "host_3");
//
rg->ComposedOf += object("Interface", "IF-host_3/1");
rg->ComposedOf += object("Interface", "IF-host_3/2");

In the final example, the network adapters are from a single system but the system status is not included in the status calculation for the redundancy group. Again, this is because the group is inserted into the PartOf relationship with the system which consists of the network adapters.

rg = create("NetworkAdapterRedundancyGroup",
   My-Redundancy-Group");
//
// Turns off system status calc
rg->PartOf += object("Host", "host_4"); 
//
// For service map
rg->LayeredOver += object("Host", "host_4");
//
rg->ComposedOf += object("Interface", "IF-host_4/1"); 
rg->ComposedOf += object("Interface", "IF-host_4/2");