Arctera InfoScale™ Operations Manager 9.0 Add-ons User's Guide
- Section I. Storage Provisioning and Enclosure Migration Add-on 9.0
- Provisioning storage
- About storage provisioning
- About creating a storage template
- Creating a storage template using VxFS file systems
- Creating a storage template using NTFS file systems
- Creating a storage template using volumes
- Updating a storage template
- Provisioning storage
- Uploading storage templates
- Downloading storage templates
- Deleting storage templates
- Locking storage templates
- Unlocking storage templates
- Migrating volumes
- Provisioning storage
- Section II. Application Migration Add-on
- Introduction to Application Migration Add-on
- Creating and managing an application migration plan
- Supported versions and platforms
- User privileges
- Prerequisites for creating an application migration plan
- Prerequisites for migration to AWS
- VVR Replication: Environment variables used in application migration
- Creating an application migration plan
- Understanding user-defined tasks
- Understanding application migration operations
- Understanding the cleanup operation
- Understanding the tasks executed in each operation
- Validations performed before migration plan execution
- Executing the application migration plan
- Editing an application migration plan
- Deleting application migration plan(s)
- Exporting application migration plan(s)
- Importing application migration plan(s)
- Viewing historical runs
- Viewing properties of an application migration plan
- Application migration logs
- Index
Understanding the Migrate operation
In this operation, the actual migration happens. Service groups on the source are taken offline, so there will be a downtime when the operation is in progress. After the operation is complete, you can use the target cluster to run the application.
In this operation, the service groups in the source are taken offline before detaching the mirror disk groups from the source cluster nodes. This is to ensure data integrity before the final migration. After the mirror disk groups are detached from the source cluster nodes, endian changes are performed on these volumes in the target cluster nodes and the service groups are brought online in the target cluster.
The operation aborts if all volumes between the source and mirror disk groups are not completely synced.
In this operation, verification is done to ensure 100% sync between the source and target clusters. Cluster configuration is completely translated and service groups are taken offline from the source. Replication is stopped for all RVGs of all disk groups part of the migration. Endian changes are performed on volumes part of replication on the target after which service groups are brought online. Secondary site is removed from the primary RVG and the primary RVG is also removed for all the disk groups marked as Create New.