Search <book_title>...

InfoScale™ Operations Manager 9.0 Add-ons User's Guide

Last Published: 2025-04-14

Product(s): InfoScale & Storage Foundation (9.0)

Platform: AIX,HP-UX,Linux,Solaris,VMware ESX,Windows

Section I. Storage Provisioning and Enclosure Migration Add-on 9.0
1. Provisioning storage
2. Migrating volumes
Section II. Application Migration Add-on
1. Introduction to Application Migration Add-on
2. Creating and managing an application migration plan
Index

Understanding the tasks executed in each operation

Endian changes

The application peration uses the fscdsconv utility to perform endian changes on the target cluster node. This utility creates a recovery file for the purpose of conversion. The default path for the creation of the recovery file is: /var/opt/VRTSsfmh/tmp. The file system /var on the target cluster node must have more than 5 GB space.

If the file system does not have sufficient space for creating the file

On all nodes of the target cluster, create the /opt/VRTSsfmh/etc/appmig.conf file.
In the appmig.conf file, define the APPMIG_RECOVERY_PATH=path variable. Here, path is the full directory path where the recovery file needs to be created.

To check how much space is required in a VxFS file system for the recovery file as used by the fscdsconv utility, see: http://www.veritas.com/docs/000012748

Cluster configuration translation at the service group level

The following points describe how cluster configuration is translated at the service group level:

All the nodes in the target cluster would be part of the SystemList for the service group in the target.
Service groups on the source cluster that is being migrated are translated to the target cluster along with dependencies.
While migrating service groups between CVM clusters, the CVM service group is not translated, but its dependencies are translated. To ensue that the dependencies are translated, Arctera recommends that you should not deselect the CVM service group during plan creation.
Any setting with the following service group level attributes will be ignored in the target cluster:
- SystemZones
- VCSi3Info
- TriggerPath
- ClusterList
- Frozen
- TriggersEnabled
- TypeDependencies
- AdministratorGroups
- OperatorGroups
- Administrators
- Operators
- Guests
Triggers configured in the source cluster will not be translated to the target cluster. If you require triggers, trigger files must be manually copied and trigger attributes must be manually configured in the target cluster. You can use the pause task after the Configure Cluster on Target task or you can create a custom script to automate this.
If the source and target operating systems are different, the ContainerInfo attribute at the group level is skipped in the target cluster.
If a service group attribute is localized in the source cluster and the number of nodes in the target cluster is more than the number of nodes in the source cluster SystemList, the localized attribute is converted to a global attribute.
If the source cluster has offline group dependencies and the target cluster is a single node cluster, offline group dependencies are deleted from the target cluster. Remote dependencies are converted to local dependencies.
All site dependencies are deleted from the target cluster.

Cluster configuration translation at the resource level

The following points describe how cluster configuration is translated at the resource level:

Resource attributes part of the service groups being migrated are translated from the source to target cluster. For example, if the DiskGroup attribute exists in the service group, the attribute value is translated from the source cluster to the target cluster.
VxVM Mirroring - For each disk group resource, another disk group resource is created by the application migration operation. The name of this resource will start with amMir_. This is for internal housekeeping of snap disk group created for mirroring. This resource is skipped in the target cluster.
If the source and target operating systems are different, ResContainerInfo and ContainerOpts attributes are skipped in the target cluster.
If a resource attribute is localized in the source cluster and the number of nodes in the target cluster is more than the number of nodes in the source cluster SystemList, the localized attribute is converted to a global attribute.
During Rehearse operation, IP resources like IP, IPMultiNIC, and IPMultiNICB are not created in the target cluster. This is to avoid accidental connection of clients to the application during Rehearse operation. These resources are converted to FileOnOff type to maintain resource dependencies.
If any resource type configured in the source cluster is not available in target cluster, the corresponding resources are removed from the target cluster during cluster configuration.
If the source and target cluster operating systems are different, IPMultiNICB resources are converted to IP type and MultiNICB type resources are converted to NIC type.
VVR Replication - In the Rehearse operation, Volume and VolumeSet type resources managing volumes and volume sets being replicated are converted to FileOnOff type resource in the target cluster. This is done as snapshot volumes created in the target cluster cannot be managed using these resources.
VVR Replication - In the Migrate operation, Volume and VolumeSet type resources managing volumes and volume sets being migrated are converted to FileOnOff type in the source cluster. This is to ensure taking the service group offline does not fail in the source cluster.
If target cluster node is detected as an AWS EC2 instance, for every IP type resource an AWSIP type resource is created in the target configuration.

List of tasks executed

Table: Mirroring - List of tasks executed lists predefined tasks executed as a part of each operation. Each predefined task in an operation is marked as Critical or not. The table also lists the tasks for which the cleanup operation is performed and the state of the managed hosts after the operation.

If a task marked as critical fails, the operation aborts. If a task is not critical, the operation continues even if it fails. For most critical tasks, failure necessitates a cleanup of the system and an internal cleanup operation is performed.

See Understanding the cleanup operation.

Table: Mirroring - List of tasks executed

Task	Is the task critical?	Will cleanup be performed if task fails?	What happens to the system if the task fails?
Setup Storage
Deploy scripts on the managed host	Yes	No	No change.
Verify mirror configuration	Yes	No	No change.
Prepare disk group for mirroring	Yes	Yes	After cleanup, system reverts to the state before the Setup Storage operation. Perform the Setup Storage operation again.
Create mirror between source disk group	Yes	Yes	After cleanup, system reverts to the state before the Setup Storage operation. Perform the Setup Storage operation again.
Snapshot sync progress	Yes	No	System will be in existing state and mirror will be under sync on the managed host.
Remove scripts from the managed host	No	No	System will be in existing state.
Rehearse
Deploy scripts on the managed host	Yes	No	No change.
Verify mirror configuration	Yes	No	No change.
Configure target cluster	No	No	Target cluster configuration is created partially. You must validate the configuration and make necessary changes during the Pause task before proceeding.
Pause plan for user validation	Yes	No	No change.
Detach mirror disk group	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, mirror is reattached to the source. Target cluster configuration is removed after taking backup. Perform the Rehearse operation again.
Online service group in the target cluster	No	No	Service groups will be in partial state. Check the reason in the Pause task.
Pause plan for user validation	Yes	No	No change.
Offline service group in the target cluster	No	No	Service groups will be in partial state. Take all the service groups offline and check whether the mirror disk groups are deported; if not, manually deport the mirror disk groups in the Pause task.
Pause plan for user validation	Yes	No	No change.
Remove service group from the target cluster	Yes	No	Task will not fail.
Endian changes on the mirror disk group	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, mirror is reattached to the source. Perform the Rehearse operation again.
Reattach mirror disk group in the source cluster	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, mirror is reattached to the source. Perform the Rehearse operation again.
Snapshot sync progress	Yes	No	System will be in existing state. Mirror will be under sync on the managed host.
Remove scripts from the managed host	No	No	System will be in existing state.
Migrate
Deploy scripts on the managed host	Yes	No	No change.
Verify snap mirror configuration	Yes	No	No change.
Configure target cluster	No	No	Target cluster configuration is partially created. You must validate the configuration and make necessary changes before proceeding.
Pause plan for user validation	Yes	No	No change.
Offline service group in the source cluster	Yes	No	Service groups will be in partial state. Do the following: Check the reason why taking the service group offline failed. Fix the issue. Bring the service groups online. Start the Migrate operation.
Detach snap mirror disk group	Yes	Yes	During cleanup, mirror is reattached to the source and target cluster configuration is removed. Bring the service groups online in the source cluster and perform the Migrate operation again.
Endian changes on the mirror disk group	Yes	Yes	During cleanup, mirror is reattached to the source and target cluster configuration is removed. Bring the service groups online in the source cluster and perform the Migrate operation again.
Online service group in the target cluster	No	No	Service groups will be in partial state in the target cluster.
Remove scripts from the managed host	No	No	System will be in existing state.

Table: Replication - Lists of tasks executed

Task	Is the task critical?	Will cleanup be performed if task fails?	What happens to the system if the task fails?
Setup Storage
Deploy scripts on managed hosts	Yes	No	No change.
Verify replication configuration	Yes	No	No change.
Configure replication on source and target clusters	Yes	Yes	After cleanup, system reverts to the state before the Setup Storage operation. Check and resolve the issue. Perform the Setup Storage operation again.
Set up replication between source and target clusters	Yes	Yes	After cleanup, system reverts to the state before the Setup Storage operation. Check and resolve the issue. Perform the Setup Storage operation again.
Create RVGLogowner type resource for shared disk group(s)	Yes	Yes	Task will not fail.
Replication sync progress	Yes	No	System will be in existing state and replication will be under sync between source and target cluster nodes.
Remove scripts from managed hosts	No	No	System will be in existing state.
Rehearse
Deploy scripts on managed hosts	Yes	No	No change.
Verify replication configuration	Yes	No	No change.
Delete replication-related VCS resources on the target cluster	Yes	Yes	Task will not fail.
Perform target cluster configuration	No	No	Target cluster configuration is created partially. You must validate the configuration and make necessary changes during the Pause task before proceeding.
Pause plan for user validation	Yes	No	No change.
Set up volumes on target cluster for creating snapshot	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, snapshots are deleted. Target cluster configuration is removed. Replication-related resources are re-created on the target cluster. Check and resolve the issue. Restart the Rehearse operation.
Create snapshots on target by freezing VxFS mount points and replication	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, snapshots are deleted. Target cluster configuration is removed. Replication-related resources are re-created on the target cluster. Check and resolve the issue. Restart the Rehearse operation.
Perform endian changes on snapshot volumes on the target cluster	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, snapshots are deleted. Target cluster configuration is removed. Replication-related resources are re-created on the target cluster. Check and resolve the issue. Restart the Rehearse operation.
Bring service groups online on the target cluster	No	No	Service groups will be in partial state. Check the reason for the failure and correct it.
Pause plan for user validation	Yes	No	No change.
Take service groups offline on the target cluster	No	No	Service groups will be in partial state. Take all the service groups offline and during the Pause task, check whether all the disk groups are deported.
Pause plan for user validation	Yes	No	No change.
Remove target cluster configuration	Yes	Yes	Task will not fail.
Remove snapshot volumes and re-create replication-related VCS resources on the target cluster	Yes	Yes	After cleanup, system reverts to the state after the Setup Storage operation. During cleanup, snapshot removal is reattempted and replication-related resources are re-created on the target cluster.
Remove scripts from managed hosts	No	No	No change.
Migrate
Deploy scripts on managed hosts	Yes	No	No change.
Verify replication configuration	Yes	No	No change.
Delete replication-related VCS resources on the target cluster	Yes	Yes	Task will not fail.
Perform target cluster configuration	No	No	Target cluster configuration is created partially. You must validate the configuration and make necessary changes during the Pause task before proceeding.
Pause plan for user validation	Yes	No	No change.
Reconfigure the source cluster to prevent plan failure	Yes	Yes	During cleanup, cluster configuration performed on the target is removed. Restart the Migrate operation
Take service groups offline on the source cluster	Yes	No	Service groups will be in partial state. Do the following: Check the reason why taking the service group offline failed. Fix the issue. Bring the service groups online. Start the Migrate operation.
Stop replication and remove the secondary site	Yes	Yes	During cleanup, secondary sites which might have been removed will be re-added and replication is started. Service groups will be in offline state on the source cluster. Bring the service groups back online. Check and resolve the issue. Restart the Migrate operation.
Perform endian changes on replicated volumes	Yes	Yes	During cleanup, secondary sites which might have been removed will be re-added and replication is started. Service groups will be in offline state on the source cluster. Bring the service groups back online. Check and resolve the issue. Restart the Migrate operation.
Bring service group online on the target cluster	No	No	Service groups will be in partial state on the target cluster.
Remove replication configuration from source and target cluster	No	No	Replication configurations added on the source and target cluster disk groups will not be fully cleaned up.
Remove scripts from managed hosts	No	No	No change.