M08res01 Virtual LUN Migration.

This module focuses on Virtual LUN Migration.
Copyright 2013 EMC Corporation. All rights reserved Module 8: Virtual LUN Migration 1
Enhanced Virtual LUN Technology allows storage administrators to quickly move an
applications data to other storage within the same array without impacting local or remote
replication. A migration can change the protection level and disk type of FBA, CKD, and IBM i
512-byte D910 devices. A migration can use the storage of existing devices that do not
contain live data or unconfigured disk space.
Virtual LUN migration is from source devices to equally-sized target devices, or disks with
free space equal to the source devices. A migration will not disrupt hosts or internal
applications.
Virtual LUN technology for disk group provisioned (DP) devices offers two types of data
movement: migration to configured space and migration to unconfigured space.
Virtual LUN VP migration migrates thin devices from one thin storage pool to another. In this
way, data can be moved between storage pools configured on different drive technologies
and with different RAID protection types.
Virtual LUN Migration is a technology that enables storage virtualization.
It allows Symmetrix users to seamlessly move application data between different storage tiers.
The storage tiers could reside inside the Symmetrix as well as outside the Symmetrix if FTS is
being used.
As data ages and the need for its availability diminishes, it can be moved to less expensive
storage as part of the ILM process.
Performance optimization is another function of V-LUN migration as applications are moved
between storage tiers.
Virtual LUN technology supports the migration of disk group provisioned Symmetrix logical
volumes in Open Systems and Mainframe environments and includes support for meta
volumes.
Virtual LUN VP mobility supports the migration of Thin devices from one storage pool to
another in open systems environments. At the end of the migration, Thin devices are bound to
the target pool unless a source pool is specified.
If a source pool is specified, allocated tracks from the source pool are migrated to the target
pool without affecting the binding. A pool-level migration of thin devices does not change the
binding of that thin device to the target pool, therefore the rebind option must be done
manually, if the rebind is desired. This functionality differs from the full migration of a TDEV in
that not all the TDEV allocations will be migrated, just the allocations that are in the source
pool. Any allocations in pools other than the source pool will not be migrated to the target in
this pool-to-pool migration.
This lesson covers the theory of Virtual LUN migration for disk group provisioned devices.
Enginuity supports up to four mirrors for each Symmetrix volume.
RAID Virtual Architecture is used for handling device mirror position usage. RAID Virtual
Architecture is an enabling technology for the Enhanced Virtual LUN technology and Fully
Automated Storage Tiering (FAST). Note that RAID Virtual Architecture does not introduce any new
RAID types. All device protection types use the same I/O execution engine which separates the
mirror position interface from RAID internal operations.
With the RAID virtual architecture a mirror position holds a logical representation of a RAID group
rather than a device, resulting in additional free mirror positions as demonstrated in this example.
Notice the RAID 5 volume with SRDF protection consumes only two mirror positions. The RAID 5
group occupies only one mirror position with the SRDF protection occupying a second position. This
frees two mirror positions for other operations such as a migration to another RAID type.
The diagram shows the migration process of an R2 device, which has one remote mirror. When a
migration is initiated, the target device occupies the third mirror position during the course of the
migration.
The RAID Virtual Architecture (RVA) will allow a maximum of two RAID groups attached as a mirror
at the same time. However, this is a transitional state to support operations such as migrations and
Optimizer swaps. The array operations associated with the RAID groups will be handled
independently for both attached groups. The attached RAID groups may be in different disk groups
containing different capacities and speeds.
The SYMCLI command symmigrate can be used to perform and monitor migrations. When
performing a migration you must designate the source, which is the device the data will be migrated
from. The device can be selected from Unisphere for VMAX GUI or on the command line by device
group, an auto provisioning storage group, or by a device file that contains a single column listing
only the desired source devices.
Next, you will need to identify the target, which is the volume the data will be migrated to. The
criteria and syntax for designating the target will vary based on whether the target is unconfigured
or configured. A symcli device group cannot be designated as a target.
When working with configured space you can control which source volumes are migrated to which
target volumes by creating a device file with two columns. The first column containing the source
device numbers, and the second column containing the desired target device numbers.
Migrations are submitted and managed as sessions, so you can use a session name using the name
option. Note that the control host for the migration must be locally connected to the Symmetrix
VMAX array on which the migration is being performed.
Note that the source or target volumes can reside on eDisks that were created on an external array.
The symmigrate command has three control actions and three monitor actions. The control actions
include validate which tests the user input to see if it will run, establish which creates the migration
session and start the synchronization process, and terminate which removes a session by name.
The terminate action can only be performed when all volumes in the session are in the Migrated
state.
The monitor actions include query which provides status about a specified session, list which shows
all sessions for a given Symmetrix array or all local Symmetrix arrays, and verify which determines if
the specified session is in a specified state.
V-LUN migration is made possible by the creation and movement of RAID groups. Initially the
target RAID group is added as a secondary mirror. Once the migration completes, the target
RAID group is made the primary mirror. If migrating to unconfigured space, the target RAID
group, i.e. the original source device is deleted. If migrating to configured space the target
device, i.e. the original source device is iVTOCd after the migration is completed.
V-LUN Migration can be controlled either from the command line using the symmigrate
command, or from the Unisphere for VMAX GUI.
In the first example we will demonstrate a Virtual LUN Migration which transfers two volumes non-
disruptively from RAID-1 to RAID-6 protection.
The symmigrate validate command checks the Symmetrix for suitable migration candidates.
In our example the validation step identifies devices 1A3 and 1A4 as suitable targets for migration.
The RAID-1 volumes are part of disk group 3 and the RAID-6 volumes are in disk group 1. When the
LUN migration starts the RAID-6 volume temporarily takes up a mirror position while the two
volumes are synchronized. Once the migration is complete the original target device assumes the
identity of the source and the original source assumes the identity of the target. Data on the target
LUN, i.e. the original source is destroyed through IVTOC.
The symdisk list dskgrp_summary command lists the disk groups present in the
Symmetrix. A disk group generally contains disks of a certain technology and RPM. Drives of
different technologies (such as FC, SATA or Flash) are placed in different disk groups whereas
drives of similar technologies are placed in the same disk group.
Here disk group 3 contains 15K RPM FC drives, disk group 2 contains 10K RPM FC drives and
disk group 1 contains 7200 RPM SATA drives.
This example will show the migration of a source storage group called Appsg. The storage
group contains two devices, B1 and B2.
Devices B1 and B2 are configured on disk group 3, which contains 15K RPM FC drives.
The validate command queries the Symmetrix to find if there are devices that suit the criteria
that we asked for, namely, RAID-6 devices with 6+2 protection. The tgt_config option
specifies that the migration should be undertaken to configured space. If valid targets exist
the device pairing should be written out to a file. This file can later be used as input to the
symmigrate command.
Here we take a look at the two devices suggested by the output of the validate command.
The interrogation marks in the SA column in the symdev list output mean the devices
are unmapped. If there had been asterisks it would had meant that the devices were mapped
to more than one front end port.
There happen to be two RAID-6 devices in this Symmetrix that are not mapped to any
director as evidenced by the interrogation marks in the SA column. The devices in the output
are connected to backend directors 8A:D0 and 8D:C0. These devices are in disk group 1.
The file devlist is used as input to a symmigrate command.
Since the file devlist contains the pairings of the devices, it is clear that we are migrating to
configured space. We also no longer need to specify the target disk group and RAID
protection.
The file devlist is used as input to a symmigrate command. Once the command is
underway a list command shows details on the state of the migration.
The value C in the Flags column indicates that we are migrating to configured space.
A listing of the storage group shows that devices B1 and B2 are now RAID-6 protected. They
used to be RAID-1 protected.
The output shows that 1A3 and 1A4 have swapped places with B1 and B2. This includes the
RAID protection and the disk groups. During the migration process devices B1 and B2
continued to stay host accessible.
The session can now be terminated.
Lets review the migration process we observed in the previous demonstration. After specifying
configured space and the target protection (or disk type), the establish action instructs the array to
perform the following steps:
1. An available target Symmetrix LUN is determined with a RAID group of the protection and disk
type specified.
2. The RAID group is disassociated from the target Symmetrix LUN and is associated to the
Symmetrix LUN being migrated as the secondary mirror.
3. The secondary mirror is synchronized with the primary mirror.
4. The primary and secondary indicators are swapped between the two mirrors.
5. The secondary mirror, which is now pointing to the original RAID group, is disassociated from the
Symmetrix LUN being migrated and associated as the primary mirror to the target Symmetrix
LUN.
6. The target Symmetrix LUN is then iVTOCd to clear the data from it.
This time well perform a migration from the same device group to unconfigured space.
The unconfigured space to which the data is being moved is designated on the command line with
the option tgt_unconfigured. When migrating to unconfigured space we must designate the
desired target configuration and protection on the command line, in this case we are designating
RAID 1 which will be built automatically and placed in the next available mirror position.
Once we issue the command, the migration session is established and the source is synchronized
with the target, while also servicing production I/O from the host. After synchronization completes,
the target assumes the identity of the source. The source is then deallocated and the storage
capacity is freed up in the original disk group. From the hosts point-of-view this operation is
completely transparent. Keep in mind that migrating to unconfigured space is a slightly longer
operation as the target configuration is created before the migration begins.
This time we will use a device file called devs to move devices B1 and B2 back to disk group
3 with RAID-1 protection. We first validate if this will work and execute the migration.
The query confirms that the migration is complete. Also, it is a migration to unconfigured
space as the legend U in the second last column indicates.
The query confirms that the migration is complete. Also, it is a migration to unconfigured
space as the legend U in the second last column indicates.
After specifying un-configured space and the target protection (or disk type), the establish action
instructs the array to perform the following steps:
1. A new RAID group of the specified protection type is created on the specified disk type.
2. The newly created RAID group is associated to the Symmetrix LUN being migrated as the
secondary mirror.
3. The secondary mirror is synchronized to the primary mirror.
4. The primary and secondary indicators are swapped.
5. The secondary mirror, which is now pointing to the original RAID group, is deleted.
This lesson covers Virtual LUN Migration for Thin pools.
Virtual LUN VP mobility is a non-disruptive migration of a (complete) thin device from one pool
(or multiple pools) to another thin pool.
The migration operation is initiated by the Storage Administrator. All extents associated with
the designated thin device are moved to the designated target pool. When complete, the thin
device is bound to the target pool. When performing a thin device migration the thin pool that
the thin device is currently bound to may be specified as the target of the migration. In this case
any tracks for the device that are allocated in pools other than the bound pool will be
consolidated to that pool.
Manual migration operations take precedence over FAST VP operations, which will be covered
later in the course. If a device is under FAST VP control, a migration will abort all FAST VP
movements in progress for the migrating device.
Virtual LUN VP allows thin devices to be moved between pools. The source thin devices can be
specified in a file, device group, storage group, or another pool. The target is always a thin pool.
The migration of VP volumes, or thin devices, is achieved by rebinding the device to a new thin
pool, and then relocating all the allocated extents, belonging to the device, to that pool.
As thin pools can be of varying RAID types, VLUN VP allows the migration of data from one
protection scheme to another, or from one drive technology to another, or both. This data
movement is performed without interruption to the host application accessing data on the thin
device.
Virtual LUN VP can be used to migrate Symmetrix thin devices, and thin metadevices,
configured as FBA in open systems environments.
Migrations can be performed between thin pools configured on all drive types including high-
performance Flash drives, Fibre Channel drives, and large capacity SATA drives. This feature can
also be a strong complement to automated tiering, as it enables administrators to override the
FAST VP algorithm and manually re-tier thin volumes based on new or unexpected performance
requirements.
Data is migrated to unallocated space in the target thin pool. There must be sufficient
unallocated space to accommodate thin device extents. As the are relocated, they are de-
allocated from the source pool, leaving additional unallocated space in that pool.
As discussed in the module on Virtual Provisioning, compressed tracks can only be migrated
as they are to a pool with compression enabled.
Uncompressed tracks are also migrated as they are to pools with or without compression
enabled.
This example was created on Solutions Enabler 7.4 before VP compression was introduced.
Thin devices 1A1 and 1A2 are bound to pool P1. Both devices are fully allocated.
Pool DG1R6SATA_Pl is free of Thin devices and all of its space is available for use. The
validate action confirms that the pool can accept the allocated tracks from thin devices F1
and F2.
Migrate the thin devices from pool DG3R1FC15_Pl to DG1R6SATA_Pl.
Thin devices are now bound to Pool DG1R6SATA_Pl. The old pool DG3R1FC15_Pl is now
empty and free of thin device allocations.
This module covered Virtual LUN Migration.

M08res01 Virtual LUN Migration.

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

M08res01 Virtual LUN Migration.

Hochgeladen von

Copyright:

Verfügbare Formate

This module focuses on Virtual LUN Migration.

Das könnte Ihnen auch gefallen