Non-Disruptive Migration VMAX All Flash_VMAX3.pdf

Welcome to Non-Disruptive Migration to VMAX All Flash and VMAX3.
Click the Notes tab to view text that corresponds to the audio recording.
Click the Resources tab to download a PDF version of this eLearning.
Copyright 2016 EMC Corporation. All rights reserved. 1

This course covers Non-Disruptive Migration (NDM) from a VMAX to a VMAX All Flash Array
or VMAX3 array. Functionality is discussed in detail and examples of NDM using Unisphere
for VMAX and SYMCLI are presented.
Copyright 2016 EMC Corporation. All rights reserved. Non-Disruptive Migration to VMAX All Flash and VMAX3 2
This lesson covers the description of NDM, the configuration requirements, and the process
steps used to migrate data using NDM.
NDM is available in the HYPERMAX OS 5977 Q3 2016 SR. It leverages SRDF for migrating
data from VMAX to VMAX AFA/VMAX3 arrays. Only Open System/FBA devices can be
migrated with NDM. NDM works at a Storage Group level. It is native to HYPERMAX OS and
does not require any licensing. The applications hosts do not suffer any downtime at all.
The VMAX array is designated as the Source array and the VMAX AFA/VMAX3 array is
designated as the Target array for the purposes of NDM. NDM requires SRDF connectivity
between the Source and Target arrays. The application host which is accessing the devices
to be migrated should have FC connectivity to both the Source and the Target arrays. The
host should also have the supported Operating System and Multi-pathing software installed.
The devices to be migrated should have been presented to the host through Masking Views.
The control host should have SAN connectivity to both the Source and Target arrays.
Management of NDM can be performed using either using SYMCLI or Unisphere for VMAX,
both at version 8.3.
Currently supported Operating Systems and multi-pathing software are listed in this slide.
The high-level process flow for NDM involves environment setup, create, cutover and
commit. The individual operations and their resulting state is discussed in detail in the next
several slides. The symbols shown in the slide will provide a guide to the stage/phase of the
NDM process.
We are in the pre-Create phase of NDM.
Prior to starting a migration session, the new VMAX AFA/VMAX3 should be installed. SRDF
should be configured between the VMAX and the new array. This would involve configuring
RDF emulation/ports, connecting RDF ports to the SAN, and zoning the RDF ports on the
arrays to access each other. The host is accessing the Source device of the migration (on
the VMAX array).
The NDM Setup operation will create an empty Dynamic RDF group on the Source and
Target arrays.
The host has to be zoned to the FA ports on the Target array.
We are at the Create stage of NDM.
NDM is done at the Storage Group level.
When the create command is run:
The requisite number of new devices are created on the VMAX AFA/VMAX3 array. For example if there
are four devices in the Storage Group to be migrated, then four new devices of corresponding capacity
are created on the VMAX AFA/VMAX3 array.
Initiator Group (containing the host initiators), Port Group, Storage Group (containing the newly
created devices).
RDF device pairs are created between the devices in the VMAX and the devices in the VMAX
AFA/VMAX3. The VMAX devices are set to be R2s and the VMAX AFA/VMAX3 devices are set to be the
corresponding R1s. For this to succeed the VMAX devices need to have the dynamic RDF attribute set
on them. RDF device pairs are set in a pass-through mode.
The WWN of the VMAX device is assigned to the VMAX AFA/VMAX3 device as its Device External
Identity.
A Masking View is created on the VMAX AFA/VMAX3 array. This enables the host to access the VMAX
AFA/VMAX3 array.
Note that the names for the device masking entities (IG/SG/PG/MV) on the Target array will be
identical to that of the Source array.
The name of the SG that is being migrated should not exist on the Target array. The name of the
Masking View that is being migrated should not exist on the Target array.
If the name of the IG that is being migrated already exists on the Target array, then that IG on the
Target array should have the exact same initiators, child groups and port flags as the same-named IG
on the source array. Port flags that are not supported on the VMAX3 are ignored.
If the name of the PG that is being migrated already exists on the Target array, then the PG on the
Target array should have the initiators logged in into at least one port in the port group.
Refer to the interop rules in the Solutions Enabler guide for permissible devices and device states for
migration.
We are now in the post-create phase of NDM. As the External Identity of the VMAX
AFA/VMAX3 device is set to the WWN of the VMAX device, when the host is rescanned, it
discovers additional paths to the “same” device. This requires that the host have supported
multi-pathing software as listed in the table earlier.
We are in the Cutover Ready phase of NDM.
From the host’s perspective, it has multiple paths to the same device. The paths to both the
VMAX and the VMAX AFA/VMAX3 arrays are active. Reads and writes to the VMAX
AFA/VMAX3 are sent on to the VMAX over the RDF links. The writes are not stored locally on
the VMAX AFA/VMAX3 array. This is the RDF Pass-Through mode.
We are at the Cutover stage of NDM.
When the Cutover operation is performed, the paths from the host to the VMAX are made
inactive. The host cannot access the device down that path. But multi -pathing software will
send the IOs down the other available paths to the VMAX AFA/VMAX3 array. The RDF mode
is changed from Pass-Through to Synchronous. The VMAX device (R2) is set to WD as in
normal SRDF Synchronous mode. Data synchronization from the VMAX devices to the VMAX
AFA/VMAX3 devices is started. New writes are stored locally and are also sent
synchronously to the VMAX and acknowledged as usual.
The host is now accessing ONLY the VMAX AFA/VMAX3 devices.
We are in the Cutover Synchronized phase of NDM.
Data synchronization between VMAX and VMAX AFA/VMAX3 has been completed. There are
no invalid tracks for the R1 or R2. The RDF pairs operate in normal synchronous mode.
A Cancel operation with –revert can be run before the commit. This moves the host I/O
processing back to the Source array. All the entities created for migration are removed. It
reverts the environment to the state prior to the Create operation. Rescan should be run on
the host to remove the paths to the Target array, which will be now marked as dead.
We are at the Commit stage of NDM.
When the migration is committed, the Masking View for host access to the VMAX array is
removed. So the host loses access to the VMAX devices. The SRDF pairs are deleted. The
R1 or R2 attributes on the devices on VMAX and VMAX AFA/VMAX3 are removed. The WWN
of the VMAX AFA/VMAX3 device is assigned as the Device External Identity of the VMAX
device. This ensures that multiple devices do not exist on the SAN with the same identity.
Essentially the Device External Identities of the VMAX and VMAX AFA/VMAX3 devices are
swapped. The host continues to “think” that it is accessing the original Source device, when
in fact it is accessing the Target device. This is how the “non-disruptive” part of NDM is
achieved. The Dynamic RDF group created during the environment setup operation is left in
place. Subsequent migrations between the same two arrays do not need a setup operation.
The Recover operation can be run if a migration step fails due to a problem in the
environment. The recover command completes the failed operation.
Removing the environment cleans up the configurations performed by the environment
setup operation.
SRDF between the VMAX (Source) array and its remote array is permitted in the
Asynchronous mode during migration. The Create operation will convert the VMAX device to
an R21 from an R1. So the VMAX device will be an R2 for the VMAX AFA/VMAX3 device and
an R1 for the remote device.
In the cutover-synchronized state, SRDF between the VMAX AFA/VMAX3 array to new R2 is
allowed in the Asynchronous mode. The VMAX AFA/VMAX3 device becomes a R11.
This slide lists the current support restrictions for NDM.
This lesson covers performing NDM using Unisphere for VMAX.
An application is currently using the device 00A3 on the VMAX40K. A VMAX100K array has
been configured and installed. The goal is to non-disruptively migrate data from device
00A3 in the VMAX40K to the VMAX100K, using Unisphere for VMAX. SRDF has been
configured between the two arrays. Requisite zones between the RDF ports between the
two arrays have been created. The viability of SRDF between the two arrays has been
checked using the symsan –sanrdf list –sid 410 –dir all command. In this example
the host has already been zoned to the Target (VMAX100K) array.
1. In the Source SID > Storage > Storage Groups page, hover over Storage and select
“Migrations” from the drop-down menu
2. In the SID > Storage > Migrations page, select “>>” for more options
3. Select “Manage Environments”
4. In the Manage Environments dialog, select the Remote Array from the drop-down menu
(if more than one Remote Array is visible to the Source), then select “Setup” from the
drop-down menu
5. Select “Run Now” from the Add to Job List drop-down
These operations are performed from the context of the Source array.
The Setup operation creates an empty RDF group (group number 250 in this example)
between the Source (VMAX40K) and the Target (VMAX100K) arrays.
In the SID > Storage > Storage Groups page, select the Storage Group to be migrated. In
this example SG esxi-161_NDM_src1_410 contains the device 00A3 which has to be
migrated. This Storage Group is also in a Masking View for the Source VMAX array.
Click on “>>” for more options and select “Migrate”.
In the Destination panel of the Data Migration Wizard, select the Target array (VMAX100K,
SID:499 in this example) and the SRP on the Target array to which the Source device has
to be migrated. Click Next.
In the Create or Prepare panel of the Data Migration Wizard, select the “Create Data
Migration” radio button.
In the Summary page, verify the information and select “Run Now”.
The necessary device is created on the Target array. An SRDF pair is created between the
Source and the Target device, with the Source device being an R2 and the Target device
being an R1. The Create operation will also create an identically named Masking View, Port
Group and Host (Initiator Group) entities on the Target array (SID:499). The Host will of
course contain the Initiators of the Application host which is currently accessing the Source
(SID:410) array. The Port Group will contain the ports through which the host can access
the Target array.
We can see that a new device 0043 has been created on the Target array (SID:499). The
Source device on SID:410 is now an R2 to the Target device 0043 on SID:499.
We can see that the Create operation has created Masking entities on the Target array
(SID:499). The host should now have access to the Target device as well as the Source
device.
After a rescan we can see that the host has 4 Active paths to access the device 00A3 (naa
ending in 304133).
Two of the paths (06:69:1c and 06:69:18) are to the Source array and the other two
(17:6c:49 and 17:6c:09) are to the Target array.
The Create operation has set the Device External Identity of the Target (VMAX100K) device
to that of the WWN of the Source (VMAX40K) device. As a result of this, the host Target
device as additional paths to the Source device, rather than accessing it as a unique device.
So the Create operation has built the necessary Masking entities to give the host access to
the device on the Target array.
Shortly after the Create operation, the Storage Group reaches the CutoverReady state. In
the view shown in the slide we can see that the Source array is SID:410, Target array is
SID:499; Source device is 00A3, Target device is 0043.
After the Create operation we can see that the Target device has been given the Device
External Identity of the Source device. This is key for the application host to “think” that it
has more paths to the SAME device and NOT new paths to a DIFFERENT device!
From the SID > Storage > Migrations page, select the Storage Group. Select “Cutover”. In
the Cutover dialog select “Run Now” from the drop-down. You can then view the Task
Details.
We can see that after Cutover, the paths to the Source array (SID:410) are now
unavailable to the host. All Host IO is now directed only to the Target array (SID:499)
which is the VMAX3 array.
Right after the Cutover operation, the State goes to “Migrating”. When data synchronization
from the R2 (Source VMAX40K device) to the R1 (Target VMAX100K device) is completed,
the state moves to “CutoverSync”.
From SID > Storage > Migrations page, select the Storage Group. Click on “Commit”. In
the Commit dialog box, select “Run Now” from the drop-down. You can monitor the
progress in the Task Details window.
The Commit operation has removed the Masking View for the Host from the Source array.
The Target device is permanently assigned the External Identity of the Source device. The
RDF pairing between Source and Target is deleted. The Source is permanently assigned the
External Identity of the Target device.
This lesson covers performing NDM using SYMCLI.
An application is currently using device 00A4 on the VMAX40K. A VMAX100K array has been
configured and installed. The goal is to non-disruptively migrate data from device 00A4 in
the VMAX40K to the VMAX100K, using SYMCLI. SRDF has been configured between the two
arrays. Requisite zones between the RDF ports between the two arrays have been created.
The viability of SRDF between the two arrays have been checked using the symsan –sanrdf
list –sid 410 –dir all command. In this example the host has already been zoned to
the Target (VMAX100K) array.
The management host has access to both the Source and the Target arrays as can be seen
from the output of the symcfg list command.
The migration environment was setup earlier to migrate device 00A3 using Unisphere for
VMAX. The migration environment was not removed at the end of the migration. So here
we validate the environment.
The SG esxi-161_NDM_src1_410 was already migrated using Unisphere for VMAX. We
would like to migrate the SG esxi-161_NDM_src2_410. This Storage Group is in a Masking
View on the Source array, for host access.
We verify that device 00A4 is contained in the SG esxi-161_NDM_src2_410.
Validate verifies that the necessary masking entities can be created on the Target array.
As the output indicates, the necessary Initiator Group, Port Group, Device and Storage
Group are created on the Target array. A new device matching the Source device is created
on the Target array.
An RDF device pair is created between the migration Source device and the migration
Target device. Listing of the data migration shows that the NDM is now in a Created state.
A Masking View for the host to access the Target device has also been created. We can see
that new Masking View and Storage Group has been created on SID:499. Note that the
names for the device masking entities will be identical to that of the Source array. The
existing Initiator Group and Port Group from the prior migration (using Unisphere for VMAX)
have been re-used in the new Masking View.
Examining the SG created on the Target array shows that a new device 044 has been
created on the Target array.
The Create operation has created an SRDF pairing between the Source device 00A4 and the
Target device 0044. The Source device has been made the R2 and the Target device has
been made the corresponding R1.
The WWN and External Identity of the Source device stay the same.
The Target device on the VMAX100K has been assigned the External Identity of the Source
device on the VMAX40K.
When the host is rescanned after the Create operation, the Masking View created by the
Create command has provided two additional paths to the host to access the device. The
newly created device on the Target array has been assigned the same WWN as the Source
device. This leads the host to “think” it has four Active paths to the SAME device.
The command lists the state of the Storage Group from both arrays perspective. As can be
seen in the output, it has moved into the CutoverReady state. In the CutoverReady sate
host I/Os can be directed to either the Source or the Target array by the multi -pathing
software. HYPEMAX OS will ensure that I/Os to the Target array are serviced by the Source
array (SRDF Pass-Through mode).
The Cutover operation takes the RDF device pair out of the SRDF Pass-Through mode. All
IOs are now directed to the Target device on the VMAX100K. Synchronization of data from
Source VMAX40K to Target VMAX100K is started.
Immediately following Cutover, the SG will be in a Migrating state until data
synchronization is completed. After synchronization the state moves to CutoverSync.
Committing the migration removes the Masking View from the Source array. So the host no
longer has access to the Source device. The SRDF pair is deleted. The Source and the
Target device are converted back to non-RDF devices.
As can be seen from the output, the Masking View and RDF pair have indeed been
removed.
The Source device on the VMAX40K is permanently assigned the Device WWN of the Target
device as its Device External Identity.
The Target device on the VMAX100K is permanently assigned the Device WWN of the
Source device as its Device External Identity.
This demo covers performing NDM operations using Unisphere for VMAX.
This course covered Non-Disruptive Migration from VMAX to VMAX All Flash Array or VMAX3
array. Functionality was discussed in detail and examples of NDM using Unisphere for VMAX
and SYMCLI were presented.
This concludes the training. Proceed to the course assessment on the next slide.

Idioma

¡Te damos la bienvenida a Scribd!

Non-Disruptive Migration VMAX All Flash_VMAX3.pdf

Cargado por

Información del documento

Fecha en que fue cargado

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Descripción:

Copyright:

Formatos disponibles

Non-Disruptive Migration VMAX All Flash_VMAX3.pdf

Cargado por

Descripción:

Copyright:

Formatos disponibles

Títulos relacionados

Welcome to Non-Disruptive Migration to VMAX All Flash and VMAX3.

Click the Resources tab to download a PDF version of this eLearning.

Copyright 2016 EMC Corporation. All rights reserved. 1

NDM is done at the Storage Group level.

When the create command is run:

The host is now accessing ONLY the VMAX AFA/VMAX3 devices.

3. Select “Manage Environments”

5. Select “Run Now” from the Add to Job List drop-down

Click on “>>” for more options and select “Migrate”.

Intereses relacionados

Documentos similares a Non-Disruptive Migration VMAX All Flash_VMAX3.pdf

Más de Shahbaz Alam

Popular en Computers

Títulos relacionados

Calificar

Compartir