Dual storage IOA functions
Consider these factors when using dual storage I/O adapter (IOA) functions.
Use of the dual storage IOA function requires controller and IBM® i software support. Controller support is shown in the feature comparison tables for PCI-X, PCIe, PCIe2, and PCIe3 cards. Look for controllers that have Dual Storage IOA configuration marked as Yes. The IBM i software levels that are required for multi-initiator support are identified in the Controller software verification topic.
Controllers connected in a dual storage IOA configuration must have the same write cache size (assuming that they support write cache). A configuration error is logged if the write caches for the controllers are not the same size.
When you configure a controller for a dual storage IOA configuration, no mode jumpers or special configuration settings are needed.
For all dual storage IOA configurations, one controller functions as the primary controller. Primary controllers perform management of the physical devices, such as creating a disk array. The other controller functions as the secondary controller and is not capable of physical device management.
If the secondary controller detects that the primary controller is going offline, it switches roles to become the primary controller. When the original primary controller comes back online, it becomes the secondary 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 forwards 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 are as follows:
- Controllers 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 communicate with each other, compare device information, and switch roles.
- Powering off the primary controller causes an automatic transition (failover) to occur.
- Failure of the primary controller causes an automatic transition (failover) to occur.
- 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.
Innovative improvements have been made in IBM i 7.2 TR 2 and IBM i 7.1 TR 10 to drastically reduce the recovery time for some of those failover scenarios so their impact on performance is measurable in seconds rather than minutes. The breadth of impact for some of the scenarios has been greatly reduced also, to not affect the operation of active paths. These improvements apply to PCIe3 SAS RAID adapters.
