MDisk groups

A managed disk (MDisk) group is a collection of MDisks that jointly contain all the data for a specified set of virtual disks (VDisks).

Figure 1 shows an MDisk group containing four MDisks.

Figure 1. MDisk group
This figure is described in the surrounding text

All MDisks in a group are split into extents of the same size. VDisks are created from the extents that are available in the group. You can add MDisks to an MDisk group at any time either to increase the number of extents that are available for new VDisk copies or to expand existing VDisk copies.

You can specify a warning capacity for an MDisk group. A warning event is generated when the amount of space that is used in the MDisk group exceeds the warning capacity. This is especially useful in conjunction with space-efficient VDisks that have been configured to automatically consume space from the MDisk group.

You can add only MDisks that are in unmanaged mode. When MDisks are added to a group, their mode changes from unmanaged to managed.

You can delete MDisks from a group under the following conditions:
Attention:
Table 1 describes the operational states of an MDisk group.
Table 1. MDisk group status
Status Description
Online The MDisk group is online and available. All the MDisks in the group are available.
Degraded paths This status indicates that one or more nodes in the cluster cannot access all the MDisks in the group. Degraded path state is most likely the result of incorrect configuration of either the disk controller or the fibre-channel fabric. However, hardware failures in the disk controller, fibre-channel fabric, or node could also be a contributing factor to this state. Complete the following actions to recover from this state:
  1. Verify that the fabric configuration rules for storage systems are correct.
  2. Ensure that you have configured the storage system properly.
  3. Correct any errors in the error log.
Degraded ports This status indicates that one or more 1220 errors have been logged against the MDisks in the MDisk group. The 1220 error indicates that the remote fibre-channel port has been excluded from the MDisk. This error might cause reduced performance on the storage controller and usually indicates a hardware problem with the storage controller. To fix this problem you must resolve any hardware problems on the storage controller and fix the 1220 errors in the error log. To resolve these errors in the log, select Service and Maintenance > Run Maintenance Procedures in the SAN Volume Controller Console. On the Maintenance Procedures panel, select Start Analysis. This action displays a list of unfixed errors that are currently in the error log. For these unfixed errors, select the error name to begin a guided maintenance procedure to resolve them. Errors are listed in descending order with the highest priority error listed first. Resolve highest priority errors first.
Offline The MDisk group is offline and unavailable. No nodes in the cluster can access the MDisks. The most likely cause is that one or more MDisks are offline or excluded.
Attention: If a single MDisk in an MDisk group is offline and therefore cannot be seen by any of the online nodes in the cluster, then the MDisk group of which this MDisk is a member goes offline. This causes all the VDisk copies that are being presented by this MDisk group to go offline. Take care when you create MDisk groups to ensure an optimal configuration.
Consider the following guidelines when you create MDisk groups:
  • Allocate your image-mode VDisks between your MDisk groups.
  • Ensure that all MDisks that are allocated to a single MDisk group are the same RAID type. This ensures that a single failure of a physical disk in the storage system does not take the entire group offline. For example, if you have three RAID-5 arrays in one group and add a non-RAID disk to this group, you lose access to all the data striped across the group if the non-RAID disk fails. Similarly, for performance reasons, you must not mix RAID types. The performance of all VDisks is reduced to the lowest performer in the group.
  • If you intend to keep the VDisk allocation within the storage exported by a storage system, ensure that the MDisk group that corresponds with a single storage system is presented by that storage system. This also enables nondisruptive migration of data from one storage system to another storage system and simplifies the decommissioning process if you want to decommission a controller at a later time.
  • Except when you migrate between groups, you must associate a VDisk with just one MDisk group.
  • An MDisk can be associated with just one MDisk group.
  • In general, MDisk groups that consist of single-port attached systems are not supported by the SAN Volume Controller. However, in some cases, specifically on HP StorageWorks MA and EMA systems that contain RAID partitions, the only way these systems can be attached to the SAN Volume Controller is through single-port attach mode.

Extents

To track the space that is available on an MDisk, the SAN Volume Controller divides each MDisk into chunks of equal size. These chunks are called extents and are indexed internally. Extent sizes can be 16, 32, 64, 128, 256, 512, 1024, or 2048 MB.

Table 2 compares the maximum VDisk capacity for each extent size. The maximum is different for space-efficient VDisks.
Table 2. Maximum VDisk capacity by extent size
Extent size (MB) Maximum VDisk capacity in GB (not space-efficient VDisks) Maximum VDisk capacity in GB (space-efficient VDisks)
16 2048 (2 TB) 2000
32 4096 (4 TB) 4000
64 8192 (8 TB) 8000
128 16,384 (16 TB) 16,000
256 32,768 (32 TB) 32,000
512 65,536 (64 TB) 65,000
1024 131,072 (128 TB) 130,000
2048 262,144 (256 TB) 260,000

You specify the extent size when you create a new MDisk group. You cannot change the extent size later; it must remain constant throughout the lifetime of the MDisk group.

You cannot use the SAN Volume Controller data migration function to migrate VDisks between MDisk groups that have different extent sizes. However, you can use the following SAN Volume Controller functions to move data to an MDisk that has a different extent size:
  • FlashCopy® to copy a VDisk between a source and a destination MDisk group that have different extent sizes.
  • Intracluster Metro Mirror or Global Mirror to copy a VDisk between a source and a destination MDisk group that have different extent sizes.
  • VDisk Mirroring to add a copy of the disk from the destination MDisk group. After the copies are synchronized, you can free up extents by deleting the copy of the data in the source MDisk group.

The choice of extent size affects the total amount of storage that is managed by the cluster. Table 3 shows the maximum amount of storage that can be managed by a cluster for each extent size.

Table 3. Capacities of the cluster given extent size
Extent size Maximum storage capacity of cluster
16 MB 64 TB
32 MB 128 TB
64 MB 256 TB
128 MB 512 TB
256 MB 1 PB
512 MB 2 PB
1024 MB 4 PB
2048 MB 8 PB

A cluster can manage 4 million extents (4 x 1024 x 1024). For example, with a 16 MB extent size, the cluster can manage up to 16 MB x 4 MB = 64 TB of storage.

When you choose an extent size, consider your future needs. For example, if you currently have 40 TB of storage and you specify an extent size of 16 MB, the capacity of the MDisk group is limited to 64 TB of storage in the future. If you select an extent size of 64 MB, the capacity of the MDisk group is 256 TB.

Using a larger extent size can waste storage. When a VDisk is created, the storage capacity for the VDisk is rounded to a whole number of extents. If you configure the system to have a large number of small VDisks and you use a large extent size, this can cause storage to be wasted at the end of each VDisk.

Library | Support | Terms of use | Feedback
© Copyright IBM Corporation 2003, 2009. All Rights Reserved.