How to Size HPE Alletra MP for Capacity, Performance and Recovery

A defensible HPE Alletra MP design is sized to the point at which capacity, peak performance or recovery commitments become limiting—not to the largest effective-capacity number on a quote. Build the requirement from measured workload behaviour over the planning horizon, then require the proposed configuration to show usable capacity and headroom in both normal and failure conditions.

The B10000’s scale-out architecture, RAID 6 layout, thin provisioning and always-on data-reduction options make simplistic calculations especially unreliable. Published platform limits are guardrails, not a sizing result. Controller topology, shelf count, drive type, software release, protection design and workload mix all affect the answer. QuickSpecs also sets hard configuration limits: at least eight drives per chassis; no mixing of drive capacities or TLC (triple-level cell) and QLC (quad-level cell) media in one system; and balanced drive quantities across shelves when expanding. (hpe.com)

What to gather before you size anything

A useful Alletra MP sizing workbook has a row for each workload class, not one grand total for “VMware”, “databases” or “file servers”. A SQL transaction log, a VDI (virtual desktop infrastructure) boot storm and a general virtual-machine estate may share an array. They should not be assumed to behave alike.

Collect at least 30 days of telemetry. Include month-end, backup windows, patching, reporting and known seasonal peaks where they apply. For each workload, capture:

• Used data and provisioned data: separate host-used capacity from logical capacity allocated to volumes or datastores. With thin provisioning, that distinction is non-negotiable.
• Growth: historic monthly growth, committed projects, migrations, retention changes and the planning horizon.
• Data type: separate database data and logs, virtual-machine disks, VDI, container persistent volumes, backups, media, encrypted datasets and already-compressed data.
• Performance: average and peak IOPS (input/output operations per second); read/write and random/sequential mix; I/O block size; queue depth; concurrency; throughput; and measured 95th and 99th percentile latency.
• Host connectivity: host count, cluster layout, expected paths per host, protocol, HBA (host bus adapter) or NIC (network interface card) speed, switch and fabric capacity, and whether connectivity survives a switch, port or controller-path failure.
• Protection: snapshot frequency and retention, application-consistent snapshot requirements, clone use, backup integration and immutable-copy policy.
• Recovery: recovery point objective (RPO), or tolerable data loss; recovery time objective (RTO), or tolerable outage; replication mode; site distance; and available intersite bandwidth.

HPE supports Fibre Channel, NVMe/FC, iSCSI and NVMe/TCP host connectivity on the B10000. Protocol choice determines the ports, optics, switch capacity and multipathing work the design needs; it does not prove an application will get its required latency. Protocol fit across FC, NVMe/FC, iSCSI and NVMe/TCP sets out the practical differences.

Step 1: Define capacity terms before discussing a ratio

Storage suppliers use capacity terms loosely enough to cause avoidable disputes. Put these definitions in the design document, and require the quote to use them consistently, in either TB or TiB.

The B10000 uses RAID 6 with distributed parity and system-wide sparing across chunklets, rather than a simple dedicated-hot-spare model. Metadata and shared data are allocated through common provisioning groups (CPGs). This architecture means “raw minus two disks” is not a valid substitute for the configurator’s usable-capacity figure. (hpe.com)

There is another complication. HPE’s public StoreMore material has described a usable-to-effective ratio for reducible data, while current public material varies by market and offer: one EMEA storefront refers to at least 4:1, newer US material refers to 5:1, and HPE describes personalised effective-capacity guarantees for specified workloads. Treat a guarantee as a commercial commitment with eligibility conditions, not a universal technical forecast. Check the regional terms, workload treatment and quoted effective capacity before purchase. (hpe.com)

Step 2: Calculate the capacity requirement in layers

It should be a traceable design pack showing that every workload’s capacity, peak performance, connectivity and recovery requirements can be met at the planning horizon, with declared reserves and a stated failure scenario.

Start at the planning horizon. Take current used data for each workload, add known migrations or projects, then apply a growth assumption supported by history. Don’t apply one ambitious reduction ratio to the total.

A usable planning formula is:

Primary pool demand = reduced primary data + snapshot change demand + local operational reserve

For mixed data, calculate reduced primary data as:

(reducible data ÷ conservative observed reduction ratio) + unreducible data

For sizing, encrypted at the host, already-compressed, image, video and backup data should normally be treated as unreducible unless assessment evidence says otherwise. Thin provisioning is not data reduction, either. It avoids allocating unwritten blocks; it does not make consumed data disappear.

An illustrative calculation

Assume an estate is expected to contain 130 TiB of application data at the planning horizon. Assessment data suggests 80% is reducible, but the design uses a modest 1.8:1 ratio rather than a headline promise. Treat the remaining 20% as 1:1.

• Reducible portion: 104 TiB ÷ 1.8 = 57.8 TiB
• Unreducible portion: 26 TiB × 1 = 26 TiB
• Estimated primary data consumed: 83.8 TiB
• Snapshot allowance, based on measured changed-block behaviour and retention: 12 TiB
• Subtotal: 95.8 TiB
• Twenty per cent operational and growth reserve: 19.2 TiB
• Target primary usable pool capacity: about 115 TiB

This is not an HPE configuration recommendation. It is the capacity target to enter into the HPE sizing tool with the performance and resilience inputs. HPE should then identify the drive count and media type that provide at least that usable capacity after platform overheads, while preserving the intended expansion path.

Give snapshots their own estimate. They initially share unchanged blocks with the parent, but their cost is driven by writes after the snapshot is taken. A heavily updated database with frequent, long-retained snapshots can consume more space than a much larger but quiet virtual-machine volume. HPE documents that snapshot data and thin-provisioned volumes draw from shared data space, while snapshot metadata has its own administration requirement. (hpe.com)

Replication needs its own capacity line, not a footnote. If the disaster-recovery (DR) array must run production after site loss, size its usable capacity, host connectivity and performance for the workloads that will run there. A secondary is not simply a passive disk bucket. Include retention, snapshots and recovery operations at the secondary site.

Step 3: Size performance for the peak that matters

Capacity determines how much flash is available. Performance drives controller class, node count, host-port layout and, in some cases, the sensible choice between TLC and QLC media. The B10000 can stripe data widely across drives and controller resources, but that doesn’t remove the need to understand workload behaviour. (hpe.com)

For each workload class, record the peak, not just the monthly average. Translate IOPS into throughput where necessary:

Throughput = IOPS × average I/O size

For example, 100,000 IOPS at 16 KiB is roughly 1.64 GB/s before protocol and operational overheads. A design can meet the IOPS total and still fail if sequential reporting traffic saturates links, or if bursty writes raise tail latency for a latency-sensitive database.

Ask for sizing against the intended latency target, not an unspecified “low latency” claim. Provide the required 95th and 99th percentile figures during peak load, alongside read/write mix, block size and queue depth. Where applications have different protection and latency needs, put them in separately observable workload groups and apply controls such as quality of service (QoS) with care. HPE’s Priority Optimization can set service objectives in throughput or I/O bandwidth terms, but QoS cannot create performance that was never bought. (hpe.com)

Step 4: Build replication and recovery into the design

The RPO should drive the replication approach and link design. HPE’s replication guidance is clear: RPO affects both replication mode and required link sizing. RPO zero requires synchronous replication; HPE states periodic asynchronous replication can be configured with a 15-second interval, giving a best-case 30-second RPO. Actual RPO still depends on change rate, link availability and whether the destination can keep up. (support.hpe.com)

Estimate replication bandwidth from changed data, not protected capacity:

Required replication bandwidth = changed data in the replication window ÷ available transfer time

Then allow for protocol overhead, contention, bursts, and initial synchronisation or resynchronisation. A link that handles the average daily delta may be inadequate when a database reload, ransomware recovery, migration or site return produces an exceptional delta set.

Availability design needs one blunt question: what failure must the service survive without missing its SLA (service-level agreement)? A local controller or drive failure, a fabric failure and whole-site loss are different events. HPE describes redundant components, N+2 fault tolerance and RAID 6 distributed parity, but cross-site application availability still depends on the host cluster, fabrics, quorum/witness design and replication topology. Hardware resilience is necessary. It is not the recovery design. (hpe.com)

Step 5: Make the supplier prove the design

Before sign-off, give HPE or the partner the assessment export and request a written design response. At minimum, ask:

• Which B10000 controller-node configuration, drive media and drive count are proposed, and why?
• What usable capacity remains after all platform overheads under the proposed configuration?
• What reduction ratio has been used for each workload class, and which data is assumed unreducible?
• What is the capacity position at the agreed planning horizon, including snapshots, local reserve and DR?
• What peak IOPS, bandwidth and tail-latency target should the design meet, and under which test profile?
• What happens to performance and available capacity during a drive, shelf, node, port or fabric failure?
• How long will initial replication and full resynchronisation take over the available links?
• Which software release, supported host versions, multipathing guidance and interoperability matrix apply?
• What is the non-disruptive expansion route, given that drive type and capacity cannot be freely mixed in one system?

The last question catches a common procurement mistake: buying the smallest configuration that works today, then finding that the economical upgrade does not fit the original media or shelf design. Current B10000 QuickSpecs distinguishes switchless and switched expansion limits, and classifies switched systems with nine to 16 expansion shelves as capacity-optimised; those configurations require ArcusOS 10.4.0 or later and do not support 30.72 TB QLC drives. Check such constraints against the QuickSpecs current at order time, not an old slide deck. (hpe.com)

Verification: what a successful sizing exercise looks like

The result should be more than a bill of materials. It should be a traceable design pack showing that every workload’s capacity, peak performance, connectivity and recovery requirements can be met at the planning horizon, with declared reserves and a stated failure scenario.

Validate the design in one of two ways. For an established estate, use assessment data from hosts, hypervisors, storage-area-network (SAN) switches and the current array, then reconcile it with application-owner expectations. For a new, unusual or latency-critical workload, run a proof of concept with a representative I/O trace or carefully built synthetic profile. Test baseline load, credible peak load, snapshot creation, replication lag, and recovery or resynchronisation behaviour. Measure latency percentiles at the host, not only on the array dashboard.

If a proof of concept changes system state, isolate it. Use test volumes and a non-production host or datastore, document every mapping and replication relationship, and export performance results before cleanup. The safe rollback is to stop test I/O, remove host mappings, and delete test replication groups and snapshots only after confirming that no production object shares them. Retain the evidence and configuration record. Don’t perform destructive cleanup by name alone.

Common sizing mistakes and quick fixes

• Using headline effective capacity as purchased capacity. Replace it with a workload-by-workload forecast and a quoted usable-capacity figure.
• Assuming every workload reduces equally. Start encrypted and compressed data at 1:1. Use observed, conservative ratios for the rest.
• Sizing to average IOPS. Use peak demand, latency percentiles, throughput and concurrency together.
• Calling snapshots “free”. Model changed data across the actual retention period.
• Counting the DR array only for capacity. It must carry the recovery workload and meet the stated RTO.
• Buying for day one. Include growth, migration headroom and an economically viable expansion path from the outset.

This overview of HPE Alletra MP covers the broader platform architecture. For sizing, the test is simpler: can you explain the design workload by workload, defend it after a failure, and still live with it when the estate is larger than it is today?