SQL Server Sizing Consideration on Snapshots and Storage Based Replication

Snapshots and Clones

Many arrays now provide the ability to create snapshots or clones of LUNs. In addition, these technologies integrate with SQL Server backup functionality and provide the ability to back up large databases in a very short period of time. If you are working with these technologies, two main considerations have the potential to impact I/O performance:

• Snapshots are generally copies of LUNs that do not contain a full physical copy of the data. Instead the snapshot LUNs maintain the original data when any modifications are made on the source LUNs. Applications using the snapshot LUNs affect the source LUNs, because requests for any data that has not changed since the snapshot was created are directed to the original LUNs.
• Clones are full copies of source LUNs maintained by the storage system. Mirroring of source LUNs can affect performance of the source LUNs, because any modifications to the source LUNs must also take place on the cloned LUNs. This is especially true if the clone LUNs utilize fewer physical disks or are configured with a RAID level that introduces more overhead for writes.

Storage-Based Replication

It is becoming more and more common for SQL Server application deployments to utilize storage-based replication technologies for high availability and disaster recovery purposes. Storage-based replication can introduce significant effects on the application. This is especially true for deployments that use synchronous replication, because the network latency between storage arrays directly affects latency of I/O issued by SQL Server.