Alletra 5000 Capacity Crunch and Snapshot Retention
MetroHealth runs an HPE Alletra 5000 array with 180 TB usable capacity for 900 VMware VMs. InfoSight shows 84% capacity used, thin provisioning at 3.4:1, and a projection of exhaustion in 24 days. The array hosts 1,900 snapshots; 60% belong to three test/dev volumes with 90-day retention. Read latency is 8 ms, write latency 4 ms, and controller CPU is 38%. The organization has a 12-month capacity forecast of 18% growth. A new ERP project needs 25 TB usable in 60 days. The storage team proposes adding 60 TB raw shelves, disabling thin provisioning on all volumes, and deleting all snapshots older than 30 days. The CIO wants no performance impact and no data loss for production.
1. Evaluate the three proposals and recommend a capacity recovery plan that protects production data.
Read the worked answer
The proposals are not equally safe. Adding shelves is reasonable but should not be the first or only action. Disabling thin provisioning does not create free space; it increases allocated capacity and removes the flexibility that currently supports 3.4:1 oversubscription, so it wastes capacity and can accelerate exhaustion. Deleting all snapshots older than 30 days is dangerous because production snapshots may be the recovery points of last resort; it also conflicts with a 90-day retention policy for test/dev. Start by measuring snapshot space with InfoSight and the array, then expire only snapshots that are outside their documented policy and approved by the data owner. The three test/dev volumes are the obvious candidates, but confirm they are not needed for an active project. Keep thin provisioning, set per-volume quotas and snapshot limits, and create alerts at 70/80/90%. Add capacity only after reclaim, and size it for the ERP plus 12-month growth and headroom.
2. Size the ERP addition and determine whether the 60 TB raw shelf expansion is sufficient with no performance impact.
Read the worked answer
At 84% of 180 TB, about 151 TB is used. Twelve-month growth of 18% adds roughly 27 TB, and the ERP adds 25 TB, for about 203 TB of logical demand before snapshot reserve. A 60 TB raw shelf does not yield 60 TB usable after RAID and sparing; assume roughly 50 TB usable, taking the array to about 230 TB usable. That leaves about 27 TB, or roughly 12%, which is too thin for snapshots and normal operational headroom. Reclaiming test/dev snapshots and enforcing quotas should recover additional space; otherwise add more than one shelf or a larger shelf. Performance risk is low because controller CPU is 38% and latency is acceptable, but shelf addition and snapshot deletion can cause background reclaim. Schedule reclaim in a maintenance window and monitor latency during ERP deployment. Validate the final plan against a 20% free-capacity target, not just the day-one ERP requirement.
3. How should snapshot policy and change control be handled so that the capacity fix does not become a data-loss incident?
Read the worked answer
Separate policy by data class. Test/dev volumes can have 30-day retention if the owners agree in writing; production volumes should keep the approved 90-day retention until an explicit exception is approved. Do not delete snapshots by age alone; first map each snapshot to its volume, owner, and recovery purpose. Export the list, have application owners confirm which snapshots are obsolete, and delete in batches with capacity and latency monitoring. Preserve at least one recent recovery point per production volume. Use snapshot quotas so a runaway test/dev clone cannot consume the array again. Record the change in the change-management system with rollback criteria: if latency rises above an agreed threshold or capacity does not recover as predicted, stop. After changes, verify restore of a sample production VM and update the capacity forecast in InfoSight. This keeps the CIO's no-data-loss requirement intact while recovering space quickly.