X hits on this document

159 views

0 shares

1 downloads

0 comments

15 / 37

Regardless of whether the migration is done to empty space on the disk or by swapping unmapped and/or unmasked devices the input is always one or more devices (the source - the devices to be migrated) and a list of disks (the target – the target locations will be selected from these disks) , the Optimizer role is to match the sources to the targets based on the configuration rules and user input and then to execute the migration plan.

Matching the sources to the target list has to follow and obey to all back-end configuration rules and especially to the new affinity rules that are mandatory since 5772. The affinity rule requires that all members of a RAID 5, RAID 6, or RAID 1 device reside on the same RAID group; these are groups of 16 (RAID 6 14+2), 8 (RAID 5 7+1 and RAID 6 6+2), 4 (RAID 5 3+1), or 2 (RAID 1) disks of the same disk class (same type and speed). In order for the migration to pass the validation, the customer has to provide at least one complete affinity group as target disks, and providing a partial affinity group as input will result in immediate validation failure, "Can not place all source devices on the specified target disks. Please check optimizer log for details." The Optimizer log will suggest adding specific disks to the targets.

The swap and migration procedures have to temporary break affinity groups; this is by design, however once these procedures run to completion all broken affinity rules are resolved. It is important to allow these procedures to run to end, if for any reason they were stopped in the middle or failed for any other reason, it is crucial to resume the failed procedure and let it run to completion. Both SymmWin and Optimizer will not tolerate broken affinity rules after a configuration change is done.

The VLUN migration allows users to migrate metadevices into a different disk tier (for example, from the performance tier to the capacity tier). A new back-end rule forces all metamembers to reside on the same disk tier to guarantee consistent performance across all metamembers. While the migration is in progress, members of metadevices have to reside on different disk classes; this is again by design and both SymmWin and Optimizer tolerate this scenario, however after the meta migration plan is done – meta consistency rules are applied and re-enforced. Meta migration is not an atomic operation and can take a while to complete because a metadevice can be large and the Optimizer can migrate only a limited number of devices (metamembers) in parallel; using the Optimizer migration rule to migrate a complete metadevice is the preferred way to ensure that all members are migrated and that the configuration changes follow the business cycles, (the “Optimizer Swap Time Windows”).

Migration to unmapped/unmasked devices is a bit different from the migration to unused space. In this mode the Optimizer matched unmapped (or unmasked) devices to the source devices (when the source device is a metadevice then the Optimizer first tried to find a matching metadevice with the same size and number of members). This is done to ensure that affinity groups and metarules are enforced and that the unmapped devices will be ready for future usage upon user request. If the Optimizer cannot match the same size meta then it will try to find smaller metadevices that fit into the source device or even regular devices that follow all metadevice back-end restrictions.

Other features include:

Performance awareness - When migrating data into unmapped (or unmasked) devices, the Optimizer considers the performance of the source devices and of the target disks. The Optimizer will then pick the best targets based on the configuration rules and the performance.

DRV requirement – The underlying technologies of swap and migration are almost identical. The Optimizer uses DRV devices to hold a temporary copy of the data while the procedure is running. The same DRV rules and requirements for swaps are applicable for the migration process.

Rollback – Each rollback session can undo only one type of configuration change (either swap or migration). In some cases when the user had sessions of swaps followed by session of migrations, more than one rollback session is required to undo all changes. (First undo the migration, then undo the swaps, and so on.)

EMC Symmetrix Optimizer A Detailed Review

15

Document info
Document views159
Page views186
Page last viewedThu Dec 08 19:08:52 UTC 2016
Pages37
Paragraphs693
Words12348

Comments