Migrating storage partitions between systems

IBM Storage Virtualize supports the non-disruptive migration of storage partitions between systems. This enables a partition to be migrated from one Storage Virtualize system to another without any application downtime. The migration procedure requires connectivity between the source and target IBM® Storage FlashSystem.

Migration enables storage partitions from a source system to a different system location in the following situations:

All the resources that are associated with the storage partition are relocated to the specified storage system location.
Host I/O is no longer served by the source system. I/O are served by the migrated storage partition on the specified system location.
The active management system and preferred management systems point to the migrated storage partition.
At the end of the migration process, the storage partitions is removed from the source system.

Migration enables storage partitions in the following situations:

When upgrading system hardware from older systems to newer ones.
Load-balancing by migrating storage partitions from overloaded systems to other systems.
Data centre environment or use-case specific scenarios that require storage partition migrations from a source system to a specified target system.

For more information, see chpartition command to automate the procedure of migration of storage partitions. This automates intermediate steps, such as setting up Fibre Channel partnerships between the systems.

Limits and restrictions

Currently draft storage partition, policy-based high availability, or data replication relationships are not supported for automated migrations.
Only one storage partition can be migrated at a time from a system. Any consecutive migrations that are attempted get queued, and are scheduled automatically as per the sequence of invocations when the earlier migrations complete.

Prerequisites

Before you can use non-disruptive system migration function, ensure that the following prerequisites are met:

Use the lspartnershipcandidate command and make sure that both source and target systems are correctly zoned and are visible to each other. For more information, see lspartnershipcandidate command.
Although the systems are visible to each other, an identified system can have multiple suitable storage pools that are able to host the migrated storage partition. Establish a pools between systems on the current source and target systems. For more information, see chmdiskgrp command.
Use the lspartnership command and ensure whether the source and a specific system are already in partnership. For more information, see lspartnershipcommand.
Make sure that both systems have certificates that are authenticated and trusted for RESTful API based communications. For more information, see mktruststore command.
Note: It is required that the systems that are involved in storage partition migrations, the time must be synchronized between the systems. The best way to achieve this is to configure each system to use a Network Time Protocol (NTP) service.

Procedure

Run the chpartition command with the -location option to migrate the storage partition to its required system location.
The following example initiates a migration of storage partition to the designated location system:
```
chpartition -location <remote_system> mypartition1
```
The resulting output:
```
No Feedback
```
To check the migration status, run lspartition.
Note: You can monitor the progress of the migration, including the amount of data remaining to be copied, using the lsvolumegroupreplication command.
Once the data to be migrated along with the mappings gets replicated to the specified storage system, an event prompts for the administrator to ensure host accessibility with the migrated storage partition. Upon fixing this event, you can switch the I/Os to the migrated storage partition at the specified IBM Storage FlashSystem. This event is raised and fixed at source systems.
Another event prompts the administrator to remove the copy of the storage partition on the source system. The testing of the migrated storage partition must be verified before finalizing this event. Fixing this event removes the storage partition at the source IBM Storage FlashSystem along with its resources and mappings. This event is raised and fixed at the target FlashSystem.
Note: The migration can be canceled and the partition rolled back to its original system before fixing the event if the administrator observes any issues with the migrated storage partition.
An informational event at the target IBM Storage FlashSystem marks the completion of the storage partition migration. This event is raised at target FlashSystem.

Note:
You can monitor the migration using migration_status field that is shown by lspartition command indicating that there is no migration activity active or queued for that storage partition.

A ongoing storage partition migration can be aborted by specifying with a new migration location that uses “-override” option. The migration to the new location gets queued behind existing queued migrations, if any. For more information, see chpartition.

An active or queued migration operation gets aborted when its source system location is provided as a specified location. This needs an -override option since the abort operations remove the data that is replicated until that moment. For more information, refer to this example.

Rolling back a migration

The migrated storage partition serving I/Os from the target location (after fixing the event for host health checks at the source) can be rolled back to its source location. You can roll back a migration from the target system. For more information, refer to this example.

Rollback operation may be needed if the migrated storage partition does not perform as expected on the target system post migration. Rolling back operation switches the I/O operations to the storage partition at the source location. This operation does not remove the copy-synced storage partition at the specified target location.