This section describes how to perform planned service migration from the production center to the remote DR center on cascading and parallel networks.
Prerequisites
- During planned migration, the production VM cannot contain disks that are not in the protected group. Otherwise, the production VM may fail to be deleted.
- Recovery plans have been created for protected groups.
- Data has been tested and the data generated during tests has been cleared in the remote DR center.
- The production and remote DR centers communicate with each other properly. The management system and the DR environment in the remote DR center are working normally.
- Recovery plans for services to be migrated have been created on eReplication, which have succeeded in at least one test.
If no DR test is performed before the planned migration, the migration has a higher rate to fail. A migration failure will interrupt DR services. For this reason, at least one recovery plan test must be executed successfully before the planned migration.
- If the information about storage devices, hosts, or VMs is modified at the production or DR site, manually refresh the information. For details, see Refreshing Resource Information.
- In the Oracle application, the database is disabled but the cluster is enabled by default on the eReplication Agent. If you need to disable clusters, modify the configuration of disabling clusters. For details, see Changing the Configuration of Stopping the Oracle Cluster.
- In a DR Star network, before performing planned migration, log in to DeviceManager and ensure that the running status of the DR Star network is Enabled.
- The datastore name cannot contain Chinese characters.
Context
- The following DR scenarios do not support reprotection:
- In the Geo-Redundant Solution based on cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR center.
- In the Geo-Redundant Solution based on cascading replication (asynchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR center.
After services in the production center are migrated to the remote DR center in a planned manner, protected groups become invalid. You need to manually configure the protected groups after services are migrated back to the production centers.
Procedure
- Perform the planned migration on eReplication in the remote DR center.
Migrate services in the production center to the remote DR center. After the migration, test data and clear the data generated during tests. For details, see Step 1 to Step 4 in Planned Migration from the Production Center to the Same-City DR Center.
Result
After the planned migration is performed:
- the service system in the production center is stopped as planned.
- The remote DR center takes over services and provides the services to users.
- The replication relationship remains unchanged between the production center and the same-city DR center.
- In a cascading network, the replication relationship between the same-city DR center and remote DR center is split. In a parallel network, the replication relationship between the production center and remote DR center is split.
- DR protected groups become invalid.