Deploying a Failed-Over Replication Peer as a Working Cluster

Prev Next

Overview

The failover capability switches data that was replicated to a destination peer to writeable mode so that you can continue operations using the replication peer. The replication peer stores a replica of the source peer's working data at the configured path. It also stores S3 access key pairs and identity policies from the destination peer, since they are replicated along with the data. Replicated identity policies are included in listings of identity policies on the remote peer. When querying users from a provider that is/was connected to the source peer, you can see any access key pairs that were generated on the source peer for the user.

Note

Identity policies and S3 access keys are replicated from source peer to destination peer and vice versa. Therefore, if both the source and the destination peers have an access key pair for a user, both peers will store a remote access key pair.

Note

When a path has multiple async replication protected paths, each peer stores local access keys and up to one pair of remote access keys per user, which are the last remote keys that were replicated to the peer.

Besides identity policies and S3 access key pairs, any and all configurations on the source peer's VMS that impact data clients, such as views, view policies, authentication providers and so on, need to be configured on the replication peer before resuming operations. Similarly, any client side configurations, such as DNS server configurations and client mounts that enable clients to connect to the source peer need to be replicated or otherwise handled manually.

Note

For seamless failover, a capability supported for NFSv3 clients, views on the replication paths need to be configured to support global synchronization prior to failover as described in Preparing for Seamless Replication Failover (NFSv3).

A record of many of the VMS configurations is maintained for you and downloadable from the destination peer so that in the event of disaster recovery, you can retrieve those configurations and manually replicate them as needed.

You may be able to maintain much of this configuration permanently or regularly update it as part of your disaster recovery plan.

Downloading VMS Data

This procedure enables you to download the source peer's VMS data from the destination peer. You can read data from this file in order to make appropriate configurations on the backup cluster VMS. In many cases, you will want identical configurations. In some cases, you need to make adjustments.

  1. On the destination peer, open the Data Protection page and select the Replication Peers tab.

  2. Right-click the replication peer and select Download VMS Data.

    The VMS data file is downloaded to your machine. It is a compressed bundle comprising CSV files for several configuration entities that you might need to recreate on the backup cluster.

  3. Extract the bundle file to access the CSV files.

Manually Replicating VMS Data

You can find various VMS configuration records in the downloaded VMS data files. See the following table for replication guidelines per configuration and for links to the relevant configuration procedures.

Configuration

Found in Files

Replication Guidelines

Configuration Procedures

Auth providers: Active Directory, LDAP

ActiveDirectory, Ldap

For expected user authorization and authentication, and for SMB access to work, either replicate the same Active Directory and/or replicate the same LDAP configuration(s) as on the primary cluster or use Active Directory and LDAP servers that are synced with the original providers.

If your primary cluster was joined to Active Directory, you also need to join the secondary cluster to ActiveDirectory, using a unique machine account name.

Callhome

CallhomeConfig

Do not input identical call home values as for the original source peer, since it is important that they are globally unique.

DNS Based Load Balancing

DNS

Ensure that the DNS-VIP does not conflict with the primary cluster's DNS-VIP, as this may cause IP conflicts.

Event Definitions

EventDefinition

Modifying Event DefinitionsModifying Event Definitions

EventDefinitionConfig

EventDefinitionConfig

Local users

User

Any users that are configured on the local provider need to be manually replicated on the backup cluster in order to be authorized as previously with the source peer.

Managing Local UsersManaging Local Users

Local groups

Group

Any groups that are configured on the local provider need to be manually replicated on the backup cluster in order to be authorized as previously with the source peer.

Managing Local Groups

Native replication peer

NativeReplicationRemoteTarget

Protected Path

ReplicationStream

Managing Protected PathsManaging Protected Paths

Protection policy

ProtectionPolicy

Managing Protection PoliciesManaging Protection Policies

Quota

Quota

Quotas must be created after failover. If quotas were created on the remote peer protected path before failover, they must be deleted and recreated.

Warning

Quota accounting is not accurate for replicated data if the quotas were created before failover.

Creating QuotasCreating Quotas

S3 Replication Peer

ReplicationTarget

Managing S3 Replication Peers

Views

View

If the protected path has a remote path on a replication peer that is different from the local path on the source peer, then you will need to nest the view's path under that remote path.

For example, supposing the async replication protected path has path=/dir and remote path=/replica/dir, and a view on the source peer had path=/dir, then to configure the equivalent view on the destination peer, you would enter /replica/dir as the path and not /dir as on the source peer.

ViewsViews

View Policies

ViewPolicy

View policies include rules that determine which NFS client hosts have different types of access (such as read-write, read-only, nosquash, all squash and so on.) In the event that you wish to allow different client hosts to access the new views on the secondary cluster to those that were allowed to access the primary cluster prior to failover, you may need to specify different NFS access rules.

ViewsViews

VIP Pools

VIPPool

VIPS that you configure on the replication peer should not conflict with the IPs in the primary cluster's VIP pools.

VMS user permissions

  • Permission

  • Role

Authorizing VMS Access and PermissionsManaging VMS Permissions

Activating Replicated Identity Policies and Access Keys

To use identity policies and users' access keys that were replicated from the destination peer, you need to enable them:

Further Configurations You May Need

Configurations not listed in the table above are not included in the downloadable configuration file and you may wish to otherwise record these configurations so that you can replicate them. This includes, for example, NIS, Managers, settings (including trash folder enablement), SSL certificates, and custom analytic reports.

Connecting Clients to Views

When you've configured the VIP pools and views on the replication peer to serve clients, and you've handled DNS configurations on the client network and if applicable on the replication peer's VMS, you will need to remount views on clients in order to connect them to the new views on the destination peer.