Home


Replication

Prerequisite for Configuration Replication

In order for Eyeglass to be able to execute the configuration replication for the shares/exports/nfs alias/quotas/zones that have been detected for the SyncIQ policies, the following is required:

Replicating Shares with $ for Security on Target Clusters

This section describes how configuration replication can be used to hide shares on DR and unhide shares after failover. This is to hide the data on the DR cluster automatically.

Use Cases:

  1. DFS mode for SMB failover with shares renamed on failover and hidden on DR cluster
  2. Access Zone failover with shares Synced and hidden on DR cluster

Configuration:

  1. Enable a policy for DFS mode from Jobs icon

Note: This will work for Access Zone failover as well.

  1. Now change the dfs config suffix.
  1. This can be enabled by editing /opt/superna/sca/data/system.xml file.  Change the tag to include $ as shown below:

 <dfssharesuffix>$</dfssharesuffix>

 NOTE: on an existing installation the old DFS renamed share will need to be manually deleted.

  1. After failover the share names will flip and hide it on the Source cluster.  

How does Eyeglass Determine Uniqueness - the Details

Uniqueness and Equality between Shares

The combination of share name and zone name is the unique value that we use to determine if one share equals another.  This applies to records on the same cluster, as well as comparing shares between two PowerScale clusters.

Uniqueness and Equality between Exports

Uniqueness is determined by the client list and the path to sync between Access Zones on replicating clusters.  Same path but different client list (all client lists) will be treated as different exports to sync within a given Access Zone.

Uniqueness and Equality between Zones

Zone name is used to determine if one zone equals another.  This applies to records on the same cluster, as well as comparing zones between two PowerScale clusters.

What Configuration Properties are Replicated by Eyeglass?


Shares

For Shares all configuration properties are replicated with the following exceptions:

! SID for local and filesystem users are replicated but not mapped to users on the target. This means AD at the target cluster should be setup to resolve SID's using the same AD forest.

Note: Shares with variable expansion now sync correctly to the target cluster example %u share names.

Note: Locally created uses or groups on PowerScale are created and generate a cluster unique UID or GID.  This means users with the same name on two clusters have different UID and GID.  This is normal Linux machine behavior.  Sync local users or groups have no value, since userX on cluster A will not be the same userX synced on cluster B, and therefore will not have access to any data secured to userX on cluster A.   The best practice is use LDAP or Kerberos for user security for exports or Active Directory for unified security database.

Exports

For exports, all configuration information is replicated to target with the following exceptions:

Quotas

For quotas, all configuration information is replicated to target with the following exceptions:

Zones

The following configuration properties are replicated for Zones other than the System zone:

! Authentication providers / Local providers must exist on the target to resolve the SID' used in share permissions and the filesystem ACL's.

Snapshots

Dedupe

SyncIQ Policies

© Superna Inc