SnapView was designed to allow system backups to run concurrently with application processing. From your study of the prerequisite material, you’ll know how it produces point-in-time copies of LUNs, and allows secondary or backup hosts to access those snapshots.Even though backups are the primary use of SnapView, it is versatile enough to be used in other ways. For critical applications, snapshots may be taken every hour – this allows easy recovery from corrupted files. Decision support systems may also use the snapshots, and thus real data, with minimal effect to the application.For backup purposes, then, we need to ensure that good, consistent data was written to the backup medium. This will require host buffers to be flushed, and I/O to be halted until such time as the backup is completed. Without the use of snapshots, that down time could be several hours.
If the application uses several LUNs for storage – say, tables and logs are all on separate LUNs – then we need to ensure that all those LUNs are in the same state when we perform the backup. SnapView can take care of this as well – Release 19 added consistency support for SnapView Snapshots.SnapView Snapshots are a view of the data, not the actual data. As a result, creating a Snapshot and starting a Session is a very quick process, requiring only a few seconds. The view that is then presented to the secondary host is writable by that host, but will be a frozen copy of the Source LUN as the primary host saw it at a given time.
The mechanism uses pointers to track whether data is on the Source LUN, or in the Reserved LUN Pool. These pointers are kept in SP memory, which is volatile, and may therefore be lost, along with the Session information, if the SP should fail or the LUN be trespassed. An optional SnapView feature, therefore, is persistence for Sessions – this stores the pointers on disk, so Sessions can then survive SP failures, trespass operations, or power failures.
No comments:
Post a Comment