Administrator Guide

The following considerations apply when using replication for disaster recovery:
If the original source NAS volume is no longer available, you can congure the recovery NAS volume to replicate to another NAS
volume in the original source FluidFS cluster. However, if the original source NAS volume is available, fail back to it. Failing back to
the original source NAS volume usually takes less time than failing back to a new NAS volume. If the FluidFS clusters have a
common snapshot, they only need to synchronize the data that changed after that snapshot was created. If no common
snapshot is available, or if replicating to a new NAS volume, all data must be synchronized.
A single FluidFS cluster cannot contain two sets of SMB home shares. Consider the example that Cluster A and Cluster B both
have SMB home shares, for dierent sites or user bases. Cluster A and Cluster B both serve as replication destinations for each
other’s NAS volume that contains the SMB home shares. If the administrator tries to fail over Cluster A’s NAS volume that
contains SMB home shares to Cluster B, Cluster B rejects this operation because it already has SMB home shares dened on it.
Managing the DNS Conguration for Single NAS Volume Failover
For single NAS volume failover, it is important that the environment is set up to properly migrate clients of the NAS volumes you are
failing over, without disrupting the clients of other NAS volumes you are not failing over.
When a NAS volume is failed over from one FluidFS cluster to another, the IP addresses that are used to access it change from
Cluster A’s IP addresses to Cluster B’s IP addresses. You can facilitate this change using DNS. It is recommended to set up a DNS
entry to correlate to each NAS volume, and change the DNS entry for single NAS volumes when they are failed over.
For example, suppose Marketing and Sales have their own NAS volumes, each with an SMB share on the NAS volumes named
marketing_share and sales_share respectively. A DNS entry named FluidFSmarketing, is created for Marketing and another DNS
entry for Sales named FluidFSsales is created. Both NAS volumes point to the same set of client VIPs on source Cluster A.
Marketing can access the Marketing NAS volume or SMB share using \\FluidFS marketing\marketing, and Sales can access the
Sales NAS volume or SMB share using \\FluidFSsales\sales.
Initially, both DNS entries FluidFSmarketing and FluidFS sales point to the same set of client VIPs. At this point, both the marketing
and sales SMB shares can be accessed from either one of the DNS names, FluidFSmarketing or FluidFS sales. When you want to
fail over a single NAS volume (for example Marketing) change the DNS entries for FluidFSmarketing to resolve to the client VIPs
on Cluster B.
Maintain a table to track which DNS entries are used to access each NAS volume. This helps when performing failover and setting
up group policies.
Setting Up and Performing Disaster Recovery
This section contains a high-level overview of setting up and performing disaster recovery. In these instructions, Cluster A is the
source FluidFS cluster containing the data that must be backed up and Cluster B is the target FluidFS cluster, which backs up the
data from source cluster A.
Prerequisites
Cluster B is installed, but has no NAS volumes congured.
Cluster A and Cluster B are at the same FluidFS version.
Cluster B has dierent network settings (client, SAN, internal, and so on) than source Cluster A, however, Cluster A and Cluster
B must be able to communicate with each other so that replication operations can occur.
Cluster B has enough space to replicate all data from Cluster A.
Phase 1 — Build up the replication partnership between Cluster A and Cluster B
Set up replication between Cluster A and Cluster B.
1. From Cluster A, set up a replication partnership between Cluster A and Cluster B.
2. Create a regular replication schedule so that the target volumes in Cluster B always have an up-to-date replication copy for
Cluster A.
The replication policy must be a one-to-one match on a volume basis, for example:
Source volume A1 (Cluster A) to target volume B1 (Cluster B)
Source volume A2 (Cluster A) to target volume B2 (Cluster B)
FluidFS Data Protection
457