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 Rehearse operation
In this operation, you can bring application online on the target cluster and test the application before performing the actual migration.
In this operation, the sync status of all volumes are checked after which cluster configuration of the selected service group is discovered in the source and translated to the target. The mirror disk group is then detached from the source cluster nodes and endian changes are performed on all volumes of the mirror disk group in the target cluster nodes.
After the endian changes are done, the service groups are brought online in the target cluster. After ensuring the application is running fine in the target, the service groups are taken offline and the target cluster configuration is removed.
Before removing the cluster configuration, a backup of the configuration is taken on the first node of the target cluster in the /etc/VRTSvcs/conf/config directory and the name will be in the following format:
main.cf_plan_name.date.time
The volumes in the mirror disk groups are then reattached to the corresponding volumes in the source disk group.
The operation aborts if all volumes between the source and mirror disk groups are not completely synced.
Initially, all RVGs are checked to ensure 100% sync. At times, if the application is writing to the volumes, data sync might be in progress to the secondary site and hence the Rehearse operation will not proceed. In such scenario, you can reduce or stop application writes so that data remains in sync.
Pre-requisites are done on target cluster nodes in order to create space optimized snapshot of volumes such as preparing volumes, cache volume, and cache object creation. IP, DiskGroup/CVmVolDg, RVGLogowner resources are then removed from the target cluster for the disk groups which are being migrated as part of the plan. This is to ensure no duplicate resources appear for an entity during cluster translation.
Cluster configuration of the selected service group and its dependencies are then discovered on the source and translated to the target. The file systems on all mounted volumes of the disk groups which are part of the replication is then frozen on the source for a moment and space optimized snapshots of these volumes are taken on the target with the help of VVR In-Band Control Messaging (vxibc). After the snapshots are taken, endian changes are performed on these snapshots and the service groups are brought online on the target. When service groups are brought online, the snapshot volumes gets mounted on the target cluster. Applications started on the target can write on these snapshot volumes until the cache volume fills up. After ensuring the application is running fine on the target, the service groups are taken offline and the target cluster configuration is removed.
Before removing the cluster configuration, the configuration is backed up on the first node of the target cluster in the /etc/VRTSvcs/conf/config directory and the name is in the following format:
main.cf_plan_name.date.time
The disk groups are then imported on the target cluster node and the snapshots are destroyed. The IP, DiskGroup/CVMVolDg, and RVGLogowner resources are re-created on the target, as required, and then brought online.