Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Storage-based mirroring terminology

When mirror relationships are in place, the storage automatically mirrors all data from SDs that it calls P-Vols to SDs of the same capacity called S-Vols, causing no overhead on the server.

In most circumstances, a primary SD is a P-Vol and a secondary SD is an S-Vol. The two exceptions are:

  • If storage-based snapshots are in use, V-Vols (SDs on which snapshots of spans reside) are also considered to be primary SDs, because the server mounts file systems on them. However, storage-based snapshots and storage-based mirrors cannot be used together on the same span. For further information, see the storage-based-snapshot CLI man page.
  • If the P-Vols are destroyed, the Administrator can place the mirror relationships into a special SSWS state. In this situation, the Administrator configures the server to treat the surviving S-Vols as primary SDs and perform I/O to them.
The server always does I/O to primary SDs and never to secondaries, although it is capable of reporting and warning about secondary SDs' statuses.

There are various types of mirrors as follows:

  • A synchronous mirror, such as TrueCopy, copies data as soon as the server writes it. In a healthy system, P-Vols and S-Vols have identical contents. If the P-Vols are lost, the server can fail over to the secondaries with a break in service but with no loss of data.
  • An asynchronous mirror, such as TrueCopy Extended Distance, copies data from P-Vols to S-Vols at fixed times or on demand. Failover discards all writes since the data was last mirrored. However, an asynchronous mirror needs less bandwidth than a synchronous mirror and may offer improved performance.
  • A near-synchronous mirror, such as Hitachi Universal Replicator (HUR), copies data from P-Vols to S-Vols as soon as possible, but not instantaneously. Failover typically discards some recently written data, but less than with an asynchronous mirror. A near-synchronous mirror offers the same bandwidth and performance advantages as an asynchronous mirror. ShadowImage works in this way if mirrored pairs are kept synchronized.
  • A copy-on-write mirror, such as Hitachi CoW, efficiently stores one or more snapshots of each SD. The server does not usually fail over to these snapshots; instead, snapshots can efficiently be copied back to the SDs used by the server. The advantages of CoW are its efficient use of disk space and the speed with which a snapshot can be created. ShadowImage works in this way when its point-in-time snapshot capability is in use. For information on using copy-on-write mirrors in which multiple snapshots of a span are visible at once and multiple snapshots of a filesystem are mounted simultaneously, see the storage-based-snapshot CLI man page. Storage-based mirrors cannot be set up on a span that is in snapshot mode.
  • A Global Access Device mirror does not require the Administrator to configure GAD mirror relationships into the server. GAD failovers are non-disruptive and do not require file systems to be unmounted.

To distinguish clearly between SDs during failover, we refer not only to primary and secondary SDs but also to production and backup SDs. Production SDs are used for everyday work; backup SDs are used if the production SDs should ever fail or whenever the administrator wishes to test the failover procedure. In normal use, production SDs are P-Vols and treated as primaries and backup SDs are S-Vols and treated as secondaries. Typically, if a problem occurs, the Administrator makes the NAS server treat treat the backup SDs as primaries and perform I/O to them. This involves either swapping mirror roles so that the production SDs become P-Vols or moving the mirror relationships into the SSWS state and temporarily configuring the S-Vols as primaries.

 

  • Was this article helpful?