By using volume mirroring,
a volume can have two physical copies. Each volume copy can belong to a different pool, and each
copy has the same virtual capacity as the volume. In the management GUI, an asterisk (*) indicates
the primary copy of the mirrored volume. The primary copy indicates the preferred volume for read
requests.
When a server writes to a mirrored volume, the system writes the data to both
copies. When a server reads a mirrored volume, the system picks one of the copies to read. If one of
the mirrored volume copies is temporarily unavailable; for example, because the storage system that
provides the pool is unavailable, the volume remains accessible to servers. The system remembers
which areas of the volume are written and resynchronizes these areas when both copies are available.
You can use mirrored volumes for the following reasons:
- Improving availability of volumes by protecting them from a single storage system failure.
- Providing concurrent maintenance of a storage system that does not
natively support concurrent maintenance.
- Providing an alternative method of data migration with better availability characteristics.
While a volume is migrated by using the data migration feature, it is vulnerable to failures on both
the source and target pool. Volume mirroring provides an alternative because you can start with a
non-mirrored volume in the source pool, and then add a copy to that volume in the destination pool.
When the volume is synchronized, you can delete the original copy that is in the source pool. During
the synchronization process, the volume remains available even if there is a problem with the
destination pool.
- Converting between fully allocated volumes and thin-provisioned volumes.