Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Data and Config Migration

Introduction​

Data and Config Migration is an Eyeglass feature for moving data — along with its associated configuration (SMB shares, NFS exports, quotas, and NFS aliases) — between Access Zones on the same cluster, or between clusters, using your existing DR license and SyncIQ. Unlike Configuration Replication, which continuously mirrors configuration to a standing DR target, this feature is used for one-time or scheduled migration projects: restructuring Access Zones, consolidating clusters, or preparing a new environment for cutover.

Migration jobs are created and monitored from the Data Migration page (sidebar).

Typical Use Cases​

  • Split an Access Zone into two, for failover granularity.
  • Move an application to its own Access Zone, for security isolation.
  • Split data and application load between clusters.
  • Move data and configuration to a new Access Zone on the DR cluster for testing.
  • Move data and configuration to a new Access Zone to achieve active-active clusters.
  • Migrate data and configuration from several remote clusters into a central cluster, either into the same Access Zone (fan-in) or into separate Access Zones.

Supported Clusters​

  • PowerScale, all models
  • PowerScaleSD

See the release notes for the current feature-support matrix and supported OneFS releases.

Prerequisites​

Quota jobs must be enabled before running a migration job that includes quotas. Quota jobs are disabled by default.

  1. Connect to the Eyeglass appliance over SSH and log in as the admin user.

  2. Enable quota jobs:

    igls adv initialstate set --quota=enabled

  3. Confirm the setting took effect:

    igls adv initialstate show

    Confirm the output includes:

    "QUOTA": "ENABLED",

Planning Migrations Between Access Zones​

Before starting a migration, review the source and destination paths and Access Zones:

  • Source path — the source Access Zone is selected manually, since some clusters allow overlapping Access Zone base paths, meaning a single source path could belong to more than one Access Zone.
  • Target path — the target Access Zone (on the same or a different cluster) is auto-detected based on which Access Zone base path matches the target path.
Important

The target Access Zone must use the same authentication provider as the source Access Zone. Eyeglass cannot translate user and group SIDs between different Active Directory providers — if the target zone authenticates against a different AD forest or provider than the source, users will not resolve correctly on the migrated data.

Example — migrating overlapping Access Zones​

This example illustrates migrating several Access Zones that have overlapping base paths into a single new, non-overlapping Access Zone (on the same or a different cluster). Each source Access Zone can have its own configuration objects (shares, exports, NFS aliases, and quotas).

  1. Open the Data Migration page and start a new migration job.

  2. Select each source Access Zone path and zone name as a migration source. You can leave Keep SyncIQ Policy enabled to allow incremental sync after the initial copy.

    note

    The initial SyncIQ policy is created in copy mode. To keep the source and target paths in sync afterward, change it to incremental sync mode and apply a schedule.

  3. Confirm the migration job completes successfully, then verify the configuration objects (shares, exports, NFS aliases, quotas) exist correctly on the target Access Zone.

note

When source Access Zones have overlapping paths, quotas that fall within the overlapping portion will be duplicated on the new Access Zone.

How to Create a Migration Job​

  1. Open the Data Migration page.

  2. Fill in the Device & Migration Path field for the source — select the source cluster (only clusters managed by Eyeglass are listed), then type the source path or use the Browse button to navigate to it:

    • All configuration data (shares, exports, NFS aliases, quotas) at or below this path is included in the migration.
    • Select the source Access Zone separately. This isn't auto-detected, because some clusters allow overlapping Access Zone base paths, meaning a single source path could belong to more than one Access Zone.
    note

    The 2.15.0 form combines the legacy Migration Path and Source Cluster fields into a single Device & Migration Path field with a Browse button (see Data Migration) — the same applies to the destination field in step 4 below. Whether device selection happens as a step inside the Browse dialog itself, or via a separate control alongside it, hasn't been independently confirmed; the steps here describe the two selections functionally rather than the exact dialog mechanics.

  3. Decide whether to block user access to the source path during migration:

    • Leave Enable Source Write Access selected (default) to leave the source path writable during migration.
    • Deselect it to lock the source path and deny all I/O for the duration of the migration, regardless of share or export permissions. The migrated data inherits the locking SyncIQ policy's ACLs on the parent folder once the migration completes — see Re-apply Default SMB Share ACL Post Migration below, which is required if you deselect this option.
    • If the source path is already protected by an existing SyncIQ policy, you must deselect Enable Source Write Access — otherwise the migration job will fail, since the path is under an active SyncIQ domain.

  4. Fill in the Device & Migration Path field for the destination — select the destination cluster (must be managed by Eyeglass with a DR license key), then type the target path or use Browse to navigate to it.

    • The target path must not already exist. If Eyeglass detects existing data or configuration at the target path, the migration will not proceed.
    • The target Access Zone is auto-detected based on the target path matching an Access Zone base path.

  5. Optionally enable Migrate Only Configuration (named Configuration Sync Only in earlier releases) if the data is already synced by an existing SyncIQ policy and you only need to create the corresponding configuration (shares, exports, quotas) at the target path. This skips SyncIQ policy creation entirely.

    • The target path must already exist for this option — Eyeglass will not create the folder structure for you.

  6. If a SyncIQ policy already exists between the source and target paths, Eyeglass detects it automatically and uses it to sync configuration data instead of creating a new migration policy — no administrator action or separate toggle is required. (There is no Auto-detect Existing SyncIQ control on the 2.15.0 migration form; this detection is built-in behavior, not a setting.)

  7. Use the Preview Configuration option to confirm which shares, exports, quotas, and aliases were discovered for migration before submitting.

  8. Click Submit to start the migration job, and monitor it from the Data Migration page. Submit stays dimmed until the required fields are complete. Use Clear to empty the form and start over — this replaces the legacy Cancel button, which no longer appears on the 2.15.0 form.

  9. When you're ready to cut over to the new cluster or Access Zone, DNS updates (for the subnet service IP) and SPN changes are manual steps, but the data itself can be failed over using the Failover Wizard's SyncIQ policy failover type.

info

The configuration data is synced once on the first job run, using SyncIQ copy mode. If Keep SyncIQ Policy is left checked, the policy remains after the initial run and can be scheduled or run manually to incrementally sync configuration changes — it will appear under the ZoneMigration section of the Jobs window. Do not uncheck this without confirming with Superna Support first.

tip

Once a configuration-only migration job has finished and is no longer needed, delete it from the Jobs window (select its checkbox, then use Bulk Actions → Delete). Configuration-only migration jobs should not be left in place indefinitely.

End-to-End Migration to a New Access Zone​

Use this outline to move data, configuration, and users to a new Access Zone, using the same SmartConnect zone name to access the data after the migration. The original shares and exports are not deleted by the migration.

  1. PowerScale: Set up the new Access Zone with an AD provider.

  2. External: Stop users from writing to the data being migrated. The method is determined by the customer.

  3. Eyeglass: Do not disable the Eyeglass job. The job should be on all the time, for example when not all of the data covered by a policy is being migrated.

  4. Eyeglass: Run the Access Zone migration from the source Access Zone to the new Access Zone.

    • You must select Enable Source Write Access if the source path is covered by a policy, in order to proceed.
    • The data is replicated, and the shares, exports, and quotas are created for the new Access Zone on the source.

  5. PowerScale: Associate the new Access Zone with an IP pool. For both the source and target clusters, set up an IP pool in the new Access Zone.

  6. PowerScale: Set up a schedule to incrementally sync data on the zone migration policy. This policy is created by Eyeglass.

  7. Eyeglass: Run an incremental config sync from the Jobs window using the zone migration policy name created by the migration job. Data sync on new directory paths that are created for configuration data must already exist.

  8. Repeat the previous two steps until the final day of the cutover to the new Access Zone. Do this before you move the SmartConnect zone name from the old IP pool to the new IP pool.

  9. Maintenance window: Repeat the incremental sync, then:

    1. Rename or delete the SmartConnect zone IP pool name on the source Access Zone.
    2. Create the SmartConnect zone name on the new Access Zone pool.
    3. Verify that DNS resolves correctly to the new IP pool by running nslookup against the FQDN of the SmartConnect name.
    4. Verify in OneFS that the shares and exports exist as expected on the target Access Zone.

  10. Cutover day: Use DR Assistant in SyncIQ policy failover mode to fail over the data. Select the migration policy in DR Assistant.

  11. Users: Users can access the new share using the same SmartConnect zone name. The old shares are not accessible using that SmartConnect zone name, because the old SmartConnect zone name was renamed. Users left behind who were using that name have no access and need a new pool and a new SPN for a new SmartConnect zone name.

    note

    A client connection may not update after it is associated with the new Access Zone. This appears to be a Windows issue: the correct shares in the zone are shown only after a reboot.

  12. PowerScale: Re-protect the data to the DR cluster. Create a new SyncIQ policy with the new path, then run the new policy.

  13. PowerScale: Create the corresponding new Access Zone on the target cluster.

  14. Eyeglass: Enable the configuration replication job and run the new job. Shares and exports are replicated to the target cluster. The original job keeps running to protect the shares that were left behind. If you select Delete Source Configuration, the original shares are deleted after the Access Zone migration, and the old shares on the target cluster are deleted after configuration replication.

  15. Eyeglass: Re-run the readiness job.

  16. Eyeglass: Re-run the failover for the mirror policy.

For example, a test setup on the same cluster with a SyncIQ policy covering part of the data (div1) migrates from testzone1 to testzone2, moving the share g1 from /ifs/testzone1/div1/group1 to /ifs/testzone2/div1/group1.

Re-apply Default SMB Share ACL Post Migration​

Use this procedure only if you deselected Enable Source Write Access when creating the migration job.

That option applies a restrictive ACL to the target's top-level parent folder to block all access during migration — this ACL is applied only at the top level, so any ACLs already present on child paths below the migration path are preserved as-is. The modified top-level ACL blocks access to the data even if the share or export permissions themselves allow write access or full control — write access requires the combination of the share/export permission and a permissive ACL.

To restore the default Microsoft-style ACLs on the parent folder after migration, connect to the cluster's CLI and run:

chmod +a# 0 group Administrators allow dir_gen_all,object_inherit,container_inherit <path>
chmod +a# 1 creator_owner allow dir_gen_all,object_inherit,container_inherit,inherit_only <path>
chmod +a# 2 everyone allow dir_gen_read,dir_gen_execute <path>
chmod +a# 3 group Users allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit <path>
chmod +a# 4 group Users allow std_synchronize,add_file,add_subdir,container_inherit <path>
note

Replace <path> with the migrated parent folder path. The example ACE numbering above (0–4) assumes these are the first entries being added — adjust the index if the folder already has other ACEs.

Check the resulting ACL list with:

ls -lze <path>

If the restrictive migration-lockout ACEs are still present alongside the restored default ACEs, remove the extra entries by ACE index (highest index first, so indexes don't shift):

chmod -a# <index> <path>

Re-run ls -lze <path> to confirm only the intended ACEs remain, then connect to the target SmartConnect name to test that the mount and write access to the data behave as expected before returning the share to production use.

Planning Timeouts for Migration Jobs​

The following default timers apply to migration jobs and should be sufficient for most migrations. Use them as a starting point when troubleshooting a timeout on a long-running job:

StepDefault timeout
Run policy (overall job)15,000 minutes (10 days)
Wait for migration of config to complete50 seconds
Wait for locking policy to complete50 seconds
Wait for opened files to be closed300 seconds (delays job start; fails if the force flag isn't enabled)
Cleanup migration policy75 seconds (only if Keep SyncIQ Policy is unchecked)
Cleanup locking policy75 seconds (only if Enable Source Write Access is unchecked)

Known Limitations​

  • igls-dfs prefixed shares cannot be migrated directly. To migrate this data, a writable copy using non-prefixed shares must be migrated instead.

See Also​

Configuration Replication

How Eyeglass continuously mirrors shares, exports, quotas, zones, snapshots, and dedupe settings across PowerScale clusters for standing DR protection.

See More

Eyeglass Jobs

Understand how Eyeglass jobs work, including types, modes, and scheduling options relevant to migration and replication jobs.

See More