HP Storage Provisioning Manager (SPM) version 2.1 User Guide

1. When the storage administrator manually re-syncs a volume, SPM will verify that the parent
pool has not changed. If it has, SPM will either:
a. Move the volume under the new pool if that pool is managed by SPM.
b. Put the volume offline if the new pool is not managed by SPM.
2. During volume discovery for a given pool: SPM will detect volumes already managed by the
catalog that were moved to or from the pool and re-syncs those volumes, thus falling back
into case (1) above.
3. Periodically, SPM re-syncs all resources in the catalog. When this happens, volume migration
will be detected and handled as described in case (1) above.
The main side effect of volume migration, particularly when automated, is that the parent pool will
change as mentioned above and the raid level of the volume may change. As a result, allocated
services that specify ‘UseResource' or ‘RaidLevel' requirements may become nonconformant.
Importing a large number of volumes
The SPM catalog can handle tens of thousands of objects. Importing those objects into the catalog
in the first place, however, can be time consuming. SPM supports importing up to 5,000 volumes
at a time for 3PAR arrays. While the overall discovery and import time can vary depending on
volume configuration (particularly if they are presented to hosts) and network latencies, one should
count about half an hour to import 5,000 volumes. It is worth noting that:
1. Subscribed capacity for a pool is calculated as the sum of the subscribed capacity for all
volumes in the pool. This means that re-syncing pools containing a large number of volumes
can be time consuming
2. During discovery of a large number of volumes, Memory requirements increase dramatically;
The system SPM is installed on needs to be sized accordingly
Unique identification of common provisioning groups (CPG)
3PAR Storage Systems uniquely identify CPGs by their name. While this name is guaranteed to
be unique at any given point in time, it is not durable because, outside of SPM, a CPG can be
renamed or worse deleted and replaced by a new CPG carrying the same name. While renaming
CPGs or “recycling CPG names should be avoided if at all possible, such event can be remedied
manually, using the SPM GUI.
In the event a CPG was renamed, the storage administrator should:
1. discover and import the renamed CPG (i.e. a pool in SPM terminology), which SPM believes
is new
2. Re-sync all volumes in the CPG – This will cause SPM to move all the volumes under the CPG
imported in step (1)
3. Remove the old pool out of the catalog
4. Identify all services that mandate the use of the fore-mentioned pool and replace the specified
name appropriately so that the service is conformant again
In the event a CPG was deleted, all volumes in the CPG end up being deleted, which is catastrophic
as it results in data loss and inability for the application to access their volumes. Fixing this is
beyond the scope of SPM, however, the storage administrator should:
1. Re-sync the corresponding pool in SPM
2. Re-sync all volumes in the pool. As deleting a CPG results in the deletion of all volumes in that
CPG, the re-sync operation should result in putting all the volumes offline.
Backup and restore handling on 3PAR volumes
SPM supports backup and restore of 3PAR volumes by writing a management signature string to
every 3PAR volume managed by SPM. This string will be stored in the volume's Comment field in
the array. This field should not be modified manually using the 3PAR InForm Management Console
or by other means. For more information, see “Backup and restore” (page 17).
Importing a large number of volumes 73