1.2 Assessing Storage Requirements, Workload Sizing & SLAs

Sizing Storage Requirements, Workload Profiling & SLAs

Designing an enterprise storage architecture begins not with hardware selection, but with a rigorous discovery process. Storage architects must translate business priorities, user experience expectations, and operational budgets into quantifiable engineering metrics. Sizing a solution solely based on raw gigabytes almost guarantees failure: an array can offer petabytes of capacity yet crawl to a halt under transaction processing if random I/O latency exceeds application tolerances, or crash during an unpredicted morning login storm.

This section establishes the analytical framework required to assess customer technical requirements, calculate capacity accurately across storage layers, model workload performance dynamics, and architect infrastructure that meets stringent Service Level Agreements (SLAs).

---

Capacity Calculations: Raw, Usable & Effective

One of the most persistent sources of confusion in storage presales and design is the distinction between raw, usable, and effective capacity. Customers frequently describe their storage needs in terms of logical dataset sizes, whereas drive manufacturers advertise raw decimal gigabytes. A storage architect must bridge this gap systematically.

+-------------------------------------------------------------------------+
| Raw Capacity: Physical Drive Total (e.g., 24 x 1.92 TB SSDs = 46.08 TB) |
+-------------------------------------------------------------------------+
                                     |
                                     v  [Subtract RAID Parity, Hot Spares,
                                     |   System Metadata, Pool Reserves]
+------------------------------------+------------------------------------+
| Usable Capacity: Net Block Capacity Available for Volume Provisioning   |
| (e.g., RAID 6 / Triple Parity yields ~30.7 TB usable)                   |
+-------------------------------------------------------------------------+
                                     |
                                     v  [Multiply by Data Reduction Ratio
                                     |   (DRR) from Deduplication + Compression]
+------------------------------------+------------------------------------+
| Effective Capacity: Logical Data Stored Before Reduction               |
| (e.g., 30.7 TB Usable x 3.5:1 DRR = 107.45 TB Effective Capacity)        |
+-------------------------------------------------------------------------+

1. Raw Capacity

Raw capacity represents the absolute sum of the advertised physical capacity of all installed storage media within an array. For example, an array equipped with 24 solid-state drives (SSDs) rated at 1.92 TB each possesses:

Raw Capacity = 24 drives * 1.92 TB = 46.08 TB

Raw capacity does not account for RAID parity overhead, spare drive allocations, drive formatting differences (base-10 decimal gigabytes vs. base-2 binary gibibytes), or storage operating system metadata reservations. It is strictly a physical hardware inventory metric.

2. Usable Capacity

Usable capacity (also termed raw formatted or net block capacity) is the actual space available to create storage pools and provision volumes after accounting for data protection mechanisms. The primary deductions from raw capacity include:

• RAID Protection Overhead: Depending on the selected RAID level, a portion of the storage capacity is dedicated to parity or mirroring. For RAID 1/10, 50% of the raw drive capacity is consumed by mirroring. For RAID 5 (distributed single parity), one drive equivalent per RAID set is dedicated to parity. For RAID 6 (dual distributed parity), two drive equivalents per set are allocated to parity. Triple-parity schemes, such as the Triple+ Parity used by the Nimble-based HPE Alletra 5000 and 6000, dedicate three drive equivalents per set.
• Spare Capacity Allocation: Storage systems allocate either dedicated physical hot spare drives (typical with traditional RAID levels) or distributed sparing, where spare capacity is spread across every drive in the group, as in MSA-DP+ disk groups on the HPE MSA and on the HPE Alletra Storage MP B10000.
• System Overhead & Metadata: Storage operating systems (such as HPE Alletra Storage ArcusOS or the MSA firmware) reserve a fixed percentage of capacity for internal mapping tables, write journals, snapshot indices, and core volume management metadata.

3. Effective Capacity

Effective capacity represents the total volume of logical, uncompressed, non-deduplicated data that an enterprise can store on the physical array. In modern all-flash arrays (AFAs) such as the HPE Alletra Storage MP B10000, effective capacity is significantly higher than usable capacity due to inline data reduction technologies:

Effective Capacity = Usable Capacity * Data Reduction Ratio (DRR)

The Data Reduction Ratio combines several complementary software engines:

• Thin Provisioning: Allocates physical storage only when host applications write actual data, eliminating wasted space from unallocated volume reservations.
• Zero Block Detection: Hardware- or software-accelerated scanners intercept streams of continuous binary zeros and record metadata pointers rather than committing empty blocks to media.
• Inline Deduplication: Identifies identical data blocks across volumes or within a storage pool and retains only a single unique instance, replacing duplicate instances with lightweight pointers.
• Hardware-Accelerated Inline Compression: Uses high-performance algorithms (such as LZ4 or proprietary ASIC engines) to compress data blocks before writing them to persistent media.

Worked Example: A customer requires 120 TB of effective capacity for a VMware ESXi virtualization cluster hosting general enterprise workloads. Assume that assessment data shows this workload type achieves a conservative 3:1 Data Reduction Ratio. The required usable capacity is:

Required Usable Capacity = 120 TB / 3 = 40 TB

If the storage architect configures an array using RAID 6 (requiring approximately 25% parity overhead) plus a 10% reserve for system metadata and sparing, the required raw capacity is calculated as:

Required Raw Capacity = 40 TB / (1 - (0.25 + 0.10)) = 40 TB / 0.65 = 61.54 TB

---

The Performance Triad: IOPS, Throughput & Latency

Storage performance is governed by three interrelated physical metrics: Input/Output Operations Per Second (IOPS), Throughput (Bandwidth), and Latency. Sizing mistakes occur when an engineer focuses on one metric while ignoring the others.

The Fundamental Bandwidth Formula

Throughput, IOPS, and I/O transfer block size are mathematically bound by the following formula:

Throughput (MB/s) = (IOPS * I/O Block Size in KB) / 1024

Alternatively, to calculate required IOPS when throughput and block size are known:

IOPS = (Throughput (MB/s) * 1024) / I/O Block Size in KB

This relationship explains why high IOPS figures do not automatically translate into high throughput, and vice versa:

• An Online Transaction Processing (OLTP) database executing 10,000 IOPS with small 8 KB blocks produces: (10,000 * 8) / 1024 = 78.125 MB/s
• A video streaming or backup stream executing only 600 IOPS with large 1024 KB (1 MB) blocks produces: (600 * 1024) / 1024 = 600 MB/s

While the database produces nearly 17 times more I/O operations per second, the video stream demands more than 7.5 times more storage fabric and controller throughput.

+-------------------------------------------------------------------------+
| Workload Type     | Block Size | Primary Bottleneck  | Key HPE Feature   |
+-------------------+------------+---------------------+-------------------+
| Transactional DB  | 4 KB - 8 KB| IOPS & Latency      | NVMe & Multi-Core |
| Analytics / DW    | 64 KB+     | Throughput (MB/s)   | PCIe Gen4 Fabric  |
| Video / Media     | 512 KB - 1M| Fabric Bandwidth    | 100GbE / 32Gb FC  |
| Mixed VDI Steady  | 4 KB - 16KB| Random Write IOPS   | Write Caching/AFA |
+-------------------------------------------------------------------------+

Latency: Service Time vs. Queuing Time

Latency measures the total elapsed time from the instant a host application issues an I/O request until the storage subsystem returns confirmation. Total latency consists of two distinct components:

Total Latency = Service Time + Queuing Delay

• Service Time: The time required by the storage controllers, internal buses, and media to physically process and commit the I/O. For all-NVMe arrays (such as the HPE Alletra Storage MP B10000), service time is typically a few hundred microseconds. For mechanical HDDs, rotational delay and physical seek times dictate service times of 4 to 15 milliseconds.
• Queuing Delay: When the volume of incoming I/O requests exceeds the storage array's parallel processing capability, requests queue in controller buffers. Little's Law (average number of requests in the system equals arrival rate multiplied by time in the system) shows why: as more requests wait, each waits longer, and queuing delay climbs steeply as a controller approaches saturation, even if the underlying media is healthy.

Sequential vs. Random Access & Read/Write Ratios

Workload I/O behavior is characterized by two fundamental attributes:

1. Access Pattern (Random vs. Sequential):

   • Random Access: I/O requests reference disparate, non-contiguous block addresses across the logical unit number (LUN). Random I/O is common in relational databases, virtualized environments (hypervisors hosting multiple diverse VMs), and indexing engines. Random access stresses controller lookup tables and cache efficiency.
   • Sequential Access: I/O requests read or write contiguous logical blocks. Sequential I/O dominates media streaming, large file copies, sequential log file writing (e.g., database redo logs), and backup data streams. Sequential access stresses array backplanes, host bus adapters (HBAs), and storage fabric bandwidth.

2. Read/Write Ratio:

   • Storage writes are fundamentally more expensive than reads due to parity calculations, mirror writes, and metadata journal updates. This overhead is called the RAID Write Penalty:
     • RAID 1/10: 2 I/O operations per write (1 data write + 1 mirror write).
     • RAID 5: 4 I/O operations per write (read old data + read old parity + write new data + write new parity).
     • RAID 6: 6 I/O operations per write (read old data + read 2 old parities + write new data + write 2 new parities).
   • While traditional spinning disk arrays required complex write penalty calculations to avoid disk thrashing, modern arrays reduce write overhead with protected write caches (for example the MSA's supercapacitor-protected cache or the B10000's SSD-based write buffer), full-stripe writes and hardware RAID offload.

---

Service Level Agreements (SLAs), SLOs, RTO & RPO

Enterprise storage architectures must align with corporate business continuity and disaster recovery frameworks. Sizing conversations must establish strict technical boundaries around acceptable downtime and data loss.

SLAs vs. SLOs

• Service Level Agreement (SLA): A formal, contractual agreement between an IT service provider (or internal IT department) and business stakeholders that defines expected service availability, performance targets, and financial or operational penalties if thresholds are breached.
• Service Level Objective (SLO): A measurable, internal technical target that engineering teams use to manage infrastructure proactively. SLOs are intentionally set more strictly than SLAs. For example, if an SLA guarantees 99.99% uptime, the internal SLO might be set at 99.999% to provide an engineering safety buffer.

Recovery Point Objective (RPO) and Recovery Time Objective (RTO)

Two core metrics dictate the required storage replication, snapshot, and backup topology:

+-------------------------------------------------------------------------+
|                       DISASTER OCCURS AT 12:00 PM                       |
+-------------------------------------------------------------------------+
      [--- RPO Window (Data Loss) ---]  |  [--- RTO Window (Downtime) ---]
Last Storage Snapshot: 11:45 AM         |  Full Recovery: 02:00 PM
(RPO = 15 Minutes Data Loss)            |  (RTO = 2 Hours Downtime)

• Recovery Point Objective (RPO): The maximum acceptable age of data that can be lost following an unplanned outage or disaster, measured backwards in time. An RPO of zero requires synchronous replication over low-latency Fibre Channel or high-speed IP SAN fabrics (typically distances under 100 km with round-trip latency under 5 ms). An RPO of 15 minutes to 1 hour can be met with asynchronous array-level snapshot replication.
• Recovery Time Objective (RTO): The maximum tolerable elapsed duration between disaster declaration and full restoration of application services and storage accessibility. A near-zero RTO demands automated multi-site clustering (such as HPE Peer Persistence) that triggers automated, non-disruptive host failover without human intervention.

High Availability Tiers: The Spectrum of "Nines"

Availability is measured by the percentage of time a storage platform remains operational and accessible to host applications. Each additional "nine" represents an order of magnitude reduction in permissible annual downtime:

HPE offers a 100% Data Availability Guarantee on the HPE Alletra Storage MP B10000; it previously covered the Alletra 9000, which HPE has discontinued. The guarantee has qualifying terms and conditions, so read HPE's guarantee document before quoting it to a customer.

---

Workload Profiling & Headroom Planning

Accurate sizing requires profiling specific workload behaviors rather than sizing for average daily utilization.

Common Enterprise Workload Profiles

Headroom and Growth Planning

Storage systems must accommodate two forms of headroom:

1. Performance Headroom (Transient Spikes): Sizing an array for 80% controller CPU utilization during normal operations leaves insufficient headroom for burst events. When an anti-virus storm, snapshot deletion, or database index rebuild occurs, controllers will saturate, driving latency into seconds. Enterprise designs should target sustained peak utilization below 60% to 70% of maximum controller IOPS and bandwidth.
2. Capacity Headroom & Pool Saturation Thresholds: Modern copy-on-write and redirect-on-write snapshot engines degrade in performance when storage pools exceed 80% to 85% capacity. As free contiguous blocks become scarce, the storage controller must perform aggressive garbage collection and space reclamation. Best practices mandate maintaining a minimum 15% to 20% free pool headroom. Furthermore, customer data growth must be factored using Compound Annual Growth Rates (CAGR):

Projected Capacity = Current Capacity * (1 + CAGR)^n

Where n is the planned operational lifecycle in years (typically 3 to 5 years).

---

Architectural Decision Matrix: Sizing Storage for SLAs

---

Realistic Deployment Scenario: Regional Healthcare System

A regional hospital network operates three distinct workloads:

1. Electronic Health Records (EHR): Intersystems Cache / Epic database requiring 25,000 IOPS, 8 KB random blocks, 75/25 read/write ratio, sub-millisecond response times, and an RPO of zero with an RTO under 15 minutes.
2. PACS Medical Imaging Archive: 300 TB of DICOM medical images growing at 25% annually, sequential reads and writes with large 128 KB blocks, tolerant of 5 to 10 ms latency, RPO of 4 hours, and RTO of 8 hours.
3. Clinical Virtual Desktops (VDI): 1,500 concurrent clinician VMware Horizon desktops experiencing severe morning shift-change boot storms (8:00 AM) and shift-end logoff storms.

Architectural Sizing Analysis

• EHR Tier: Sizing this workload on hybrid storage with mechanical disks would fail due to the strict sub-millisecond latency requirement and zero RPO. The architect specifies HPE Alletra Storage MP B10000 arrays in two data centers with synchronous Remote Copy and Active Peer Persistence, backed by HPE's 100% data availability guarantee, all-active multi-node processing and sub-millisecond NVMe response times.
• PACS Tier: The PACS archive demands high usable capacity at an affordable cost-per-terabyte. If the PACS application can write to S3 object storage, the architect positions the HPE Alletra Storage MP X10000, which uses dense QLC flash and erasure coding to keep cost per terabyte down. For a small clinic, a capacity-oriented HPE MSA Gen7 with midline HDDs and SSD read cache is the budget alternative.
• VDI Tier: The VDI workload generates high random write ratios during steady-state and massive read/write spikes during boot storms. The architect places the desktops on an all-flash B10000 volume set, whose protected write buffer absorbs boot storms and whose inline deduplication works well on cloned desktop images. The reduction ratio used in the proposal comes from assessment data, not a rule of thumb.

---

Common Exam Traps

• Trap 1: Confusing Raw vs. Usable vs. Effective Capacity: Exam scenarios will state an initial capacity requirement and ask how many physical drives must be purchased. Never apply Data Reduction Ratios to raw capacity! DRR applies strictly to usable capacity. First determine usable space after RAID and spares, then apply data reduction to calculate effective capacity.
• Trap 2: IOPS vs. Throughput Disconnect: Watch for questions that state an array has plenty of IOPS but users report poor file copy or backup performance. A system delivering 50,000 IOPS with 4 KB blocks delivers only ~195 MB/s of bandwidth. If the SAN fabric or controller throughput saturates, adding more IOPS will not resolve the bottleneck.
• Trap 3: RPO vs. RTO Reversal: Exam questions often invert these definitions. Remember: RPO = data loss window (how far back in time data must be recovered); RTO = recovery time window (how long before systems are back online).
• Trap 4: Availability Guarantees Across the Portfolio: Do not assume every HPE array carries the 100% Data Availability Guarantee. It applies to the Alletra Storage MP B10000 (and applied to the discontinued Alletra 9000). The Nimble-based Alletra 5000 and 6000 carried a six-nines (99.9999%) guarantee. The MSA is a redundant dual-controller array, but HPE's availability guarantees are tied to the Alletra families, not the MSA.