[-]
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 [+]
  
  
  
  
  
  
 [+]
  
  
  
[+]
[+]
[+]
[+]
[+]
[+]
[+]
[+]
[+]
[+]
Updated on 10/21/2019
Administration Guides
Configuration Replication
Direct link to topic in this publication:
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:

  • Directories associated with the shares/exports/quotas/zones must exist on the target Isilon cluster as defined in the SyncIQ policy.
  • Access Zones associated with the shares/exports/quotas must exist on the target Isilon cluster.

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 Isilon 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 Isilon clusters.

What Configuration Properties are Replicated by Eyeglass?


Shares

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

  • Local users & their permissions.
  • filesystem users & their permissions.

! 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 Isilon 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 behaviour.  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:

  • export id: Exports on source and target will not have the same export id.
  • Dual path exports must have both paths fall under the same SyncIQ policy.
  • FQDN clients listed must be resolvable by the target cluster. If this is not possible Eyeglass full sync mode must be used to override API validation and force create exports.  See ilgs CLI command documentation section in this guide.

Quotas

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

  • Usage Accounting - include Snapshot Data (best practice to not replicate this setting with SyncIQ)
  • Usage Accounting - include Data-Protection Overhead (best practice to not replicate this setting with SyncIQ)
  • Quota definitions that use user or group quota from local or filesystem are unique across clusters even if the same name is used.  This means local/filesystem users and well known accounts should not be used with the Quota Replication feature.   Active Directory should be used with user and group quota and custom or automatic quota replication jobs.

Zones

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

  • Access Zone Name
  • Zone base directory
  • Authentication Providers (name only)
  • User Mapping rules (Isilon 7.1.x.x only)

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

Snapshots

  • Snapshot schedule properties (only for paths that match SyncIQ policies cluster wide) with the following exceptions:
  • next_run  (auto-populated by OneFS)
  • next_snapshot  (auto-populated by OneFS)

Dedupe

  • Dedupe path for job processing (only for paths that match SyncIQ policies cluster wide)
  • Dedupe assessment paths (only for paths that match SyncIQ policies cluster wide)

SyncIQ Policies

  • On Failover only the SyncIQ schedule is re-applied to newly created mirror policies
  • File pattern filters set on SyncIQ policies are NOT synced on failover, these patterns can result in unprotected data during failover and failback.   Failover and failback work flows require customer testing.  All file filter use cases  are untested without support or documentation.
Copyright Superna LLC