Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Process of transferring primary access

CautionWhen performing a transfer of primary access, the snapshot rules may be deleted on the source file system. This will lead to the snapshots and snapshot schedules also being deleted on the source file system.
A single transfer of primary access operation may be in progress at any time for any given replication policy, and the process for the transfer of primary access is as follows:

Procedure

  1. Put the source and destination (target) file systems into "syslock" mode.

    When a file system is in Syslock mode, the storage server allows read-only access to the file system, but not write access.

    The storage server ensures that the target file system data is consistent with the source file system data before primary access is transferred. This involves making the source and destination file systems read-only for a short time. Although any arbitrary directory can be relocated, the entire source file system is set to syslocked mode while the final replication operation is in progress. For more information on syslock mode, refer to the File Services Administration Guide.

  2. Notify clients that a short period of read-only access will be necessary while data and file system settings are relocated.

  3. Replicate the data and file system settings to the new location.

    After a transfer of primary access has been started, the replication process monitors the replication to determine when it is complete. When the replication is complete, the replication process starts moving configuration information automatically. The following table describes how network access points on the source file system are moved or deleted:

    Source File System Setting/Network Access Point Being Moved

    Destination

    Within the EVS

    Another EVS in the Same Cluster

    An EVS on Another Server or Cluster

    SMB Shares (if within replicated path)

    Moved (path is modified).

    Clients that had the share mounted before the transfer of primary access do not have to remount the share after the transfer.

    Moved (deleted from source EVS then added on target EVS).

    Clients that had the share mounted before the transfer of primary access must remount the share after the transfer only if the share was not to a directory in the CNS.

    Moved (added to target EVS then deleted from source EVS).

    Clients that had the share mounted before the transfer of primary access must remount the share after the transfer.

    NFS Exports (if within replicated path)

    Moved (path is modified).

    NoteClients that had the export mounted before the transfer of primary access must mount the export again after the transfer (the NFS mount becomes stale after the transfer).

    Moved (deleted from source EVS then added on target EVS).

    Moved (added to target EVS then deleted from source EVS).

    FTP Initial Directories/Users (if within replicated path)

    If all users within an initial directory can be moved, the initial directory is also moved.

    If all users within an initial directory cannot be moved, no users are moved and the initial directory is not moved.

    If all users within an initial directory can be moved, the initial directory is also moved.

    If all users within an initial directory cannot be moved, users are moved where possible, and the initial directory is duplicated.

    Snapshot Rules

    Where a file system is replicated from root (/) and all data and access points transferred to a new standalone file system, Snapshot Rules related to the source file system are deleted and recreated for the target file system. Deletion of snapshot rules automatically leads to the deletion of all snapshots associated with the rule on the original, source file system. This behaviour is intentional and unavoidable.

    Where a file system is only replicated partially, from sub-directories off the root of the file system (/), and only a subset of data and access points are transferred to the target file system, snapshot rules are not deleted and recreated on the target file system.

    CNS Links

    If CNS entries already point to the replication source, then the CNS link is removed and a link to the new file system is added at the corresponding path. Note, however, that if the file system is linked to the cluster name space at a point higher in the directory structure than the root directory for the file system path being replicated, moving the CNS link is not possible. In such cases, the CNS link is reported as an error in the list of successful/failed transfers, and the administrator must manually create a CNS link to the file system in the new location.

    After a transfer of primary access, network clients will not be able to access the file system through the a CNS name space if any of the following are true:

    • The file system did not have CNS links.
    • The file system's CNS links were not moved.
    • The file system was replicated to another server or cluster.

    To access the file system in its new location, network clients must reconnect through SMB shares or NFS exports pointing to the relocated file system or to a CNS name space into which the file system is linked. NFS clients pointing to a CNS name space will not experience any interruption.

    NoteIf clients will not access the relocated file system using CNS links, they must access it using new IP addresses.

    If CNS links exist, the relocation is not allowed to proceed, and a message advises the administrator to remove the links before proceeding.

    iSCSI Targets

    Not moved.

    Global Symlinks

    Not moved.

    NoteFor SMB shares and NFS exports: if possible, a text file backup of the moved shares and export is retained.
  4. Bring the target file system online.

    The system administrator receives instructions to bring the target file system on-line, by allowing read/write access. Read/write access is re-enabled on the entire source file system unless it was syslocked originally).

    The replication process tracks/records the progress of the final replication. Status of the network access point relocation is available through the Status and Reports page; replication failures are logged and can be viewed by following a link from the replication report.

  5. Begin servicing file service requests from the relocated file system.

  6. If the source file system was online when the transfer of primary access was started, put it back online by taking it out of syslocked mode.

    NoteIf the replication process is rebooted during a transfer of primary access, the source file system may not be returned to its original online state. If the replication process is rebooted during a transfer of primary access, you may have to take the file system out of syslock manually, from the File System Details page. For more information on syslock mode, refer to the File Services Administration Guide.

    After the final replication has completed, the original source data is still present on the source. This data can be accessed (and modified) through access points configured higher up in the directory tree, and should be deleted manually.

    NoteAfter the successful completion of a transfer of primary access, the source file system should be deleted or made inaccessible manually.
    WARNINGIt is especially important to perform the above in the case where data from the source file system had previously been migrated to cloud. Do not delete, or reverse migrate, the data from the source file system as both the source and the target (relocated) file systems refer to the same copy of data migrated to cloud.

    All replication schedules configured for the replication policy are set to inactive once the transfer of primary access is completed, and these inactive policies should then be deleted manually.

Handling a failure during a transfer of primary access

If a failure occurs during a transfer of primary access:

  • The target file system is not brought online in place of the source.
  • The source remains accessible and usable to network clients.
  • There is no attempt to rollback after a failure.
  • The replication process performs as many actions as possible, but leaves the replication policy in place.
  • A partially failed final replication does not remove the replication policy/schedule.
  • The system administrator can usually resolve the issue that caused the failure, then run transfer primary access again.

For example, when replicating several SMB shares, one share fails to be replicated, but the others are replicated successfully:

  • The share that failed is logged to a simple text file (which is viewable from the File Replication Report page).
  • All other shares that were successfully recreated are brought online, and deleted from the source.
  • When complete, the system administrator sees the error message and then views the text file using the File Replication Report page).
  • Viewing the text file, the administrator sees that the share could not be created on the target, perhaps because the name is already in use. The system administrator can delete the named share, either from the source or the target, and then transfer primary access again, this time successfully.

 

  • Was this article helpful?