Storage Planning Isn’t Just Capacity

The first question is usually: “How many terabytes do you need?” It’s a valid question, but an incomplete one. In critical environments, storage also involves performance, availability, recovery, security, and operational predictability. Capacity is one part of the design — not the whole design.

Capacity is a variable

Before defining terabytes, there are better questions to ask:

• What’s the workload, and what’s its I/O profile?
• What latency is expected, and what growth is projected?
• What’s the Recovery Point Objective (RPO) — how much data can you afford to lose?
• What’s the Recovery Time Objective (RTO) — how long can you afford to be down?
• What’s the backup window, and what’s the actual restore time?
• What’s the impact of a controller going down? Of a site going down?
• Does the environment maintain availability during a takeover, and does performance stay within what’s needed afterward?
• Who can delete snapshots, and who can change policies?
• Does replication protect the environment, or just replicate the problem?

These answers define the architecture. Everything else is sizing.

Availability needs to be designed

High availability doesn’t just mean having two controllers. The point is understanding how the environment behaves during a failure. In a takeover scenario, one controller assumes the other’s services — availability is preserved, but the load becomes concentrated on fewer resources.

The capacity constraint is direct. A two-node pair where both nodes run at 70% CPU at peak cannot deliver full performance after a takeover — the surviving node is being asked to do 140% of a node’s work. If performance during takeover matters (and for anything that justified an HA pair, it does), size for the surviving node carrying both workloads: a conservative starting point is keeping sustained per-node utilization around 50% at peak, or having an explicit, written-down answer for exactly what degrades and by how much when one node is out. CPU and workload behavior do not always combine linearly during takeover, so validate the target against the controller model, protocol mix, workload profile, and observed takeover performance rather than treating 50% as a universal limit. Two commands tell you where you stand today:

storage failover show
statistics show-periodic -object system -counter cpu_busy

The first confirms takeover is actually possible — not assumed possible — on both nodes. The second, run during your real peak window rather than at 10 a.m. on a quiet Tuesday, is the number to hold against that 50% line. An environment can meet its targets with all controllers active and fall below them when one controller is unavailable.

The right question isn’t just “Does the environment have HA (High Availability)?” The right question is: “Does the environment keep delivering the required service level during the takeover?” That analysis changes how you evaluate CPU, cache, ports, throughput, IOPS, latency, aggregates, SAN/NAS paths, and growth.

Technology doesn’t fix a bad premise

ONTAP, SAN, NAS, object storage, SnapMirror, MetroCluster, backup, cyber recovery, Kubernetes, VMware, and cloud are tools. Good tools help, but they don’t replace architecture. If the design doesn’t account for failure, operation, security, recovery, and growth, the environment is limited from the start — even with good hardware.

About this blog

This blog is about storage, data protection, and cyber resilience. The goal is to share architecture decisions, troubleshooting, sizing, best practices, and field lessons — with objectivity, technical context, and a focus on real environments.

Storage isn’t just a shelf, a disk, a controller, or a terabyte. Storage is a critical layer of business continuity. The more critical the data, the more important it is to properly design availability, recovery, and operation.

Version and source note

Command availability and performance behavior vary by ONTAP release and platform. Validate the design against the current ONTAP documentation and test takeover behavior with the real workload before using any utilization threshold as a production limit.