THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne, EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology, Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta, the EMC logo, and where information lives, are registered trademarks or trademarks of EMC Corporation in the United States and other countries.
All other trademarks used herein are the property of their respective owners.
This course provides an introduction to the Open Replicator application. It also includes an overview of Open Replicator architecture, features, functionality and how Open Replicator is used to perform a Federated Live Migration.
Upon completion of this course, the student should be able to provide an overview of Open Replicator. Also, the student will be able to identify Open Replicator management software offerings, and describe Open Replicator’s business benefits and considerations.
EMC’s Symmetrix Open Replicator provides a method for copying device data from various types of arrays within a Storage Area Network (SAN) to or from a Symmetrix DMX or VMAX array. Symmetrix Open Replicator is a tool that can be used to migrate data from older Symmetrix arrays, CLARiiON or VNX arrays, and certain third-party storage arrays to a DMX or VMAX.
Data migrations can be very complex projects, and require careful planning. Failure to identify and perform necessary steps can result in data unavailability or data loss.
Open Replicator operations are controlled from a local host attached to the Symmetrix DMX or VMAX Family array. Data copying is accomplished as part of the storage system process and does not require host resources. The data can be copied online between the Symmetrix array and remote devices, allowing host applications, such as a database or file server, to remain operational during the copy process.
The Symmetrix Open Replicator command symrcopy provides a method for copying device data from various types of arrays within a Storage Area Network (SAN) infrastructure to or from a Symmetrix VMAX storage array. For example, Symmetrix Open Replicator is used to migrate data from older Symmetrix arrays, CLARiiON arrays, and certain third-party storage arrays to a new Symmetrix VMAX storage array.
Data migrations are often complex operations and require careful planning and execution of predetermined procedures. Failure to identify and perform necessary steps, or work within supported configurations can result in data being unavailable or lost.
For detailed interoperability information, refer to the E-Lab Interoperability Navigator (http://elab navigator.EMC.com).
Rather than using the terms “source” and “target,” which might be confusing in the Open Replicator context, we use the terms “control” and “remote,” where the Control Device always resides on the Symmetrix running Open Replicator.
The Remote Device is passive and does not require any software.
Open Replicator copy direction is defined by push and pull. A push sends data from the Control Symmetrix to the remote storage array. A pull fetches data from the remote storage array to the Control Symmetrix. An incremental copy is an option that only copies changed tracks since the last activate. This is only available during a push operation.
Open Replicator does not depend on the device geometry of the Remote Device. There are no restrictions related to RAID types or striping. For example, a striped RAID 1 metavolume can transfer data to a concatenated RAID 5 metavolume.
Hot or cold refers to the state of the Control Device during an operation. A hot state means the Control Device is read/write online to the host while the copy operation is in progress. A cold state means the Control Device is not ready to the host (offline) while the copy operation is in progress.
To ensure data integrity, the data on the remote array should not be changed during an Open Replicator session.
While the host running the Open Replicator commands does have visibility to the Symmetrix devices, it does not see or control the Remote Devices.
During a hot push or pull, the Control Device may be read/write enabled. During a cold push or pull, the Control Device is set to a “User Not Ready” state.
Throttling allows users to limit SAN bandwidth usage by Open Replicator. If left unchecked, Open Replicator consumes the full bandwidth of the SAN. It performs very fast, which could be a problem if the SAN is being shared by hosts performing I/O to the local volumes on the Controlling Array.
Pace values range from zero (0) to nine (9). A pace of zero (0) means that the session is not throttled at all. The default pace for an Open Replicator session is five (5).
Ceiling values range from zero percent (0%) to one hundred percent (100%). A zero percent (0%) setting on the port indicates the port will not be used for Open Replicator. A one hundred percent (100%) setting on the port allows Open Replicator full bandwidth usage, if necessary. The default ceiling value is None, which means that an Open Replicator session will be regulated by the Pace setting.
When an Open Replicator session is created, the Symmetrix marks the tracks on the devices participating in the session. These tracks are considered protected, which means that after activation, these tracks must be moved to or from the Control Device. Access to the tracks is only permitted once the tracks have been moved.
Activation is the step that marks the point-in-time when the data is secured. If background copy is enabled, data transfer will start immediately after activation. This is the default action. If background copy is not enabled, data transfer is undertaken only when the host on the Symmetrix tries to change the protected data.
The recreate action is similar to a create action. However, only tracks that have changed since the last activation are protected. It is only permitted if the session was created as a differential session.
The terminate action ends the Open Replicator session. The information about the session is deleted, and the relationship between the Control and Remote Devices is terminated.
The restore action initiates data flow from the Remote to the Control Device after a differential hot push. Instead of pushing the changes since the last activation to the remote site, the restore action will overwrite the changes by pulling data from the Remote to the Control Device.
Storage ports between control and remote Symmetrix arrays must be zoned. Control Symmetrix fiber ports act like hosts to the Remote array.
A SAN connection between the controlling Symmetrix and the Remote array must be created for Open Replicator data transfer to occur. The FA ports on the controlling Symmetrix appear to the Remote array’s ports like host computers.
During a hot pull or push, each FA that has access to the Control Devices must have access to the corresponding Remote Devices. During data transfer, a track that has not yet been transferred is referred to as a protected track. If there is a write to a protected track on the control host, the FA is responsible for pulling or pushing the track from the Remote Device before the write is allowed.
The session will fail when any director cannot see the Remote Device.
During a cold pull or push, each FA that has access to the Control Devices need not have access to the corresponding Remote devices. As long as one FA from the Control Device can reach the Remote Devices, the cold push or pull will work.
Masking is the process for storage arrays to make their volumes available to a host connected to the fiber port. Masking procedures are vendor dependent, and can be performed using vendor specific tools. Unlike the zoning process, EMC does not have a single tool that performs masking for different vendor arrays. Masking must be performed on the Remote array to provide device access to the Fibre Channel port of the Control array.
For hot push or pull operations, all ports with access to the Control Devices must be able to access the Remote Devices.
For cold push and pull, one or more ports with access to the Control Devices must be able to access the Remote Devices.
Let’s take a moment to discuss the various deployment options for Open Replicator for Symmetrix.
Open Replicator can push data volume out from a Symmetrix, either in a live mode or from a static copy. For a live push, no local point-in-time copies of the volumes are required. The Symmetrix creates logical point-in-time copies without having to allocate additional disk space, and I/O is permitted against the source volume during the transfer. For BCV mode push, up to 16 remote copies of the local volume can be made, and those remote copies can be incrementally updated.
In pull mode, the Symmetrix volume can again be in a live state during the copy process, which makes either restoring remotely vaulted volumes or migrating from other storage platforms very fast and efficient. The local hosts and applications can begin to access the data as soon as the session begins, even before all of the data has been copied over. Open Replicator can also copy to a static Symmetrix volume.
EMC’s Open Replicator for Symmetrix has several features. It delivers key requirements for platform-independent replication by being fast, simple and open.
It addresses each challenge listed on the slide. These challenges are addressed at the appropriate service level to align with business requirements and offer improved data migration and distribution, remote vaulting of data solutions, and dynamic management of a tiered storage infrastructure.
With Open Replicator for Symmetrix, it is possible to create point-in-time copies of local Symmetrix volumes and transfer them to or from any qualified storage array, in any place that you can extend your Storage Area Network (SAN) or Wide Area Network (WAN).
When migrating data from older arrays to a newer Symmetrix, it is not necessary to wait for the data to complete the copy before accessing it locally on the new array.
Open Replicator cannot be used to perform intra-array data replication. It is designed for moving data between storage arrays.
The chart on this slide shows comparisons between performance, availability and functionality for Open Replicator, SRDF, Host and Network based replication.
This module covered an overview of Open Replicator as well as the terminology that will be used throughout this training course. Open Replicator replication considerations were also presented in this module.
Open Replicator for Symmetrix allows you to push data from a static Symmetrix volume to a remote target. The source copy can either be a TimeFinder family BCV, or a source volume with no I/O being performed against it.
The advantage of using the TimeFinder family is that it enables parallel access to your production data. Using TimeFinder/Mirror or TimeFinder/Clone along with TimeFinder/CG allows you to create a consistent set of volumes, created at precisely the same point in time, without affecting production applications. Once Open Replicator for Symmetrix copies these volumes to the remote targets, you can incrementally update the BCVs using standard TimeFinder family commands, then send only the updates to the remote arrays.
Up to 16 remote copies can be simultaneously made from each source volume.
To extend the value of remote vaulting and distribution of data with Open Replicator for Symmetrix, you have the option to perform a “live” push. This means you don’t have to create a local copy of the production volumes, and that the production applications can keep accessing the source volumes without interruption.
The primary differences between Live and BCV modes are that in Live mode, you don’t need a static source volume or second copy of the data, and you can only copy to a single target location, while in BCV mode, up to 16 remote copies can be made at once from a single source volume.
One important use of this point-in-time volume pull capability is to migrate data from older storage platforms to the latest Symmetrix systems. In this example, you simply install the Symmetrix between the hosts and the storage being migrated off of it, point the applications to the new Symmetrix, and start the migration process.
You can use Open Replicator for Symmetrix to recover local volumes in the event of logical or physical loss of data at the local site or, as in this example, for migration purposes. In Live mode, you can access the local Symmetrix volumes as soon as the copy session begins. The Symmetrix will copy all data from the remote storage device in the background while servicing all host I/O requests in the foreground. If the host requires access to data that hasn’t already been copied, the Symmetrix will retrieve that portion of the volume to satisfy the request.
Open Replicator includes a feature that protects against potential data loss due to a SAN failure or other connectivity problems during an active Open Replicator live pull session. The “donor update” feature enables arrays to propagate (update) writes to the local device back to the remote device (donor) as data is being pulled from the remote device. When enabled, donor update ensures consistent data between, and on, both the local and remote devices during the data movement process. As a result, no new data written to the local device will be lost during a SAN failure.
Open Replicator Hot Pull permits host access of the Control Devices while data transfer is in progress. After a hot pull session is activated, data on the Control Device is pulled from the Remote Device before a new read or write to the Control Device is permitted. An attempt to read or write data that has not already been transferred will cause a priority data move from the Remote to the Control Device before the write is allowed. This behavior is known as “Copy on First Access.” Several copy modes are permitted during a hot push. The default behavior is to start a background copy as soon as the session is activated.
The nocopy option results in control data not being copied in the background. Data is only moved when a new read or write is directed against the Control Device.
The donor update option permits new writes to the Control Device to be pushed to the Remote Device. This option results in the remote site containing the most current data. If the data pull is unexpectedly aborted because of a failure of network connectivity, there is no loss of the data that was written to the Control Device between the times when the session was activated and aborted.
Federated Live Migration (FLM) combines the capabilities of Open Replicator Hot Pull, PowerPath, and host application redirection enabling non-disruptive data migration from older Symmetrix DMX arrays running Enginuity 5671, 5773, or newer VMAX arrays running 5876 Enginuity.
Open Replicator Cold Pull operation is not permitted unless the Control Device is placed in a “User Not Ready” state. The background copy is enabled by default. The differential copy is not a viable option against a cold pull action.
Open Replicator Hot Push permits host access of the Control Devices while data transfer is in progress. After a hot push session is activated, data on the Control Device is moved to the Remote Device before a new write to the Control Device is permitted. An attempt to overwrite data that has not already been transferred causes a priority data move from the Control to the Remote Device before the write is allowed. This behavior is known as “Copy on First Write” because the data move is performed only the first time that the write is attempted. Subsequent writes to the same location will not cause data to be transferred. Several copy modes are permitted during a hot push.
The default mode for hot push is background copy. Data transfer starts immediately after session activation.
The nocopy option results in control data not being copied in the background. Data is only moved when a new write is directed at the Control Device.
The precopy option starts the data copy as soon as the session is created. This results in fewer tracks having to be moved when the session is activated at a later time.
The differential option, enabled by default, causes a record of the changes since the last session activation to be maintained on the control Symmetrix. Later, a differential push can be initiated by recreating the session after the first data copy is complete.
For differential push operations, a restore will cause the changed tracks to be restored from the Remote Device.
Using the –consistent option creates a consistent point-in-time copy.
The Open Replicator Cold Push operation is not permitted unless the Control Device is placed in a “User Not Ready” state. This ensures that the data on the Control Device does not change while Open Replicator is transferring data.
The Open Replicator command symrcopy accepts a number of arguments, which governs the behavior of the data transfer. By default, a background copy is enabled. This option causes a data transfer to commence immediately after a session is activated. The data transfer continues until it is complete.
A cold push is the only kind of data transfer that allows a single source to transmit data to multiple targets.
The first time data is transferred from the Control to the Remote Device, the copy is always a full copy. The use of the differential option permits incremental changes to be sent across on subsequent cold pushes, as long as the initial session has not been terminated.
For differential push operations, a restore causes the changed tracks to be restored from the Remote Device.
Using Cold Push with TimeFinder Snap Virtual Devices is an alternative to hot pushes from an active standard device. Hot Push requires that all paths with access to the Control Device have access to the Remote Device.
For a cold push, only one of the directors with access to the Control Device must have access to the Remote Device, so the SAN configuration is simpler.
With TimeFinder Snap, a write to the Source Device causes a copy of the original source data to go to a Save device, which resides inside the local array. This action is a “Copy-On-First-Write” and the additional time required to perform this write is called the Copy-On-Write penalty. In contrast, during an Open Replicator hot push, the original data is copied to the Remote Device before the Source Device can be altered. This is also a case of Copy-On-First-Write, but since the data must be moved to a remote array, the performance penalty can be higher.
To run an Open Replicator Cold Push session with VDEVs using TimeFinder Snap and Open Replicator, begin by creating a TimeFinder Snap session using the symsnap create command. Create an Open Replicator session using the symrcopy create command, and define the Snap device as the Control Device. This creates an open Replicator protected session on the VDEV. Next, activate the TimeFinder Snap session with the –not_ready option. This causes the VDEV to be inaccessible to the host. If consistency is required, specify the -consistent option. Once you activate the Open Replicator session using the symrcopy active command, data begins copying from the Control to the Remote Device. When the session is complete, the Remote Device will contain a point-in-time copy of data from the time the snap session was activated. Once the Open Replicator session has finished copying all of the data, the sessions can be terminated or recreated and reactivated as many times as needed.
Any of the devices listed on this slide can be Open Replicator Control Devices. The RAID protection of the volumes is unimportant. The product documentation lists restrictions that may be associated with specific types of devices. For instance, a TimeFinder/Snap Virtual Device can only be used for cold pushes.
Open Replicator operations may conflict with the use of other replication products such as TimeFinder/Clone, TimeFinder/Snap and SRDF. Since TimeFinder and SRDF cause devices to be inaccessible for reads or writes during certain operations, Open Replicator cannot function when those operations are in use.
To ensure data integrity, a Remote Device should not be accessed while it is participating in an Open Replicator session. Since the control Symmetrix cannot ensure that the data on the Remote is not being changed while Open Replicator is transferring data, the user must take this action to ensure data integrity.
The table in this slide summarizes the common guidelines associated with Open Replicator operations. A number of the default options have changed over the life of the product. For more detail on each option, please refer to the Solutions Enabler Migration CLI Product Guide.
This module covered Open Replicator operations and deployment options. Device guidelines for control and remote Open Replicator volumes were also discussed.
With Enginuity 5876 and higher, Symmetrix VMAX 40K and 20K now have the RecoverPoint Splitter directly integrated into the arrays. This joins the RecoverPoint Splitter with the VMAX 10K with Enginuity 5875.
RecoverPoint Splitter integration is much simpler and more efficient than deploying host - or fabric-based splitters. With the RecoverPoint integration, the VMAX 40K and 20K arrays can replicate to heterogeneous arrays.
Additionally, all the RecoverPoint functionality, which includes continuous data protection (CDP), continuous remote replication (CRR), and concurrent local and remote (CLR) replication, are now available for the entire Symmetrix VMAX series.
The Symmetrix splitter uses EMC Symmetrix Open Replicator to split writes to RecoverPoint. Open Replicator for Symmetrix VMAX provides a method for copying device data from various types of arrays within a Storage Area Network (SAN), to or from a Symmetrix VMAX storage array.
One Open Replicator session is required for each LUN that is replicated by RecoverPoint.
Splitting occurs at the Symmetrix FA port, therefore, RecoverPoint must be zoned to the same FA ports as the replicated hosts.
Open Replicator Hot Push was modified to support the RecoverPoint splitter functionality. The Symmetrix splitter uses Open Replicator for Symmetrix in continuous push mode to split writes to the RecoverPoint Appliance. Also, it uses always push old mode when image access is enabled.
Open Replicator copies data in sessions across the SAN infrastructure. When RecoverPoint with Symmetrix splitter is deployed, the RecoverPoint appliances act as if they were the remote storage array by presenting virtual target and virtual remote devices.
A LUN must be tagged to be used with the Symmetrix splitter. If a LUN is attached to the Symmetrix splitter and not tagged as being used by RecoverPoint, warnings and errors will occur, and the system will not work properly. Tagging can be done using Solutions Enabler, or at the Symmwin level.
Starting with Solutions Enabler 7.6, a non-concurrent SRDF/R1 device can be tagged for RecoverPoint, and a RecoverPoint tagged device is allowed to become an SRDF/R1 device. One can use the same source volume for both RDF (for disaster recovery) and RecoverPoint CDP (Continuous Data Protection) for local operational recovery.
This feature applies to:
• Both static and dynamic SRDF devices
• All SRDF modes; synchronous, asynchronous, and adaptive copy, as well as
• All VMAX platforms; VMAX 10K, VMAX 20K and VMAX 40K.
This slide describes the data flow from the application host to the production volumes, and how the RecoverPoint Appliance accesses the data as part of the process.
An application server issues a write to a LUN that is being protected by RecoverPoint. Writes sent to the production volume are split and sent to the production volume and to the RPA. This write splitting occurs at the Symmetrix Fibre Channel Director/Interface Adapter (FA) port, then is sent to the RecoverPoint Appliance.
As a requirement of this architecture, RecoverPoint Appliances must be zoned to the same FA ports as the replicated hosts.
The Symmetrix splitter is based on Open Replicator. Open Replicator is a component of EMC Solutions Enabler, which is the command-line-interface software suite used for managing a Symmetrix storage environment. It is also part of Symmetrix Enginuity.
When Open Replicator functions as a splitter, RecoverPoint acts as the remote array and presents virtual remote devices to Open Replicator. This allows the RPA to acknowledge writes to the remote devices, which, in RecoverPoint terminology, are called replica volumes. For more information about Open Replicator, refer to the EMC Solutions Enabler Symmetrix Migration CLI Product Guide.
To be replicated with the VMAX RecoverPoint splitter, a volume must be identified to the Symmetrix array as a RecoverPoint device. Device tagging informs the Symmetrix array that the device is reserved for RecoverPoint replication. Untagged devices are not allowed to create Open Replicator sessions with RecoverPoint.
This module covered the Open Replicator modes for RecoverPoint, as well as RecoverPoint integration with the Symmetrix VMAX. Also presented in the module, was a explanation of a write I/O flow within a Symmetrix splitter.
The symrcopy command is part of the Solutions Enabler command set, and is used to manage Open Replicator sessions. The slide shows examples of the Create, Activate, Terminate, Recreate and Restore SymCli session commands.
The examples are using an ascii file (–file <filename>) that identifies the pairing information for the Control and Remote Devices. Remote Devices in the file are specified by "LUN WWN" and the Control Devices are specified by Symmetrix ID.
Unisphere for VMAX provides users with the same EMC-standard look and feel. Unisphere for VMAX is contextual and simple to navigate. With Unisphere, users can easily and rapidly manage and monitor all Symmetrix VMAX Open Replicator features.
EMC provides Symmetrix customers several solutions to perform migrations. These are grouped into a convenient and easy-to-use software package, called Symmetrix Migrator.
The Package contains several software products that many customers might already use, such as, Open Replicator/LM with the Federated Live Migration feature, z/OS Migrator, Open Migrator/LM and SRDF/DM.
These products offer comprehensive support for any environment, including open systems and Mainframe, as well as mixed environments. These products offer data and/or application migration support, whether it be on the host or on the array.
Federated Live Migration ties together the array-based migration of the data, provided by EMC Open Replicator for Symmetrix, with the host-level application redirection, provided by multi-pathing software, such as EMC PowerPath. It does this by using a set of coordinated commands through EMC’s SymCli to initiate the migration session and coordinate the host application redirection from one central point, making the migration truly non-disruptive. Additionally, Federated Live Migration supports a number of pre-qualified stacks of arrays, and host operating systems that help eliminate time-consuming remediation processes. Federated Live Migration is flexible. It’s capable of supporting combinations of migrating thick-to-thick, thick-to-thin, and thin-to-thin, as well as consolidating multiple systems to one Symmetrix.
Federated Live Migration has several features and benefits. It provides nondisruptive data migration from Symmetrix DMX to VMAX, or VMAX to VMAX.
A planned outage must be taken at a convenient time for restoration of native identities. It leverages intelligence of storage array and host multi-pathing, and supports thick to thin migrations with Zero Space Reclaim. It also manages both array and host redirection with EMC’s SymCli command set.
FLM has unique requirements that must be met before a migration is attempted. Procedures vary between Operating Systems, therefore follow the process for your particular environment.
Data migrations are often complex operations and require careful planning and execution of predetermined procedures. Failure to identify and perform necessary steps or work within supported configurations can result in data unavailability or data loss.
Use the Symmetrix Procedure Generator for your environment. This tool will build a procedure that will help the business meet it’s unique FLM requirements.
The Symmetrix Procedure Generator is a stand-alone utility that creates procedures to help manage your EMC Symmetrix systems, which include;
• Setting up a host environment, • Managing storage, • Managing SRDF, • Managing TimeFinder, • Managing Symmetrix hardware, • Performing Mainframe operations, and • Managing Federated Live Migrations
This Procedure Generator eliminates the need to search through manuals by providing you with a customized procedure for your configuration. This tool is available to all Symmetrix customers (https://support.emc.com). It is updated regularly by EMC and contains a 30-day expiration timer to ensure you always have the latest validated procedures.
Once installed, double click the Symmetrix Procedure Generator icon on your desktop. Select the options for your procedure. The selected example on this slide is showing that we will create a Federated Live Migration procedure. This procedure will create a detailed Microsoft Word or Adobe PDF procedure file for your environment.
A migration might be needed to support a technology refresh, a data center move, a storage system consolidation, virtualization of servers, or integrating two IT environments due to an acquisition.
The challenge is that all of this must be done while keeping business applications online. It is necessary to reduce the complexity and cost associated with migrations by simplifying and shortening the planning cycles. FLM is one of the options EMC offers to achieve this objective.
The most common use cases for Federated Live Migration are one-way data migrations in support of data center consolidations and technology refreshes.
Some customers work to keep all the data for a given application in the same array, in which case, the growth of data in one array may need some applications to be moved to other storage. This is another example of where FLM would be useful.
Federated Live Migration operates by having the new VMAX device assume the identity and geometry of the donor Symmetrix DMX device, and then performing an Open Replicator hot pull operation as the data movement method between new and donor arrays. The new VMAX device must be equal or larger than the donor DMX device for the migration operation to be allowed.
The donor storage must be a Symmetrix, and the donor device cannot be involved in any type of local or remote replication. This restriction is necessary to ensure data integrity on the new device, as an Open Replicator pull session will not be able to copy consistent data if new data is written to the donor DMX device while the session is running.
The host may run indefinitely with federated identity on the new VMAX devices; however, EMC recommends that the spoofed identity be removed as soon as the migration is complete. Leaving the identity spoofing in place long-term has the potential to cause confusion for system administrators or other users who may not be familiar with the details of FLM, and how device identities are spoofed.
This next two slides will show, at a high level, a FLM Migration Flow and the steps required to migrate an application environment from an old DMX to a new VMAX platform. Each illustration is numbered.
The first illustration shows an application host running production on a DMX array.
The second image illustrates a zone that was created between the VMAX front-end port and the DMX front-end port (FAs).
Illustration number three shows that a zone has been created between the HBA of the application host and the front-end port of the VMAX array.
Step four shows the new device has been created on the VMAX. It’s mapped to the front-end port, however, it’s not yet masked to the HBA.
Between step four and five, a FLM session has been created, resulting in the new VMAX device being set to host as passive.
In step five, the VMAX devices are masked to the application host.
Upon activating the FLM session, the new VMAX device is set to host as active. The DMX device is set to host as passive. An Open Replicator Hot Pull session with Donor Update has been started on the VMAX. At this time, host I/O starts flowing to the VMAX device (shown in step six). New writes to the VMAX device will also be written to the DMX device because Donor Update is in use.
Once the migration completes, the FLM session reaches a copied state. Until the session is terminated, the old DMX devices continue to be updated. At this time, the session can be terminated.
The old DMX device can now be removed from the application host. The masking and zoning relationships with the application host can also be removed. The DMX can now be physically removed from the SAN.
A FLM session can be failed back automatically or manually. If an error occurs after activating the session, the session automatically will fail back.
A FLM migration can also be manually canceled and full data access to the donor DMX device can be restored. A failback command with the –migrate option will stop the FLM session, restore the donor DMX devices to host active mode, and restore the new VMAX devices to host passive mode.
The command does not affect the device WWN, director port, or device geometry on the new VMAX device. Any existing device reservations will be restored to the donor DMX device. This command can be run from any state in which the FLM session is actively copying data, or when the copy has completed. After the failback command completes, the FLM session will be in the Failed Back state from which only the terminate operation will be available.
Failback is not permitted once a FLM session has been terminated.
FLM is a technically complex product, though the steps to implement it are simple. Before attempting an implementation, consult the documents listed on this slide.
The Solutions Enabler Migration CLI Product Guide is the primary document for theory of operations, command syntax and requirements and restrictions for using FLM.
The Support Matrix provides the latest information on supported operating systems, file systems and logical volume managers
The Federated Live Migration Technical Overview notes contain a detailed description of FLM theory and command options.
This module covered the software packages that make up the Symmetrix Migrator application set and presented an overview of what Federated Live Migration is. Also presented in the module are considerations and benefits for FLM.
