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 native 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.
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 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.
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 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 |
||
|
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. |
|
|
VMS user permissions |
|
To use identity policies and users' access keys that were replicated from the destination peer, you need to enable them:
-
To enable an identity policy: Enabling and Disabling Identity Policies
-
To enable an access key pair from the VAST Web UI: Enabling and Disabling a Key Pair
-
To enable an access key pair from the VAST CLI: user modify-key
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.