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 is an independent cluster in all senses except that it stores a replica of the source peer's working data at the configured path. Therefore, 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.
You may be able to maintain much of this configuration permanently or regularly update it as part of your disaster recovery plan.
A record of many of the VMS configuration 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.
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.
-
On the destination peer, open the Data Protection page and select the Replication Peers tab.
-
Click
to open the Actions menu for 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.
-
Extract the bundle file to access the CSV files.
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 ActiveDirectory, you also need to join the secondary cluster to ActiveDirectory, using a unique machine account name. |
|
|
Callhome |
CallhomeConfig |
Do not input identical callhome 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 |
||
|
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. |
|
|
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. |
|
|
Native replication peer |
NativeReplicationRemoteTarget |
||
|
Protected Path |
ReplicationStream |
||
|
Protection policy |
ProtectionPolicy |
||
|
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. WarningQuota accounting is not accurate for replicated data if the quotas were created before failover. |
|
|
S3 Replication Peer |
ReplicationTarget |
||
|
Views |
View |
If the native replication protected path has a path on peer that is different from its path then you will need to nest the view's path under that path on peer. For example, supposing the native replication protected path has path=/dir and path on peer=/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. |
|
|
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. |
|
|
VIP Pools |
VIPPool |
VIPS that you configure on the replication peer should not conflict with the IPs in the primary cluster's VIP pools. |
|
|
Remote VPN Tunnel Access |
VpnTunnel |
||
|
VMS user permissions |
|
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.
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.
Comments
0 comments
Article is closed for comments.