Follow

About

A set of operations and commands to drive and manage the mobility process.   

Mobility Operations 

Each operations performs several actions.

  • Mobility operations can be performed only using Host PowerTools.
  • A "mobility readiness check" is carried-out at the begging of each operation.
  • Note: mobility operations cannot be performed while the link between the source and the target systems is down. 

Mobility Readiness Check

The mobility readiness check validates that the environment is properly configured according to the requirements and best practices.

  • The readiness validations are different for each mobility operation. 
  • The readiness check consists of mandatory and non-mandatory validations.
    • Violations of mandatory checks prevent the mobility operation from progressing.
    • By default, violations of non-mandatory checks also prevent from the mobility operation from progressing.
    • The non-mandatory validations can be skipped. (if specified)
      • Run the desired mobility operation command using '--skip-optional-validations' in order to skip non-mandatory checks. 
  • It is possible to run only the readiness check of each operation.
    • Running a mobility operation without '--yes' triggers only the mobility readiness check.

Initiate

This operation starts the online data mobility process.

infinihost mobility initiate
  • To initiate mobility only on specific volumes, use the '--device-or-mount' param.
    • Accepts comma separated values.
  • To initiate mobility on all volumes that are mapped from a specific system at once, use the '--source-system' param.
    • The operation will Identify and initiate mobility on all the mapped volumes from the specified system which are not already undergoing mobility.

Host / Cluster registration validation

The operation checks if the host is part of a cluster, before validating if the host is registered on the target system.

  • In case the host is not part of a cluster:
    • If the host is already registered on the target system, it must be identical to the host on the source system.
      • The host name and the ports it contain must be identical.
      • Else it is considered as not properly registered.
    • If the source host name and his ports do not exist on the target system, the host will be registered.
  • In case the host is part of a cluster:
    • If the cluster is already registered on the target system, it must be identical to the cluster on the source system.
      • The hosts names and all the hosts's ports that the source / target cluster contain must be identical - the exact same structure. 
      • Else it is considered as not properly registered.
    • If the source cluster name and all the objects it contains do not exist on the target system, the entire cluster will be registered.
  • Note: In case any discrepancy is found between the structure of the source host / cluster to the target host / cluster, the operation aborts and the target host / cluster is considered as not properly registered.
    • The operation does not conduct any change to existing the host or cluster objects. 

Readiness check

The Initiate readiness check validates the following: 

  • The source and target system are linked and the link supports Active-Active replication. 
  • The specified volume(s) is qualified for mobility.
  • The target pool has enough space to contain the specified volume(s).
  • There are no more than six paths to the source volume(s). 
    • Non-mandatory

Actions sequence

The operation performs the following actions:

  1. Validate credentials to source and target InfiniBox systems.
  2. Run initiate readiness check.
  3. Host \ Cluster registration validation on the target system.
  4. Validate that there are no LUN/s conflicts between the source and target hosts / clusters. 
  5. Generate custom InfiniBox events which indicate that mobility will be initiated. 
  6. Initiate volume/s mobility:
    1. Create mobility replica for each volume to the target system.
      • A mobility target volume with the exact same name as the source volume is created. 
      • The target volume SCSI serial is inherited from the source volume.
      • The mobility source volume is set as the replica preferred. 
    2. Map the target volume to the target host / cluster (dependent on the volume mapping type) with the same LUN as in the source.
  7. Perform a host rescan - discovers the new paths to the target system. 

Cut-over 

This operation completes the online data mobility process.

  • Cut-over can be performed only once the mobility replica is in a "synchronized" state - data is synchronized on the target system.
    • For more information about monitoring the mobility replica state see the "Monitoring Mobility" section below.
infinihost mobility cut-over
  • In order to cut-over only specific volume(s), use the '--device-or-mount' param. 
    • Else the operation will attempt to cot-over all volumes which are undergoing mobility. 
  • In order to "clean" the source system, use the '--clean-source' param. The operation will also perform the following:
    • Source volume/s will be deleted - only volumes that cut-over successfully.

    • The source host / cluster will be deleted if it doesn’t have any mapped volumes.

Readiness check

The Cut-over readiness check validates the following: 

  • All specified volumes have the same source and target system. 
  • The Mobility replica is synchronized. (of each volume) 
  • The volume is mapped through the target system.
  • The volume is mapped to an identical host \ cluster object on the source and target systems.

Actions sequence

The operation performs the following actions:

  1. Validate credentials to source and target InfiniBox systems.
  2. Run cut-over readiness check.
  3. Generate custom InfiniBox events to indicate that the volume is about to cut-over. 
  4. Cut-over volume/s mobility:
    1. Unmap the source volume.
    2. Delete the mobility replica from the target system.
      • The target volume SCSI serial is kept .(was inherited from the source volume)
      • The source volume SCSI serial is changed. 
      • Note: if from any reason deleting a mobility replica failed, Host PowerTools would attempt to re-map the source volume.
  5. Perform a host rescan - removes dead paths to the source system. 
  6. Optional step: Preforming source clean-up.
    • If "source clean-up" was specified.
    • Source volume/s will be deleted - only volumes that cut-over successfully.

    • The source host / cluster will be deleted if it doesn’t have any mapped volumes.

Abort

This operation cancels (aborts) a mobility process.

  • It is possible to abort a mobility process at the volume granularity on any time before performing the cut-over operation. 
infinihost mobility abort
  • In order to abort mobility only for specific volume(s), use the '--device-or-mount' param. 
    • Else the operation will attempt to abort all volumes which are undergoing mobility. 
  • In order to "clean" the target system, use the '--clean-target' param. The operation will also perform the following: 

    • Target volume/s will be deleted - only volumes that aborted successfully.

Readiness check

The Abort readiness check validates the following: 

  • All specified volumes have the same source and target system.
  • The link between the source and target system is up.
  • The Mobility replica state on the source system is not lagging. 
  • The volume is mapped through the source system.
  • If the volume is mapped on the target, it must be to an identical host \ cluster object on the source and target systems.

Actions sequence

The operation performs the following actions:

  1. Validate credentials to source and target InfiniBox systems.
  2. Run abort readiness check.
  3. Generate custom InfiniBox events which indicate that mobility will abort. 
  4. Abort volume/s mobility:
    1. Unmap the target volume.
    2. Delete the mobility replica from the source system.
      • The source volume SCSI serial is kept .(was inherited from the source volume)
      • The target volume SCSI serial is changed. 
      • Note: if from any reason deleting a mobility replica failed, Host PowerTools would attempt to re-map the source volume.
  5. Perform a host rescan - removes new dead paths to the target system. 
  6. Optimal step: Preforming target clean-up.
    • If "target clean-up" was specified.
    • Target volume/s will be deleted - only volumes that aborted successfully.

Monitoring Mobility

The mobility process can be monitored within the host using Host PowerTools or directly on the InfiniBox system.

  • Provide status and information about undergoing mobility processes. 

Monitoring mobility process within the host

It is possible to monitor the mobility progress from every host that is mapped to a volume which is undergoing mobility. 

  • Using the 'Infinihost mobility list' command.
  • Example:
>infinihost mobility list
Volume Name      Device Name            Source System (S/N)       Target System (S/N)        Replica State            Throughput          Progress
Vol1             PHYSICALDRIVE1         IBOX100 (1233)            IBOX200 (3213)             Sync In Progress         200 MiB/sec         65%
  • "Progress" - provides an estimated indication for the mobility replica/s to reach the "Synchronized" state.
    • Implies that the volume/s are ready to cut-over. 
    • I/O to the source volume during synchronization and the replication link load can negatively impact the progress.
    • Available only through Host PowerTools.

Monitoring mobility process on InfiniBox

GUI

Login to the InfiniBox GUI and navigate to Replication → Mobility.

  • The small arrow between "LOCAL" and "REMOTE" indicates the mobility direction: Source → Target. 

CLI

  • Using the 'mobility.query' command.

>mobility.query
LOCAL       TYPE           ROLE          REMOTE SYSTEM         REMOTE          STATE                      THROUGHPUT
Vol1        VOLUME         Source        IBOX1000              Vol1            Sync in progress           400 MiB/sec
  • "ROLE" - indicated if the local dataset is the mobility source or target. 

Testing Mobility

It is possible to test the entire mobility process between two systems using the "Mobility Test" flow. 

  • The test flow validates the environment and both systems are properly configured for mobility.
  • Done by performing a complete online data mobility process on a "dummy" volume.
    • Temporary created for the test flow. 
infinihost mobility test

Note: The Test operation is not supported on AIX and Solaris operating systems. 

  • The readiness check and host / cluster registration is similar to the Initiate operation. 

Actions sequence

The mobility test flow performs the following actions:

  1. Run the initiate readiness check. 
  2. Register the host (or cluster) on the target system.
    • If the host is already exists on the target system, it will validate that it is properly registered. 
  3. Create a dummy 2GB thin volume on the source system.
    • Name: "Mobility-test-%GUID%".
  4. Map the source dummy volume to host on the next available LUN.
  5. Perform a host rescan - discovers the dummy volume.
  6. Initiate mobility:
    • Create mobility replica for the dummy volume to the target system.
    • Map the target dummy volume to the host on the same LUN as on the source system.
  7. Wait for the mobility replica to become Synchronized.
    • This action takes place almost instantly. 
  8. Writes a set of data.
  9. Perform cut-over:
    1. Unmap the source volume.
    2. Delete the mobility replica from the target system.
  10. Perform a host rescan.
  11. Validate that the dataset which was written before is accessible. 
  12. validate accessibility to the target dummy volume.  
    • Informs the user if the host can access the volume according to the best practices.
  13. Performing clean-up:
    1. Deleting the dummy source volume.
    2. Deleting the dummy target volume.
  14. Perform a host rescan - removes the dead dummy volume.
Was this article helpful?
0 out of 0 found this helpful

0 out of 0 found this helpful

Comments