Veritas InfoScale™ Operations Manager 7.3.1 Add-ons User's Guide
- Section I. VCS Utilities Add-on 7.3.1
- Section II. Distribution Manager Add-on 7.3.1
- Section III. Fabric Insight Add-on 7.3.1
- Section IV. Patch Installer Add-on 7.3.1
- Introduction to Patch Installer Add-on
- Using Patch Installer Add-on
- Section V. Storage Insight Add-on 7.3.1
- Performing the deep discovery of enclosures
- About Storage Insight Add-on
- Adding HITACHI storage enclosures for deep discovery
- Editing the deep discovery configuration for an enclosure
- Monitoring the usage of thin pools
- Monitoring storage array metering data
- Managing LUN classifications
- Appendix A. Enclosure configuration prerequisites
- HITACHI enclosure configuration prerequisites
- EMC Symmetrix storage array configuration prerequisites
- Device setup requirements for EMC Symmetrix arrays
- IBM XIV enclosure configuration prerequisites
- NetApp storage enclosure configuration prerequisites
- EMC CLARiiON storage enclosures configuration prerequisites
- Hewlett-Packard Enterprise Virtual Array (HP EVA) configuration prerequisites
- IBM System Storage DS enclosure configuration prerequisites
- IBM SVC enclosure configuration prerequisites
- EMC Celerra enclosure configuration prerequisites
- EMC VNX storage enclosure configuration prerequisites
- EMC VPLEX storage enclosure configuration prerequisites
- Appendix B. Commands used by Management Server for deep discovery of enclosures
- Performing the deep discovery of enclosures
- Section VI. Storage Insight SDK Add-on 7.3.1
- Overview of Storage Insight SDK Add-on 7.3.1
- Managing Veritas InfoScale Operations Manager Storage Insight plug-ins
- About creating Storage Insight plug-in
- About discovery script
- About the enclosure discovery command output
- Creating a Storage Insight plug-in
- Editing a Storage Insight plug-in
- Testing a Storage Insight plug-in
- About creating Storage Insight plug-in
- Section VII. Storage Provisioning and Enclosure Migration Add-on 7.3.1
- Provisioning storage
- Creating a storage template using VxFS file systems
- Migrating volumes
- Provisioning storage
- Section VIII. Veritas HA Plug-in for VMware vSphere Web Client
- Introduction to Veritas HA Plug-in for vSphere Web Client
- Installation and uninstallation of Veritas HA Plug-in for vSphere Web Client
- Configurations for Veritas HA Plug-in for vSphere Web Client
- Section IX. Application Migration Add-on
- Introduction to Application Migration Add-on
- Creating and managing an application migration plan
- Understanding application migration operations
Understanding the tasks executed in each operation
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
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, Veritas 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.
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.
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:
|
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:
|
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. |