A four-node AHV cluster reports 92% storage utilization and a six-week runway; CPU and memory are below 45%, and data reduction is already enabled. You must restore capacity without adding unnecessary compute. What should you do?
Select an answer to reveal the explanation.
Short Explanation
Think of this like a warehouse full of shelves but empty forklifts. Your bottleneck is storage, so you buy shelves, not drivers. You add storage-only nodes to extend runway without wasting CPU capacity.
Full Explanation
When Prism Central shows a short storage runway while CPU and memory remain low, the correct expansion target is capacity, not compute. Storage-only nodes add disk capacity and participate in the storage pool, so usable space and runway improve without increasing CPU or memory headroom that the cluster does not need. This is the efficient response when data reduction is already enabled and the bottleneck is physical or logical storage consumption. Adding general-purpose nodes would increase storage but also introduce unnecessary CPU and memory, changing cost and placement decisions without addressing the stated constraint. Enabling compression and deduplication is not the right answer because those features are already enabled and may not reclaim enough capacity quickly or predictably; they are efficiency tools, not guaranteed expansion. Scaling out compute-only nodes is wrong because compute-only nodes add processor and memory resources but do not increase storage capacity, so the runway remains constrained. Exam caveat: capacity forecasting must identify the dominant constrained resource before selecting node class or expansion type. Operational check: review Prism Central capacity runway, storage utilization, data reduction status, and node roles, then confirm storage-only node compatibility before adding capacity.