Config Guide
AssuredSAN 3xx4
83-00006911-00-01 Rev B
Page 24
which do not, that small amount of data will remain at risk until the entire VDisk has been rebuilt. Also, performance
suffers during the entire rebuild.
Another exposure is encountering a media error. If the array is rebuilding two drives and encounters a media error on
a third, the rebuild will fail. This leaves the VDisk in a critical state, exposed, and with no way to rebuild the VDisk.
It is especially unfortunate if this media error resides in unallocated space. The outcome is the same, linear storage
must assume all stripes contain customer data.
With the introduction of Virtual Storage, we have a new set of technologies to improve these conditions. RealStor
enables Virtual Disk Pools which track how much data has been allocated for each Volume and where it resides in the
Pool, at a granularity of 4 MB. The Virtual Pool algorithm decides where to allocate each new 4 MB page.
Advantages of Quick Rebuild:
LUNs are spread across many RAID sets, so one RAID set rebuilding only affects a fraction of all disk I/Os.
Less rebuild work to do – so affected disks can return to full performance quickly.
Volumes become fault tolerant more quickly – user data is restored to full protection more quickly.
The rate of a RAID rebuild is directly proportional to the amount of unused disk space in a Virtual Disk Pool.
8.6.
RealSnap: Advanced Copy Services / Snapshots
Unlike prior AssuredSAN arrays which use VDisks, RealStor users will create storage pools by creating and adding
Virtual Disk Groups into a Virtual Disk Pool. The new copy services will run within these pools and leverage the new
storage page design. RealStor will allow the existing COW snapshots and the new Virtual Snapshots for Virtual Disk
Pools to coexist on the same system.
8.6.1.
Differences between Copy on Write (COW) and Redirect on Write:
The biggest differences between the two types of snapshots are the underlying technique used to manage the location
of the data that needs to be preserved. When an application writes to a disk using COW, the snapshot engine copies
the contents of the block(s) being overwritten to a new location (snapshot pool), whereas Redirect on Write snapshots
write the new data to a new page in the storage pool and updates the internal pointers to indicate the location of the
most up to date copy of the data.
Where COW requires three I/O’s to complete the operation, Redirect on Write only requires one I/O (write the new
data to disk). The advantage of this is the host application does not suffer the inherent performance penalties that exist
with the legacy COW snapshots.
8.6.2.
Redirect on write snapshot overview:
A snapshot is in theory a new volume with pointers that reference the original volume’s data. To do this we create a
new volume for all new incoming writes, create page tables and data structures within the storage pool that duplicate
the original volume to keep track of all references for the volume.
A reference count in the page tables is used for each allocated page in a volume to record how many volumes
(snapshots) use it. Since reference counts are shared by multiple volumes (snapshots), they are not stored with the
volume. They are instead kept in the component object in cache for fast access.
If the volume reference count is 1 then writes will continue as if the volume were a standard volume. If the reference
count increases copy services will know a snapshot of that volume has been taken and allocate a new page from the
storage pool. When a snapshot is deleted the volume reference count is reduced by 1 and the relevant volume
(snapshot) is deleted.
Some Frequently Asked Questions about the new design:
Q: Is a snapshot pool required to use the new copy service?
A:
No, the new design removes the requirement for a snapshot pool. There is a small volume created within the
storage pool for pointers.
Q: Are there any performance penalties using the new copy services?
