SVC/Virtualize FC sessions in CSM provide just basic capabilities for FC management. This limits users for building more complex FC solutions or provisioning capabilities. Especially when using Space Efficient volumes, or when cascaded / multi-target FC must be used, it is difficult to follow best practices for optimized system performance.
SVC recommends to use non-default cleaning rate and eventually non-default grain size when using space efficient volumes. If there are dependent FC relations, the grain size must also be the same for all dependent FC mappings.
CSM currently only supports to modify FC grain size or cleaning rate via a CSM server propertie for a given session. This is very impractical to use:
- Server property changes are not synchronized with Standby server and must be applied on both servers, otherwise the FC sessions use different properties after a CSM server Takeover.
- Server property changes are not directly applicable to active mappings (usually used for new mappings only)
- Server properties cannot be managed along with other FC Session properties
- different places where FC properties are defined and managed
- They also require Admin role, where session property changes require only Operator role.
- None of the actual FC session properties match the recommended pre-sets recommended in the SVC GUI, therefore implementing any of these presets with CSM requires manual editing of the server properties per FC session.
- Snapshot --- background copy rate = 0, cleaning rate = 0
- Clone --- background copy rate =50, cleaning rate = 50, auto-deletion = yes
- Backup --- background copy rate = 50, cleaning rate = 50, incremental = yes.
Additional limitation exists for the FC Restore capabilities...
On the hardware, a Restore is another FC CG with new mappings in reversed direction, creating a kind of Cascaded FC loop (= FC dependency). It is not possible to terminate only the Restore FC without deleting the normal FC CG/mappings. Consider the use case for a restore within an FC backup generation chain:
If a restore of a potentially good FC image is done using Restore (with copyrate = 0 to limit copy while investigating the restore image), it might be detected that the restore image is not usable and another backup image of the chain must be restored. If the Restore mappings as well as the normal FC mappings in the chain must be deleted, this may trigger lots of cleaning activities in dependent FC relations on the hardware before another FC image can be restored to the host volumes, thus negatively affecting the overall recovery time.
Following improvements would simplify FC management for SVC/Virtualize solutions:
- Add changeable session property for Background Copy Rate, Cleaning Rate and Grain Size in GUI/CLI/REST API
- A change in grain size can only be applied for new mappings, it should not affect existing mappings. It may result in HW errors when new mappings are created if the are dependencies of other mappings using different grain size
- Change in cleaning rate or background copy rate should be directly applied to active mappings
- e.g. for converting NoCopy type relation to full copy, or to dynamically increase cleaning rate if cleaning holds up subsequent FC actions for dependend mappings.
- Background copy rate and cleaning rate for Restore mappings should be independently managable. For example if you want to change the change the background copy rate from 0 to a higher value when you found the "proper restore".
- If the use case of a Clone via CSM session is required, there is no support yet for the SVC mapping property "auto-deletion = yes/no", mentioned above for the SVC GUI preset Clone. There should be a way to change this property in advance (before the mapping is started) as well as when the FC mapping is already active (use case: you found the "proper restore" and restore mappings could be deleted after background copy completed).
- The Restore mappings should be deletable without deleting the normal FC mappings
- A command should allow to transition from the Restored state back to the previous Target Available state (deleting only the restore mappings without completing their background copy). This capability is not possible with DS8000 family, but with SVC/Virtualize family
- It can help to avoid unnecessary cleaning activities on HW if restore image can be discarded
