Controller functions

Consider these factors when using multi-initiator and HA functions.

Use of the multi-initiator and HA functions require controller and AIX® software support. Controller support is shown in the feature comparison tables for PCIe and PCI-X cards. Look for controllers that have HA two-system RAID, HA two-system JBOD, or HA single-system RAID marked as Yes for the configuration that you want. The AIX software levels required for multi-initiator support are identified in the AIX software requirements table.

Specific controllers are intended only to be used in either an HA two-system RAID or HA single-system RAID configuration. Use the feature comparison tables for PCIe and PCI-X cards to look for controllers that have Requires HA RAID configuration marked as Yes. This type of controller cannot be used in an HA two-system JBOD or a stand-alone configuration.

Controllers connected in a RAID configuration must have the same write cache size (given they support write cache). A configuration error will be logged if the controllers' write caches are not the same size.

When configuring a controller for an HA two-system RAID or HA single-system RAID configuration, no mode jumpers or special configuration settings are needed. However, when configuring a controller for an HA two-system JBOD configuration, the Dual Initiator Configuration must be changed to a value of JBOD HA Single Path.

For all HA RAID configurations, one controller functions as the primary controller. Primary controllers perform management of the physical devices, such as creating a disk array, downloading SES microcode and downloading disk microcode. The other controller functions as the secondary and is not capable of physical device management.

If the secondary controller detects the primary controller going offline, it will switch roles to become the primary controller. When the original primary controller comes back online, it will become the secondary controller. The exception to this case is if the original primary controller was previously designated as the preferred primary controller.

Both controllers are capable of performing direct I/O accesses (read and write operations) to the disk arrays. At any given time, only one controller in the pair is optimized for the disk array. The controller optimized for a disk array is the one that directly accesses the physical devices for I/O operations. The controller that is not optimized for a disk array will forward read and write requests, through the SAS fabric, to the optimized controller.

The primary controller logs most errors that are related to problems with a disk array. Disk array errors might also be logged on the secondary controller if a disk array is optimized on the secondary controller at the time the error occurred.

Typical reasons for the primary and secondary controllers to switch roles from what was expected or preferred are as follows:

Controllers will switch roles for asymmetric reasons. For example, one controller detects more disk drives than the other. If the secondary controller is able to find devices that are not found by the primary controller, an automatic transition (failover) occurs. The controllers will communicate with each other, compare device information, and switch roles.
Powering off the primary controller or the system that contains the primary controller causes an automatic transition (failover) to occur.
Failure of primary controller or the system that contains the primary controller causes an automatic transition (failover) to occur.
If the preferred primary controller is delayed in becoming active, the other controller assumes the role of primary controller. After the preferred primary controller becomes active, an automatic transition (failover) occurs.
If the primary controller loses contact with the disks that are also accessible by the secondary controller, an automatic transition (failover) occurs.
Downloading controller microcode might cause an automatic transition (failover) to occur.

For all JBOD configurations, both controllers function only as stand-alone controllers and do not communicate directly with each other.

Users and their applications are responsible to ensure orderly read and write operations to the shared disks or disk arrays, for example, by using device reservation commands (persistent reservation is not supported).