We are in the process of implementing our first SAN solution and we have two proposals, MSA 1000 from Compaq and FastT200 from IBM. Our major concern is the future of MSA 1000 after the HP-Compaq merger. Any news regarding the roadmap of MSA1000?
Another concern for our first SAN implementation is using the Snapshot feature of either IBM FastT200 or Compaq MSA 1000. If we take a backup of the Snapshot copy when restoring, will we get the full database?
Are there any documents about Snapshot that will explain the technology and the history of the Snapshot feature?
You will have to get the roadmap information from HP/Compaq on the future of MSA1000.
Snapshot copy can be done in a number of ways. There are software solutions that work at the host system level to provide "snapshot"(copy on write) functionality such as Veritas' or Compaq's Virtual Replicator, or Sun's Instant Image. Then there are firmware-based solutions done at the storage subsystem level. Your choice of which to use would depend on the number of host systems needing the functionality. Host-based solutions are licensed per server, where firmware-based solutions are priced per storage subsystem.
If you only have a few servers that need snapshot functionality, then using host-based software may be the cheaper way to go.
There are two types of "snapshots" available. Complete copy, a clone or exact duplicate of the original volume, and metadata-based copy that uses "copy-on-write" functionality. A metadata copy is very fast as it just copies the "pointers" to where your data is stored whereas the clone or complete copy copies the entire LUN to a separate physical disk. Metadata copies track which blocks on the disks are changed as you write to the original volume and does a "copy-on-write" to a designated pool of storage set aside for the snapshot. Copy-on-write moves the original data block to the snapshot before a write is allowed to that block. This keeps the snapshot data consistent in time with the exact time the snapshot was taken. Snapshot volume read requests to unchanged data blocks are redirected back to the original volume while read requests to data blocks that have been changed are directed to the "copied" blocks in the snapshot.
Metadata snapshots have an impact on performance on the original volume while they exist since write requests to the original volume must be "copied out" to the snapshot before the write is allowed.
Clone copies are more highly available since they are exact duplicates of the original volume that now reside on a separate physical disk. A clone can be made available by "splitting" a mirrorset volume into two JBODs or copied internally inside the storage array from one RAIDset to another. Check with your storage vendor for how this is performed.
If the mirrorset is already in place before the clone is taken, then the clone-based image will happen very quickly. If the original volume was a JBOD prior to issuing the clone command, then it will take time for the volumes to get in sync before the clone can be split off.
As for your database, the most common way of creating database clones or snapshots is to "quiese" the database prior to creating the snapshot. By "quiese" I mean stopping all writes to disk and flushing your file system cache. Doing this, will give you a transactionally consistent image that can be remounted without file system checks or database consistency checks.
Some vendors (like HDS) have firmware-based software that will flush host memory down to disk and freeze, then thaw I/O to disk as the snapshot is taken. This means you can keep the database (or mail system) up and running while the snapshot is taken. Check with your storage vendor to see if this capability is currently available on their arrays.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .bphAaR2qhqA^0@/searchstorage>discussion forums.
This was first published in July 2002