Configuring storage-based mirrors

Procedure

1. Use your storage configurator to select a mirroring type (synchronous, asynchronous, etc...) and set up P-Vols and S-Vols. If mirrors are asynchronous, near-synchronous or CoW, place all the new mirror relationships into a single consistency group per span, so that the S-Vols always form a coherent point-in-time snapshot of the P-Vols. Wait until mirrors have completely synchronized. This can take many hours. Your storage configurator can report progress.

2. If the S-Vols are intended for use on the same cluster as the P-Vols, use the NAS server sd-list command to check that both primary and secondary SDs are healthy and visible to the server. Use 'sd-allow-access' to license (grant the server permission to use) all the SDs, including the S-Vols.

   1. If the P-Vols are intended for use on one cluster and the S-Vols on another, license on each cluster only the SDs to which that cluster is connected.

   2. In an advanced setup with more than two copies of the data, license only two copies: the primary SDs and the SDs to which you want this server to fail over.

   3. In advanced setup with two or more copies of the data, where one copy is mounted by a different cluster, license just two copies: the primary SDs and the SDs on which the other cluster mounts file systems. The other cluster's SDs will be unlicensed in a separate step.

   4. Do not license more than two copies of the data. This system does not permit more than two-way failover. There can be any number of copies of the data, but only two copies of each span can be loaded and only two copies of each file system can be mounted.

3. Provided that only the P-Vols and one set of S-Vols have been licensed and both are visible to the same server, use the sd-mirror-prepare and sd-mirror-detect commands to instruct the server to detect the mirror relationships set up in step 1. If the P-Vols are visible to one cluster and the S-Vols to another cluster, use the sd-mirror-remotely command instead. In exceptional circumstances, you may need to configure mirror relationships into the server manually. The sd-metadata command can help to identify relationships; the sd-list --raid-names command displays the same identifiers that storage configurators use to identify SDs. In complex configurations, set up relationships with the S-Vols that this or another cluster can eventually access -- even if those are not the S-Vols with an immediate mirror relationship to the P-Vols. The two SDs in a mirror relationship must be in the same tier, or both must be in no tier at all.

4. If mirrors are not synchronous, or if you want to forbid partial failovers for any other reason, use the span-set-site-id command to place the production SDs at site 1 and the backup SDs at site 2. There is no need for the two copies of the data to be geographically separate. Although it is not mandatory, we recommend the use of SD sites even with synchronous mirrors, because the server can respond to SD failovers faster than Storage Navigator can fail over all the SDs in a large span. Without SD sites, the result is a series of partial failovers, as the server repeatedly tries to mount file systems on a mixture of production and backup SDs.

5. If the filesystems on the S-Vols are to be mounted by another cluster:

   1. On the production cluster, which is connected to the P-Vols, use the span-add-cluster-uuid command to add the remote cluster's UUID to the span, so that each cluster can mount its own copy of the filesystems.

   2. Mounting the same copy of the file systems on two clusters can cause data loss. Therefore, on the production cluster, unlicense the S-Vols using the span-deny-access --secondaries command. Zone your switches to ensure that each cluster can see only its own SDs. No SD should be visible to both clusters.

   3. If necessary, synchronize mirrors, so that the secondary SDs contain on-disk configuration that includes both clusters' UUIDs.

   4. Break the mirror relationship nearest to the remote cluster, making its SDs into simplex P-Vols.

   5. Walk to the second cluster. Use the sd-allow-access command to license the second cluster's SDs. That cluster can now mount its copy of the file systems. Ensure that, on the backup cluster, you do not license the production cluster's SDs.

Parent Topic

• Replication and Disaster Recovery Administration Guide

  This guide provides information about replicating data using file-based replication and object-based replication, provides information on setting up replication policies and schedules, and using replication features for disaster recovery purposes.