Chapter 8. Planning data migration
The planning and methods of data migration for the storage system vary by environment.
When you plan for data migration, consider the following factors:
Note: The following lists do not cover every possibility. They provide a high-level view of some of the tools
and factors that you can consider when you move data.
Data
• How much data is to be migrated?
Operating system
• Is it a IBM Z or UNIX system? Consider using Remote Mirror and Copy functions such as Metro
Mirror, Global Mirror, or some variation of a logical volume manager.
• Is it z/OS? Consider using DFDSS, though there are many choices.
• Is it VM? Consider using DASD Dump Restore or PTAPE.
• Is it VSE? Consider using the VSE fastcopy or ditto commands.
Your system administrator selects the data migration method that is the best compromise between
efciency and impact on the users of the storage system.
Storage system
• Are the storage systems involved the same type with the same level of licensed machine code?
• Are the storage systems different? If the storage systems are different, ensure that the new
conguration is large enough to accommodate the existing data. You also want to ensure that the
virtual disks are similar in conguration to the disk drives that they are replacing.
Time and complexity
• What duration of service outage can be tolerated? Typically data migration requires that updates or
changes cease while the movement occurs. Also, depending on the amount of data that you are
moving and your migrating method, data might be unavailable for an extended time, even several
hours.
• Does the complexity and time that is involved require the services of IBM through International
Global Services? Contact your technical support representative for more information.
When you replace existing storage, partition the storage so that the virtual disks are similar in
conguration to the disk drives that they are replacing. New congurations must be large enough to
accommodate the existing data.
You might want to take advantage of this opportunity to do some remapping. The allocation and
distribution of data are not required to be a straight one-to-one relationship, although that is possible. For
instance, you can take advantage of using a maximum of 255 logical subsystems whereas the prior
limitation was 32 logical subsystems.
Consider creating any new xed block (FB) volumes with T10 DIF protection. This protection can be used
on volumes to which data is migrated, even if the current host server volumes are not T10-protected. T10
DIF-protected volumes can be used even if the host server does not currently support T10 DIF.
©
Copyright IBM Corp. 2019 111
To Next Page
Loading...
Need help?
General