Sun Storage Availability Suite: Procedure For Accessing Data On The Secondary System When The Primary Server Is Unavailable (Doc ID 1607521.1)

Last updated on AUGUST 16, 2019

Applies to:

Goal

Sun Storage Availability Suite (AVS) incorporates two distinct modules :

• Remote Mirror (RM) also known as StoreEdge Network Data Replication (SNDR) or Remote Data Copy (RDC)
• Point-in-Time Copy (PitC) also known as Instant Image (II)

Remote Mirror (RM) is used to replicate disks, disk slices and logical volumes across a network to a remote server. Point-in-Time Copy (PitC) is used to snapshot/copy disks, disk slices and logical volumes locally.

This document will cover a disaster recovery test from primary to secondary server. In a disaster where a primary non-cluster server has failed, a system administrator can move the primary production services to the secondary server to which the application data/volumes had been replicated.

To simulate this situation and to prove that, if the primary crashed and could not be recovered, an administrator can reconfigure with the secondary to gain access to the replicated data with the following procedure.

The recommended procedure for accessing data on the secondary system is to put the associated AVS volume sets into "logging" mode before mounting the secondary volumes. This is to ensure that replication is stopped and no further updates (accidental) are sent from the primary to the secondary volume. If the secondary volume is mounted and replication continues from the primary to the secondary, then this risks corruption of the data in the secondary volume. When the secondary volume is mounted there should be no further replication from the primary to the secondary.

In a controlled situation it should be possible to guarantee the consistency of the filesystem on the secondary volume. Before shutting down the primary server stop all I/O and unmount all the file systems on the primary volumes, and then put all the volume sets into "logging" mode using the sndradm command.

The file system unmount ensures that all data is flushed from the system onto the disk, and putting the sets into "logging" mode destages this data and halts further replication beyond this consistent state. It should then be possible to mount the secondary volumes on the secondary host without the need for fsck. In a real-life situation when the primary server becomes unavailable, sometimes fsck of the secondary volumes will be required. This is because, at the time of the incident, the data replicated to the secondary volume may not be in a completely consistent state, as most likely the file system on the primary volume will be mounted with I/O ongoing. Fundamentally this is an issue with the UFS file system, which does not always guarantee a consistent state on disk for a file system. It is the same reason that sometimes UFS filesystems will need to be fsck'ed on a system during the reboot following a crash.

This procedure is not intended for use where one or more of the servers involved is running cluster sortware. In cluster configurations the design normally includes failover/switchover procedures between servers or datacenters.

Solution