Good post by W. Curtis Preston (thank you)
There are two very different ways to create snapshots: copy-on-write and redirect-on-write. If IT is considering using the snapshot functionality of their storage system, it is essential to understand which type of snapshot it creates and the pros and cons of using either method.
Rather than the more common term volume, this column will use the term protected entity to refer to the entity being protected by a given snapshot. While it is true that the protected entity is typically a RAID volume, it is also true that some object storage systems do not use RAID. Their snapshots may be designed to protect other entities, including containers, a NAS share, etc. In this case, the protected entity may reside on a number of disk drives, but it does not reside on a volume in the RAID or LUN sense.
Read on here
Posted by rogerluethy on April 27, 2016
Post by George Crump (thank you)
An increasing number of storage systems are coming to market with Quality of Service (QoS) functionality that allows an administrator to guarantee and in some cases, limit the amount of storage performance that a VMware or other virtualized workloads will experience. This is an important feature as the number and variety of workloads continues to increase in the data center. QoS should allow mission critical workloads to be intermixed with less critical workloads, without fear of the impact of a noisy neighbor stealing all available storage performance.
Read on here
Posted by rogerluethy on May 5, 2015
A simultaneous reboot of all nodes may occur if a FlashCopy consistency group is stopped without the use of the -force flag, or a target FlashCopy Volume is taken offline.
An issue exists in V188.8.131.52 only, in which all nodes may reboot simultaneously if either a FlashCopy consistency group is stopped without specifying the -force flag, or a FlashCopy target Volume that resides in a FlashCopy consistency group goes offline. This will result in a temporary, self-recovering loss of host access to all Volumes.
Since it is not always possible to predict when a FlashCopy target Volume offline event will occur, it is strongly recommended that all customers using FlashCopy consistency groups upgrade to a level of code containing the fix for this issue as soon as possible.
The only guaranteed workaround is to avoid the use of FlashCopy consistency groups altogether until the code has been upgraded to a level containing the fix.
If this is not practical, then at the very minimum the use of the -force flag should always be employed when issuing commands to stop FlashCopy consistency groups.
This issue is fixed by APAR IC78962 in the V184.108.40.206 PTF release.
Posted by rogerluethy on October 24, 2012