IBM XIV Storage System Copy Services and Migration

eceiving read requests from a host, when in fact it is the XIV Storage System doing ablock-by-block copy of the data, which the XIV is then writing onto an XIV volume.During the background copy process, the host server is connected to the XIV StorageSystem. The XIV Storage System handles all read and write requests from the host server,even if the data is not resident on the XIV Storage System. In other words, during the datamigration, the data transfer is transparent to the host and the data is available for immediateaccess.It is important that the connections between the two storage systems remain intact during theentire migration process. If at any time during the migration process the communicationbetween the storage systems fails, the process also fails. In addition, if communication failsafter the migration reaches synchronised status, writes from the host will fail if the sourceupdating option was chosen. The situation is further explained in the 7.2, “Handling I/Orequests” on page 187. The process of migrating data is performed at a volume level, as abackground process.The data migration facility in XIV firmware revisions 10.1 and later supports the following:► Up to four migration targets can be configured on an XIV (where a target is either onecontroller in an active/passive storage device or one active/active storage device). XIVfirmware revision 10.2 increased the number of targets to 16. The target definitions areused for both Remote Mirroring (RM) and data migration (DM). Both DM and RM functionscan be active at the same time. As already stated, an active/passive storage device withtwo controllers uses two target definitions unless only one of the controllers is used for themigration.► The XIV can communicate with host LUN IDs ranging from 0 to 512 (in decimal). Thisdoes not necessarily mean that the non-XIV disk system can provide LUN IDs in thatrange. You may be restricted by the ability of the non-XIV storage controller to use only 16or 256 LUN IDs depending on hardware vendor and device.► Up to 4000 LUNs can be concurrently migrated.Important: During the discussion in this chapter, the source system in a data migrationscenario is referred to as a target when setting up paths between the XIV Storage Systemand the donor storage (the non-XIV storage). This terminology is also used in RemoteMirroring, and both functions share the same terminology for setting up paths fortransferring data.7.2 Handling I/O requestsThe XIV Storage System handles all I/O requests for the host server during the data migrationprocess. All read requests are handled based on where the data currently resides. Forexample, if the data has already been written to the XIV Storage System, it is read from thatlocation. However, if the data has not yet been migrated to the IBM XIV storage, the readrequest comes from the host to the XIV Storage System, which in turn retrieves the data fromthe source storage device and provides it to the host server.The XIV Storage System handles all host server write requests and the non-XIV disk systemis now transparent to the host. All write requests are handled using one of two user-selectablemethods, chosen when defining the data migration. The two methods are known as sourceupdating and no source updating.Chapter 7. Data migration 187