How 'suite' it is... - Jackie Gleason The "Availability Suite"

If you are looking for a single reason to consider adding Availability Suite to Solaris Express server, it would have to be the ability to perform the equivalent operation of the following dd(1m) command, but in just a fraction of a second, instead of its usual time of minutes, hours, or even days.

# dd if=/dev/rdsk/c1t0d0s1 of=/dev/rdsk/c2t0d0s1

The Point-in-Time Copy software (a.k.a, II or Instant Image) does this with the following command, and in just a fraction of a second, allowing both volumes to be instantly accessed for both read and write operations.

# iiadm -e dep /dev/rdsk/c1t0d0s1 /dev/rdsk/c2t0d0s1 /dev/rdsk/c2t0d1s1

Yes there is the addition of another disk partition (or other Solaris block device), being the II bitmap volume, but it is a volume that brings about the true capabilities of the Point-in-Time Copy software.

Fast-resynchronization - Ability to update either volume based only on the differences (caused by writes) to either or both volumes. Unlike the dd(1m) utility, where if one needs to perform the operation again another full volume copy is done, with II the operation still allows read or write access to both  , only the minimal

Independent Shadow Volume - Although initially dependent on the master volume, an independent shadow volume will in time become independent, allowing one to disable the set if they choose to, while retaining the Point-in-Time data. An independent set allows exporting the shadow volume from the current set, importing it on another Solaris host for both read and write access (backups, off-host process, etc.), and later returning the volume to the original host, joining it back with the master, leaving it a state as though it had never been exported, including the ability to perform fast-resynchronizations.

Dependent Shadow Volumes - Always dependent on the master volume, a dependent shadow volume has no background copy operation, always performing COW (copy-on-write) functionality. Due to the fact that only a portion of the shadow volume may be used (caused by writes), one can configure a compact dependent shadow volume, say at 25% the size of the original master volume size. If one had to configure four 1TB volumes, expecting no more then 25% change over the life of any Point-in-Time, an additional 1TB volume is all that is needed, something not possible with RAID-1 mirroring. If there was a chance that any or all of the volumes could exceed the 25% change, there is the means to associate a shared overflow volume, just in case.

There are no limits, other then Solaris limits, as to the number of shadow volumes that can be configured, including multiple shadow volumes of the same master volume. Each Point-in-Time Copy operates by itself, unless one or more sets are placed in an I/O consistency group, something needed for all the volumes in 'named' ZFS storage pool, QFS filesystems, or other data services where multiple LUNs act as one.

Besides supporting all Solaris filesystems, databases and applications, the volumes configured can be any Solaris block device (.../rdsk/...), including SVM, LUNs, lofi, zvols, independent of RAID types.