The storage section is where the report is most useful and most easily misread. Four numbers do most of the work.
IOPS, and why the number alone is meaningless
An IOPS figure without a block size is not a specification. Ten thousand 4 KB operations is 40 MB/s. Ten thousand 256 KB operations is 2.5 GB/s. These are wildly different systems and the IOPS number is identical.
So read block size first, then IOPS. Live Optics gives you an average block size, and the average is itself a simplification: most real workloads are bimodal, with a cluster of small transactional operations and a cluster of large sequential ones. An “average” of 32 KB may describe a workload that has almost no 32 KB operations at all.
Where the distribution is available, look at it. Where it is not, be suspicious of any sizing that leans hard on the average.
Read/write ratio, and what it does to the design
The write percentage is the number that changes the architecture. Reads can be served from cache and scale relatively cheaply. Writes must be committed, protected and eventually destaged, and on a RAID-protected system a single host write can become several back-end operations.
This is the write penalty, and it is why a workload that looks modest at the host can be demanding at the array. A 70% write workload is a different purchase from a 70% read workload at the same IOPS.
If a proposal does not visibly account for the write ratio, it has either been done at a level of abstraction that hides it, or it has not been done.
Latency, and the direction of causation
The report shows the latency the storage delivered. People read this as a measure of demand. It is a measure of supply.
If existing storage is slow, applications wait, submit fewer operations per second, and appear in the report as light workloads. Size the replacement from those numbers and you have sized for the throttled behaviour, not the actual demand. The new system will be faster, the applications will push harder, and the workload will grow to fill it in a way nobody predicted because nobody could see it.
Signs you are looking at a throttled workload: high latency in the report, flat-topped throughput curves, and application owners who complain about performance. If all three are present, treat the observed IOPS as a floor and ask the application owners what they actually need.
Data reduction, the most contested line
Somewhere the report or the subsequent sizing will assume a data reduction ratio, and that assumption will move the capacity figure enormously.
Reduction comes from two different things. Compression is fairly predictable by data type: databases compress reasonably, text compresses well, already-compressed media and encrypted data do not compress at all. Deduplication is entirely dependent on redundancy in the dataset — dozens of similar virtual machines dedupe beautifully, unique user data does not.
So a single blended ratio applied across a mixed estate is a fiction. Ask which workloads the ratio was derived from. If the answer is a general default, treat the capacity number as provisional and size a range.
The specific thing to watch: an estate with meaningful encrypted or already-compressed data, where a general ratio has been applied anyway. The error is silent and it is always in the direction of under-sizing.
Capacity: provisioned, used, written
Three different numbers that get used interchangeably and should not be. Provisioned is what was allocated, used is what the file system thinks is occupied, written is what the array actually holds. The gap between provisioned and written on a thin-provisioned estate with thick-provisioned virtual disks can be enormous.
Size from written, plan growth from used, and treat provisioned as a measure of how much housekeeping has been deferred.
Next, and last in this series: turning the collection into a proposal without hiding the assumptions.