HPE Storage Fundamentals

This English edition explains the concepts in the archived HPE storage-training notes. Its English diagrams are instructional reconstructions, except for the credited original manufacturer SSD illustrations. Product families and software releases differ; the simplified examples are not configuration specifications or measured performance results.

1. Follow the I/O path

An application accesses files through an operating-system file system and its I/O stack, which ultimately issues requests to block devices. A lower-layer block-device failure can make a file system unavailable or damage data. A file-system error alone does not establish that the storage array caused it; investigate software, host, path and storage evidence together.

English conceptual block-I/O path: user process, file system/cache, block queue, driver and storage devices. OS implementation details vary.

2. Block storage, file storage and shared access

Storage is more than a collection of disks: controllers, protection, connectivity and management determine how applications use it. It is not necessarily faster than server-local storage. Availability objectives such as five nines depend on a complete supported design and operations; installing an array alone does not guarantee them.

DAS and SAN expose block devices; a host normally supplies the file system. Fibre Channel SANs use FC adapters and switches. IP SANs such as iSCSI use Ethernet and TCP/IP. NAS exposes files through protocols such as SMB/CIFS or NFS. Object storage exposes objects through an object API; it is a separate access model, not simply another name for NAS. Cloud file-sharing services may provide several interfaces and are not an interchangeable protocol definition.

English FC SAN topology. Source-era 8/16/32 Gbit/s examples are not an exhaustive rate list or a performance guarantee.

English iSCSI topology. Source-era 1/10/25 Gbit/s examples depend on the supported adapters, switches and array ports.

The source illustrates writing a PowerPoint file on Windows Server 2019. An application may complete a buffered write while data is still in host memory. Durable completion depends on the application and OS flush contract and the storage system’s acknowledged-write protection. Arrays may mirror or otherwise protect cache and use batteries, capacitors or persistent memory to survive power loss; their designs and degraded-mode policies differ. Ordinary unprotected host RAM is volatile. A protected-cache acknowledgement can precede final disk destaging, so disk destaging is not the sole definition of durable completion.

English cache-protection illustration: application completion, host RAM, protected controller cache and media destaging are distinct stages.

The notes compare one failed standalone computer with several clustered hosts that retain access to shared storage. Shared connectivity alone is insufficient: the application, cluster-aware file system or supported volume manager must coordinate concurrent access, with appropriate fencing. Do not mount an ordinary single-host file system writable on multiple hosts merely because they can see the same LUN. The source’s below-1-ms latency note is a design objective for a particular workload, not a universal iSCSI requirement.

English shared-storage cluster illustration: redundant connectivity plus coordinated host software, not automatic multi-host consistency.

3. Controllers and multipathing

ALUA means Asymmetric Logical Unit Access. Active/Optimized (AO) paths and Active/Non-Optimized (ANO) paths can both carry I/O, with the supported host policy preferring the optimized group. Ownership, forwarding, failover and priority values are array- and host-specific. ALUA describes path access and is not itself a universal controller architecture. The source’s MSA example has two priority-50 AO paths and two priority-10 ANO paths; do not extend that exact layout to all models mentioned in the training slides.

English ALUA example: two AO/priority-50 paths and two ANO/priority-10 paths to one LUN; no fabricated raw command output.

The historical Nimble example shows an active controller serving host I/O and a standby controller, with two ready paths and two ghost/standby paths. The standby controller still participates in redundancy and takeover; it is inaccurate to say it does no work. Firmware capabilities, protocol and host configuration can change how paths are presented. Compare the actual system with its supported host guide.

English active/standby reconstruction: the source-era example has priority-50 ready paths and priority-1 ghost/standby paths.

Several paths to the same LUN may appear as several path devices before a multipath layer groups them. A stable LUN identifier, typically a WWID, associates the paths with one logical device. The four paths in the source are access routes, not four independent copies. Different volumes need distinct identities.

English reconstruction: four routes to one logical device, grouped using a common stable LUN identity.

On an applicable Linux host, multipath -ll displays map identity, path groups, priorities and path states. The source uses the alias mpathk, a 12G example map and alua, with priority 50 versus 1 in its Nimble output. Exact WWIDs, device names and addresses identify the local system and are omitted from the conceptual English map. A ready path does not establish file-system or data integrity; review all relevant layers.

English explanatory multipath map: alias, shared identity, two ready paths and two ghost/standby paths. This is a schematic, not terminal output.

4. Snapshots and first-write preservation

A point-in-time snapshot records a view of volume data. Metadata locates the blocks; it is distinct from the data itself. A space-efficient snapshot can initially share unchanged blocks with the active volume. The drawings below show logical data relationships, not measured physical capacity or a full copy at creation.

English initial block-mapping diagram: active metadata references A, B, C and D before snapshot creation.

English initial snapshot diagram: source and snapshot reference existing shared blocks; circle sizes do not measure physical allocation.

In the source’s simplified copy-on-first-write example, a 14:00 snapshot retains value A. At 14:30, before changing the protected block to B, the implementation preserves A for the snapshot. At 15:00, changing B to C does not need to preserve B for that same 14:00 snapshot, which still needs A. Other snapshots, volume types and snapshot implementations can require different work. The conceptual first overwrite has one read of old data and two writes: preserved old data and new live data.

English logical-content timeline: the current block progresses A to B to C while the 14:00 snapshot retains A. It does not depict a full physical copy at creation.

A snapshot can help recover from an accidental file deletion or formatting action when the relevant snapshot data and metadata remain intact. It can still depend on the same underlying storage as the live volume. A RAID, shared-block or array failure may make both unavailable. Logical source-volume deletion is not automatically identical to destroying shared physical blocks: product dependency and deletion rules vary. A local snapshot alone is not an independent retained backup.

English failure-domain diagram: underlying shared-storage damage can affect both views; logical file deletion is a different event.

Copy-on-write (COW) preserves old data before an overwrite; redirect-on-write (ROW) writes new data elsewhere and adjusts mappings while preserving the old view. Both involve implementation-dependent allocation and metadata work. Do not treat the source table’s yes/no performance entries or product-family labels as universal. HPE documents delayed COW and ROW variants for 3PAR/Primera, with selection depending on volume type and data-reduction configuration; a product is not necessarily limited to one method. Read and write overhead must be assessed for the actual implementation and workload.

English conceptual COW/ROW comparison replacing the source’s overly broad product and performance table.

5. Full clones and writable snapshots

The source describes creating a full physical clone from a point-in-time view: establish a consistent point, copy the required data to separately allocated blocks and verify completion. Once a full copy is complete and independent of source-data blocks, a later source-data change need not affect it. Allocation may be thick or thin depending on the product; do not assume every full clone immediately consumes exactly the source’s logical size. Copy work can affect performance. A full clone on the same array still shares that array’s failure domain. Snapshot cleanup is a separate product-specific action after dependency and completion checks.

English full-clone workflow: point-in-time capture, required data copy and completion verification. It is not a command to delete the source or snapshot.

A writable snapshot, sometimes called a virtual clone in the notes, shares unchanged blocks and allocates diverging changes. It provides a separate logical view quickly, without implying an independent physical backup. Source/clone dependency rules vary. Merely overwriting all user data is not proof that all shared dependencies or the array failure domain have disappeared.

English writable-snapshot illustration: shared unchanged data with diverging writes and product-specific lifecycle rules.

English comparison of shared-block virtual copies and completed full copies. Even disjoint data-block sets may reside in the same array.

6. Disaster recovery, RPO and RTO

The training notes contrast restoring a backup from tape with using another production system and remote replication. Restore duration depends on data volume, media, throughput and recovery work; tape does not imply one fixed recovery time. Disaster recovery also needs usable hosts, applications, networks, identities and tested procedures. Local clones protect against selected events within one storage system; a separate remote array/site can address other failure domains. Replication can propagate unwanted changes and does not replace retained recoverable backups.

English comparison: backup/restore, same-array copies and remote replication address different recovery needs.

RPO (Recovery Point Objective) sets the acceptable recovery point or data-loss window. RTO (Recovery Time Objective) sets the target maximum time to restore the service. Neither is a guaranteed observed result. With only daily midnight recovery copies, newly written data may be exposed for up to roughly 24 hours, depending on the failure time and available recoverable copies. A 12-hour RTO is a target to meet, not the minimum time recovery must take.

English RPO/RTO definitions and the source’s daily-midnight / 12-hour examples, with objective versus actual result distinguished.

7. Synchronous and asynchronous replication

In the simplified synchronous sequence, the host writes to array 1, array 1 replicates to array 2, array 2 acknowledges the required remote protection, and array 1 acknowledges the host. Remote round-trip and protection work therefore contribute to foreground write latency. A link or array failure triggers the product’s supported policy, which may involve degraded operation or suspension. Automatic failover is an additional supported design with orchestration, quorum/witness and fencing; synchronous replication alone does not make every failure an automatic safe takeover.

English synchronous-write sequence: 1 host write, 2 replication, 3 remote acknowledgement, 4 host acknowledgement after required protection.

With asynchronous replication, the source can acknowledge protected local writes before the remote copy catches up. The source’s five-minute cycle is an example, not a universal interval or a guaranteed maximum RPO: transfer duration, backlog and faults affect lag. Acknowledged writes not yet replicated can be lost if the source fails. Replication still consumes resources; it is inaccurate to promise no performance impact merely because the remote acknowledgement is outside the foreground path.

English asynchronous sequence: local acknowledgement precedes later replication. The five-minute example is not a universal guarantee.

Repeated English active/standby illustration at the source’s controller recap; it retains the distinction between serving I/O and supporting redundancy.

8. Thin provisioning and capacity

Traditional thick allocation reserves or allocates capacity in advance, even if the application has not used all of it. Thin provisioning assigns backing capacity as data is written, subject to metadata, protection, snapshots, allocation granularity and product limits. It can improve utilization and defer expansion; it cannot create unlimited physical storage.

The source’s four 100-GB disks in RAID5 (3+1) give approximately 300 GB before overhead. Its 500-TB logical-volume example with only 1 TB of user data illustrates the difference between logical size and current use, not a guarantee of exactly 1 TB physical allocation. A 100-TB usable pool with 300 TB of promised logical capacity has a simplified 3:1 oversubscription ratio. Exhaustion can cause failed writes or other product-specific disruption. Monitor usable pool capacity, growth, snapshots and limits and expand before exhaustion. The source’s 75% budgeting trigger is a planning example, not a universal HPE alarm threshold.

English thick/thin introduction with the four-disk RAID5 capacity example and finite-capacity warning.

English logical-versus-physical examples: 300 TB logical / 100 TB usable pool and a lightly used 500-TB logical volume; overhead and limits remain applicable.

English conceptual allocation comparison: reserved-but-unused space versus unallocated pool capacity. Logical volume size is not extra physical free space.

9. RAID parity and write cost

RAID5 uses XOR parity. For the source’s seven data values, 1010 XOR 1100 XOR 0011 XOR 1001 XOR 0110 XOR 1101 XOR 0101 = 0010. The illustration represents one stripe; parity placement rotates across drives in RAID5.

English seven-data-plus-one-parity example, retaining the verified source bits and parity 0010.

For the illustrated small read-modify-write update, old data is 0110, old parity is 0010, and new data is 1111. New parity is 0010 XOR 0110 XOR 1111 = 1011. Read old data and parity, then write new data and parity: two reads plus two writes in this model. Full-stripe writes, cache and other implementations can change backend behavior.

English read-modify-write example: 0110 to 1111, parity 0010 to 1011; four backend operations in the simplified case.

Combining the source’s first-write COW model with the RAID5 model gives 1 + 2 × 4 = 9 backend I/O operations under its assumptions. This counts operations including reads. It is not a measured nine-times byte-write amplification, not a universal latency multiplier, and not the behavior of every HPE snapshot implementation. Alignment, cache, RAID stripe handling and snapshot design matter.

English toy COW-plus-RAID calculation with the distinction between backend operation count and measured write amplification.

Choose RAID for fault tolerance, capacity, workload and supported hardware. For equal-size drives of size S and N members, simplified usable capacities are N×S for RAID0, S for a two-drive RAID1 mirror, N×S/2 for RAID10, (N−1)×S for RAID5 and (N−2)×S for RAID6. These omit spares and metadata. RAID0 has no redundancy; controller minimums vary, and conventional multi-drive striping uses at least two drives. RAID10 requires at least four drives in this example and survives failures only while each required mirror remains readable. RAID5/6 tolerate one/two member-drive failures respectively under their stated assumptions. RAID is not backup.

English RAID comparison, with capacity assumptions, minimum-drive qualifications and mirror-group fault limits.

10. SSD garbage collection and endurance

NAND pages are programmed into erased space; erasing operates on larger blocks. Updates can be written to fresh pages while previous locations become stale. The manufacturer diagrams below match the English figures underlying the annotated training slides. Their 128-KB blocks, 32 pages and 4-KB page example are illustrative, not a geometry specification for every SSD.

Original English Cactus Technologies illustration: ten valid pages are updated at fresh locations and previous pages become dirty/stale. Source: SSD Primer #11, Updating Page Data.

To reclaim a block containing both valid and stale pages, the controller preserves its still-valid data elsewhere before erasing and reusing the block. This internal copying contributes to write amplification. The diagram shows 22 valid pages moved from block 1 to block 2; its before/after views are an explanatory sequence, not a measured device trace.

Original English Cactus Technologies garbage-collection illustration: preserve 22 valid pages in another block, then reclaim the original block.

The source’s extra endurance annotation incorrectly describes erasing each page and implies a fixed percentage of worn pages makes every drive fail. Endurance depends on NAND program/erase wear, the controller, workload and write amplification; use the drive’s documented TBW/DWPD ratings and health indicators. A rating or wear indicator is not an exact prediction of the instant every SSD will fail.

Same original manufacturer garbage-collection figure at the source’s endurance recap; the inaccurate added page-erasure / fixed-failure-percentage annotation is replaced by the English explanation.

11. Legacy 3PAR virtualization

The legacy training diagram abstracts physical drives into chunklets, combines them into RAID-protected logical disks, and allocates virtual volumes presented to hosts. The figure’s 1-GiB chunklets, 32/128-MiB regions and 16-KiB pages belong to its training context; details vary by product and OS. HPE’s English Primera architecture paper documents related layers but is not a claim that every generation uses an identical layout. The source’s quoted HDD/SSD IOPS ranges are workload-era examples, not current drive specifications or guaranteed per-volume performance.

English reconstruction of the legacy storage layers, replacing annotated slides rather than presenting a newer product figure as the same device.

Chunklets are allocation units, not independent physical drives. Do not turn the source’s 900-GB-drive example into exactly 900 one-GiB chunklets: decimal GB differs from binary GiB, and formatting, spare and system overhead also matter.

Same English layer diagram at the chunklet explanation. Product/version scope and GB-versus-GiB qualifications remain explicit.

The next legacy example has twelve drives organized into three four-member RAID5 (3+1) sets. With one 1-GiB chunklet per member, each set has 3 GiB data capacity before overhead. A 128-KiB step on each of three data members gives 3 × 128 = 384 KiB per RAID-set stripe; three such sets give 3 × 384 = 1152 KiB = 1.125 MiB. This corrects the source annotations’ 376/1128 arithmetic. It is a simplified mapping, not the supported configuration for every array.

English legacy mapping example: twelve drives, three RAID5 (3+1) sets, 128-KiB steps and corrected 384/1152-KiB data-stripe arithmetic.

Logical disks can supply allocations to several thin-provisioned virtual volumes such as tpvv1, tpvv2 and tpvv3. Wide striping spreads eligible allocation across drives according to the CPG, RAID and placement policy; it does not make every volume use every drive under every configuration. The source’s 512-MB/256-MB region drawing and 684-stripe annotation are not a precise universal size equation, so the English mapping remains conceptual. A failed or slow drive can affect shared workloads, with the actual impact determined by protection, failure scope and workload. Neither an inevitable stall of all volumes nor a fixed sum of drive IOPS follows from the diagram.

English conceptual chunklet-to-LD-to-TPVV mapping, with configuration-dependent performance and failure scope.

English references and source scope

A public English copy of the original annotated BookStack training article was not established. Manufacturer originals were recovered for the matching SSD diagrams; the other figures are English reconstructions. The related official documents above verify specific concepts and are not represented as the same course edition.