Administrator Guide
If a redundant RAID controller module fails with an existing disk group process, the process on the failed controller is transferred to the
peer controller. A transferred process is placed in a suspended state if there is an active disk group process on the peer controller. The
suspended processes are resumed when the active process on the peer controller completes or is stopped.
NOTE: If you try to start a disk group process on a controller that does not have an existing active process, the start
attempt fails if the first virtual disk in the disk group is owned by the other controller and there is an active process on
the other controller.
RAID background operations priority
The storage array supports a common configurable priority for the following RAID operations:
• Background initialization
• Rebuild
• Copy back
• Virtual disk capacity expansion
• RAID level migration
• Segment size migration
• Disk group expansion
• Disk group defragmentation
The priority of each of these operations can be changed to address performance requirements of the environment in which the operations
are to be executed.
NOTE: Setting a high priority level impacts storage array performance. It is not advisable to set priority levels at the
maximum level. Priority must also be assessed in terms of impact to host server access and time to complete an
operation. For example, the longer a rebuild of a degraded virtual disk takes, the greater the risk for potential secondary
disk failure.
Virtual disk migration and disk roaming
Virtual disk migration is moving a virtual disk or a hot spare from one array to another by detaching the physical disks and re-attaching
them to the new array. Disk roaming is moving a physical disk from one slot to another on the same array.
Disk migration
You can move virtual disks from one array to another without taking the target array offline. However, the disk group being migrated must
be offline before performing the disk migration. If the disk group is not offline before migration, the source array holding the physical and
virtual disks within the disk group marks them as missing. However, the disk groups themselves migrate to the target array.
An array can import a virtual disk only if it is in an optimal state. You can move virtual disks that are part of a disk group only if all members
of the disk group are being migrated. The virtual disks automatically become available after the target array has finished importing all the
disks in the disk group.
When you migrate a physical disk or a disk group from:
• One MD storage array to another MD storage array of the same type (for example, from an MD3460 storage array to another
MD3460 storage array), the MD storage array you migrate to, recognizes any data structures and/or metadata you had in place on
the migrating MD storage array.
• Any storage array different from the MD storage array you migrate to (for example, from an MD3460 storage array to an MD3860i
storage array), the receiving storage array (MD3860i storage array in the example) does not recognize the migrating metadata and
that data is lost. In this case, the receiving storage array initializes the physical disks and marks them as unconfigured capacity.
NOTE:
Only disk groups and associated virtual disks with all member physical disks present can be migrated from one
storage array to another. It is recommended that you only migrate disk groups that have all their associated member
virtual disks in an optimal state.
NOTE: The number of physical disks and virtual disks that a storage array supports limits the scope of the migration.
Use either of the following methods to move disk groups and virtual disks:
• Hot virtual disk migration—Disk migration with the destination storage array power turned on.
• Cold virtual disk migration—Disk migration with the destination storage array power turned off.
22
About your MD Series storage array