Storage Provisioning and Volume Management
This domain tests volume creation and lifecycle: thin provisioning, volume groups, host mapping, protection policy assignment, and capacity accounting. Expect questions that compare subscribed capacity with physical used capacity and ask which construct provides consistency.
Core rules
- PowerStore volumes are thin provisioned; there is no thick provisioning option. A 10 TB volume consumes only the blocks written, plus metadata.
- A protection policy containing snapshot and replication rules is assigned at creation; leaving a production volume on a weak policy is a design decision, not a default to ignore.
- Volume groups bundle volumes so snapshots and replication are consistent across the group. A volume belongs to at most one volume group.
- Mapping is to a host or host group, with an automatically assigned or manually chosen LUN ID. A volume can be mapped to multiple hosts when a cluster needs shared access.
- Volumes can be migrated between appliances in the same cluster without disrupting I/O, and clones can be created from snapshots for independent copies.
Capacity accounting
Distinguish three numbers: configured (subscribed) capacity, physical used capacity, and snapshot space. Thin savings are the difference between subscribed and physical. Capacity alerts should be based on physical used and snapshot growth, not on the sum of volume sizes.
Worked example
An administrator creates ten 1 TB volumes in one volume group and writes 30% of the data. Subscribed capacity is 10 TB; physical used is about 3 TB before snapshots. If a daily snapshot policy keeps seven copies and the data churns 10% per day, snapshot space grows with changed blocks, not with another 10 TB per copy. The correct planning figure is physical used plus projected snapshot growth, leaving headroom for rebuild and metadata.
Traps that cost marks
- Reporting subscribed capacity as consumed capacity, or sizing a purchase from volume sizes alone.
- Creating independent volumes for a multi-volume application that needs consistent snapshots instead of a volume group.
- Mapping a volume to a host without the correct initiator registered, then blaming the array.
- Assuming snapshots reserve a fixed percentage of the volume.