A SnapView enabler gives the user access to both Snapshot and Clone technology. These two methods of making poin-in-time copies are independent. They use vastly different replication mechanisms and have limits which are independent of each other.
Snapshots
Snapshots use pointers to indicate where data is currently located. It may be on the Source LUN (Traditional, Thick, or Thin) or may have been copied to the Reserved LUN Pool. As a result of the Copy on First Write (COFW) technology used, Snapshots may use appreciably less additional space than a full copy, such as a Clone, would use. As a rough guide, a Snapshot will use around 20% of the space occupied by its Source LUN.
Clones
Clones, on the other hand, make a full copy of the Source LUN data, and therefore use additional disk space equal to 100% of the space occupied by the Source LUN. Because Clone data can be copied back to the Source LUN, there is a requirement that Source LUN and Clone be exactly the same size. When a Clone is fractured, changes to the Clone or its Source LUN are tracked in the Fracture Log.
SnapView terminology
- Production host – server where customer applications are executed, and source LUNs are accessed from the production host
- Backup (secondary) host – host where backup processing occurs, offloads backup processing from production host, snapshots and clones are accessed from backup host
- Admsnap utility – an executable program that runs interactively or with a script to manage clones and snapshots.
- Source LUN – Production LUN, from which replicas are made
- Activate – when a snapshot is activated it maps a snapshot to an available snapshot session. The snapshot is a point-in-time view of the LUN and can be made accesible to a secondary host, but not to the primary host once a snapshot session has been started on that LUN
- Reserved LUN Pool (RLP) – private area used to contain Copy on First Write (CoFW) data
- Snapshot session –defines a point-in-time designation by invoking COFW activity for updates to the Source LUN
- Chunk – granularity at which data is copied from the Source LUN to a resreved area – 64kB
- Copy on First Write (CoFW) – when a chunk is changed on the Source LUN for the first time, data is copied to a reserved area
- Fracture – the process of breaking off a clone from its source. Once a clone is fractured, it can receive server I/O requests
- Clone group – contains a Source LUN and all of its clones
- Clone private LUNs – used for recording information that have been modified on the Source LUN and clone LUN that has been fractured. Due to that, you can synchronize a fractured clone.
SnapView features
The SnapView enabler allows the user the choice of Snapshots and/or Clones. The choice of which method to use depends on the specifics of the environment.The SnapView enabler allows the user the choice of Snapshots and/or Clones. The choice of which method to use depends on the specifics of the environment.
All Snapshot sessions are automatically persistent and save metadata to their Reserved LUNs. An advantage of Snapshots over Clones is if there is logical corruption of the data, this would be distributed to the Clones immediately if they are still in the unfractured state. In this example, the data on both the Source and the Clone would be damaged. If this were a Snapshot the data would not have changed at all. Point-in-time copies are also useful for backups and other operations. If there is a need to return the Source LUN to a previous data state, both Clones and Snapshots are capable of doing so.
Clones, however, achieve their persistence by tracking changed data extents using Clone Private LUNs. They can therefore survive planned and unplanned events, such as component failures, and the loss of power.
SnapView Clones vs SnapView Snapshots
While both Clones and Snapshots are each point-in-time views of a Source LUN, the essential difference between them is that clones are exact copies of their sources (with fully populated data in the LUNs), and are not based on pointers. It should be noted that creating clones takes more time than creating Snapshots, since the former requires actually copying data. A clone can be described as a copy of the data, whereas a Snapshot is a view of the data.
Another benefit to the clones having actual data, rather than pointers to the data, is that the performance penalty associated with the Copy-on-First-Write mechanism is avoided. Clones generate a much smaller performance load on the source LUN than do Snapshots. If the source LUN has a heavy write load, especially if those writes are randomly distributed on the LUN, then a clone has a lower performance impact than a Snapshot.
Because clones are exact replicas of their source LUNs, they generally take more space than SnapView Reserved LUNs, since the Reserved LUNs only store the Copy-on-First-Write data.Because clones are exact replicas of their source LUNs, they generally take more space than SnapView Reserved LUNs, since the Reserved LUNs only store the Copy-on-First-Write data.
An additional Clone advantage is that a clone can be moved to the peer SP for load balancing. It is automatically trespassed back to the owning SP for synchronization operations.
Any info on configuring snap view on a sparc Solaris 10 host
can you please post video explain mirrorview, san copy and recover point please….