3PAR, Primera and Alletra Hardware: Identification and Replacement Notes

These archived training notes cover identification, topology and selected maintenance checks for HPE 3PAR StoreServ, Primera, Alletra 9000 and, in separate examples, Alletra Storage MP B10000. The source mixes several generations and software releases. Identify the exact model, OS, enclosure and failed component before selecting a service procedure; the notes are not a replacement for the matching component guide and support-case instructions.

Readable English figures are retained. Chinese annotations are translated with imagegen, and credential-related or ambiguous views are replaced by explanatory English illustrations. Shared summary figures replace equivalent source positions where noted. Physical drawings are learning aids, not a substitute for the actual labels and part locator. No storage commands, failure tests, firmware changes or physical replacements were performed while preparing this edition.

1. Identify the product family and software release

The source introduces 3PAR 7000/8000/9000/20000 examples, Primera 630/650/670, Alletra 9060/9080 and MP B10000. Their OS histories are context, not an upgrade path or a statement that every listed release supports every model. Likewise, a maximum controller count illustrated for a high-end model does not apply to the entire family.

Combined English historical family overview, replacing the first 3PAR roadmap. Example release families are not a compatibility matrix.

Use showversion to record the release, maintenance update and patch information separately. The original English example shows 3.2.2 (MU6) and component-specific patch levels. Do not infer the current firmware of every drive or IOM from the array release string alone.

Original English showversion example reused without the Chinese release/patch annotations; this historical output is not a new verification.

Same combined family overview at the second annotated 3PAR roadmap position; model-specific controller limits must be checked separately.

Review shownode for state, master role and cluster membership, and shownet for the management network and active interface. The source node output is Degraded. A reachable management address does not establish that controllers, data paths or volumes are healthy.

Fresh English node/network command explanation, with the original degraded-state limitation retained and no fabricated output.

2. Read CLI help and physical identifiers

The command help is useful for understanding actions and nouns: show inspects resources, create adds resources, remove removes resources, and vv denotes a virtual volume. Read the version-matched help before selecting an action. In the source, removevv -h is a help request; this is not an instruction to remove a volume.

Original English CLI help listing command categories. Listed service or removal commands are not steps to execute automatically.

Original English help show listing, including showalert and other inspection commands.

Fresh English command-naming and help illustration; the prompt symbols are illustrative, and removevv is shown only with its help option.

Use clihelp -col showvv to interpret virtual-volume columns. The source text misspells clihelp; the original English screenshot establishes the correct command. Its legacy provisioning names, including full, tpvv, tdvv and cpvv, describe that release and must not be assumed to exist in every later family. clihelp -search cage searches related help topics.

Original English clihelp -col showvv excerpt explaining legacy provisioning values.

Fresh English CLI help-search explanation; it does not fabricate the complete search results.

Use showsys to identify the actual model and system serial for the service case, and keep the version output with it. Recording a serial number does not itself verify warranty or entitlement.

Fresh English system/version identification instructions with no invented serial number, uptime, model output or date.

Original English showversion output retained at its second source position.

Combined English family overview at the Primera introduction position. Match the actual A/C model and drive support rather than relying on the original generalized all-flash annotation.

Combined English family overview at the Alletra 9000 introduction position; the source illustrates 9060 and 9080.

Combined English family overview at the MP B10000 introduction position. Its detailed node/enclosure limits depend on the configuration and release.

Repeated English node/network explanation at the source master-node discussion; a master role is not a single data-path ownership rule.

Keep identifiers distinct. In the legacy example, drive CagePos is cage:magazine:disk, whereas a port is node:slot:port. Later MP examples use a drive position such as 41:1 and a separate node Encl:Bay field such as 1:1. Read the actual column headers and physical labels; do not equate a PD ID with a slot, assume every model numbers bays from one, or transplant an old three-part format into another model.

Fresh English identifier comparison replacing the annotated legacy showpd output. All numbers are source examples, not service targets.

3. Controller hardware, orientation and indicators

The source shows several different controller boards and replacement assemblies. Memory, boot drives, time-of-day batteries and optional adapters can have different service boundaries. Verify the spare-kit contents and exact replacement procedure; the source’s conflicting blanket statements about whether a controller includes memory or boot drives are not carried forward as universal rules.

Localized original board example, preserving its two-CPU layout and numbered component groups. Callout 8 is corrected to TOD battery.

Localized 3PAR 8000 orientation example with alternating controller orientation and source node labels. Verify labels on the actual enclosure.

Interpret the LED function and pattern together. In the checked 3PAR 8000 guidance, a flashing blue UID/Service indication is a locate state and does not authorize removal. The halted/removal state has additional conditions and must be verified through the complete procedure. A generic green light is not enough to determine node health. The 8000 controller-node procedure describes preparation, shutdown and verification for its stated model scope; it is not a procedure for every controller shown here.

Fresh English 3PAR 8000 LED explanation distinguishing flashing-blue locate from the documented halted state and further removal checks.

For the illustrated four-node 7000/8000 layout, node pairs are 0/1 and 2/3. Label cables and confirm cable-end orientation before service; disturb only the target connections required by the approved procedure. Do not infer rack order from the drawing alone.

Localized original four-node interconnect example. The four End A/End B mappings are retained; this diagram is scoped to its source layout.

Same English identifier comparison at the source node:slot:port explanation position, replacing the annotated port-address schematic.

MGMT identifies the management connection in the source; RC-1 has the model-supported Remote Copy or related role. Check the relevant adapter/port LED table. The source suggests disconnecting a cable to change the active management node; do not treat that as a routine test. The verified setnet reference uses setnet changenode [<node_ID>] and notes that connected management clients can lose their connection. This is a configuration change, not a read-only check.

Fresh English management/RC port explanation replacing the original Ethernet LED/failover slide.

Fresh English setnet changenode syntax explanation replacing a credential-related source help view; no real command was run.

Fresh English interconnect LED explanation. Model-specific link indications are separate from component removal readiness.

Localized original controller-cover/component drawing. The unverified 3.3 V coin-battery annotation is omitted; select the actual specified service part.

Check supported HBA type, paired-node configuration, transceiver and peer settings before service. The source’s 7000/8000 lists are historical option examples, not current compatibility lists. Follow the controller shutdown and adapter handling instructions for the actual part. A nominal 10/25 Gb rate does not establish transceiver or switch compatibility by itself.

Localized original HBA/SFP drawings and historical English option lists, with model-specific compatibility and service conditions stated.

Localized original Primera 630 board example, retaining its board layout and component callouts; it does not establish another model’s DIMM placement or spare-kit contents.

Localized original 10/25 GbE four-port adapter outline. The detailed rate/color table is replaced by explanatory LED roles; an invented compatibility subtitle was removed.

4. Enclosure paths, RAID layout and node pairs

High availability combines data protection, cache protection, controller takeover and independent physical paths. A mirrored-cache or battery-backed design must be understood for the actual product; neither redundancy alone nor a RAID name proves that all failure combinations are safe.

The source contrasts a forward chain and opposite traversal paths through enclosures. A downstream path can depend on upstream components. Assess both paths and the supported cabling arrangement before concluding which drives remain accessible; the diagrams are concepts, not wiring plans or instructions to disconnect a live enclosure.

Fresh English forward-chain concept replacing the annotated source rack view. One marked path dependency is illustrative; evaluate both actual paths.

Fresh English legacy RAID 5 (3+1) placement concept across four enclosures. This example must not be applied as a Primera/Alletra RAID support rule.

Fresh English opposite-traversal concept retaining source enclosure order E2/E3/E4 versus E4/E3/E2, without claiming a guaranteed surviving RAID state.

The source asks whether RAID 6 (6+2) can preserve access with members spread across four cages instead of eight. Losing two members is a parity-count example, not by itself a validated HA Cage configuration. Supported layout rules, node-pair attachments, cabling and additional inaccessible members determine the result. Do not use either enclosure count as a universal requirement or guarantee. The Primera architecture guide describes node pairs and supported HA Cage placement.

Legacy 3PAR storage layers use physical-disk chunklets, logical disks (LDs), virtual volumes and host-exported LUNs. The learning figure uses 1 GiB chunklets, 32/128 MiB regions and 16 KiB pages, scoped to the illustrated architecture. Chunklets are allocation units, not separate physical disks. A CPG controls applicable layout/policy, while LD ownership and partner takeover relationships matter during service.

Previously reviewed English storage-layer illustration reused for the equivalent annotated source slide, with legacy allocation units explicitly scoped.

Fresh English LD/node-pair dependency concept; a virtual volume can use multiple LDs, and there is no one-LD-per-node mapping.

Same English dependency concept at the source pair-failure discussion. Surviving controller count alone does not establish volume availability.

The source gives failure-count examples for four- and eight-controller systems. Their intended lesson is to consider which node pair and data paths are affected. They are not a promise that any two or four failed nodes are tolerated, and no blanket conclusion that every pair fault crashes every system is retained.

Provisioning, reduction and RAID capabilities must be checked by family and release. The source’s 3PAR thin-volume screenshot is not proof of later-family support. The checked Primera 600 and Alletra 9000 drive guidelines specify RAID 6 in their respective scopes. This does not establish a universal rule for all HPE products, all volume types, reduction behavior or optional features.

Fresh English provisioning/reduction explanation. It replaces the source thin-volume screenshot and its generalized performance/feature claims.

5. Separate MP B10000 architecture and service scope

The MP example introduces a disaggregated NVMe design with controllers and enclosures connected through supported redundant fabrics. Its purpose is to explain different connectivity, not to claim the array remains operational with any arbitrary number or combination of failed controllers. Direct-attached and switched configurations, scaling limits and component requirements remain version-specific.

Fresh English redundant-fabric concept. Lines express connectivity only, not a physical cable count, port map or a single-surviving-controller guarantee.

The source contrasts traditional write-back cache with MP B10000 write-through behavior. The MP architecture white paper describes this design; HPE’s volume-staging-area terminology explains that a host write is acknowledged when it is written to the staging area. Do not simplify this to “no cache” or assume every final RAID stripe must already be destaged before acknowledgement.

Fresh English JBOF component summary. The source’s 2U/24-drive illustration is historical; no invented chassis or port locations are shown.

Same English identifier comparison at the MP drive example: 41:1 identifies source cage 41, slot 1, not a legacy three-part CagePos.

Same English identifier comparison at the MP node example: Encl:Bay is a distinct field. It is not a system-wide rule that bay 0 never exists.

Original English showcage -iom output showing Locate, FailInd, SafeToRemove and State separately. Locate No is not the same field as SafeToRemove No.

The source discusses CDM-assisted discovery, setup and recovery. Use the matching service workflow for activation, component updates or rescue, and verify the actual management-network design. The MP QuickSpecs documents an optional Bluetooth kit; Bluetooth is not a universal prerequisite. The source’s abbreviated PXE/rescue discussion is not a complete recovery procedure.

Fresh English CDM role summary replacing a complex annotated block diagram. Recovery actions remain version-specific.

Fresh English management-network concept replacing the annotated internal/external connection slide; the CDM is not drawn as a storage data-path switch.

LLDP can expose neighbor identity, port and VLAN information. The original English output is an example of discovery information, not proof that a switch API call configured a VLAN or that a storage expansion completed. Apply the supported network automation and switch configuration procedure for the actual system.

Original English LLDP neighbor example. Neighbor and VLAN observations do not prove a configuration change or storage readiness.

For shutdown and startup, use the exact platform procedure. The source lists stopping workloads, a storage halt, and a startup order involving switches, enclosures, controllers and hosts. That outline is incomplete for some configurations and is not a universal runbook. Confirm dependencies, quiesce the actual workload, and verify each required component before restarting applications; do not copy a cross-family shutdown command without the matching instructions.

6. Understand distributed spare space

The legacy/Alletra example distinguishes normal and spare chunklets through showpd -c. Read the multi-level Used/Unused and OK/Fail/Free headings together, using the CLI column definitions for the actual release. “Spare” is an allocation category; it is not a separate dedicated hot-spare disk in every design. A free normal chunklet and a free spare chunklet are different states.

Original English showpd -c table reused in place of its Chinese-annotated copy; normal and spare chunklet headings are preserved.

Original English showpd -c table at the second source position. The historical table contains failed/unused counts and is not asserted to be entirely healthy.

The source mentions removing spare allocation with removespare a:a and rebalancing it with admithw spares. These change the system and are not routine remedies for a full pool. The Primera 4.4 removespare reference defines a:a as removal of unused spare chunklets. Use only an approved capacity/service plan and verify spare state afterward. The source’s assertion that reconstruction always succeeds without spare allocation, or always falls back to a faster media type, is not a cross-family guarantee; free capacity, locality, media compatibility and RAID constraints still matter.

Original English historical admithw spares acknowledgement and follow-up table. It is an example result, not a command executed for this documentation task.

7. Use the correct management and service interface

Use the specified service cable and authorized account for the actual platform. The source illustrates a serial adapter and lists 57600 baud for its 3PAR/Primera/Alletra 9000 examples versus 115200 for its MP example. Verify the model’s service-port requirements before connecting. Do not use default-password examples, privileged account assumptions or a pictured saved login as access instructions.

Original serial-adapter photograph localized to English, with cable geometry retained. It does not establish universal cable compatibility.

Fresh English serial-setting reference replacing the credential-related original view; rates are explicitly source examples.

3PAR Service Processor/Service Console functions include service and support tasks beyond simply collecting logs; SSMC is a separate management interface. Primera and Alletra families have their own supported onboard and cloud/CLI workflows. The HPE management-tool guidance distinguishes Primera/3PAR tools from Alletra management. Do not assume that installing a VSP creates an onboard array UI or that SSMC supports every Alletra product.

Fresh English management-interface overview replacing the original credential-related UI view; no login values are reproduced.

Where supported, begin the actual hardware repair through the system’s guided Service action, select the exact target and follow the preparation and post-replacement steps. The Primera UI hardware guidance explains that some actions require node shutdown and host path checks. The migrated-enclosure drive procedure explicitly begins and ends with the UI; do not replace it with a generic “pull and insert” instruction.

Original English Service System Repair/Upgrade selection example. The model-specific guided workflow determines the next steps.

8. Locate the intended target

The source gives locatesys -t 90 for system identification and locatecage -t 30 cage2 iom 1 for its cage2/IOM1 example. Review the actual identifiers before use. A locate indication identifies a component and is separate from shutdown, offlining and safe-to-remove checks; LED colors vary by component and model.

Fresh English locatesys duration example without a fabricated hardware/LED picture.

Fresh English IOM locate example, preserving the separate iom and 1 arguments.

Original English locatecage help examples for cage, power/cooling module, IOM and drive targets. Select the actual supported target.

Original English locatenode help example, including a node power-supply target; the accepted range shown belongs to that reference, not every system.

9. Drive replacement: establish readiness and verify completion

Confirm the failed PD and its physical enclosure/slot with the case owner and the matching guided procedure. The source proposes failed-state/used-count, chunklet-query and servicemag-status checks. These are related evidence, not independent shortcuts that each automatically authorize removal. Verify relocation and all applicable conditions for the actual service target before removing a drive.

Original English historical failed-drive example: PD 95 at CagePos 4:6:0. Check both Normal and Spare Used columns, not a single zero.

The source prose refers to showpdch 95, while the pictured command is showpdch 50. Keep that discrepancy explicit. “No chunklet information available” in one query is not proof that another disk is empty or safe to remove. The Alletra 9000 showpdch reference documents default filtering to LD-mapped chunklets and deprecation of older positional usage; use the actual release’s documented query and service checks.

Fresh English interpretation of the original PD 50 query, explicitly distinguishing the PD 95 prose and retaining the actual source message.

Read servicemag status for the intended cage/magazine. In the source, a start operation has Succeeded after bringing cage 4, magazine 6 offline. That is a preparation-stage result, not a completed replacement or completed resume. Automatic behavior varies with the failure and release; do not assume every failure produces the same completed service operation.

Original English servicemag start result for cage 4, magazine 6: offline preparation succeeded. No newly completed replacement is inferred.

After physical replacement, follow the guided admission/resume and validation steps. The source’s later c630 example shows resume operations for cage 0 slots 6 and 7 still In Progress and no usable relocation estimate. It is a separate example, not continuation of the PD 95/cage 4 sequence. Monitor the actual target to its required final state; the picture does not authorize replacing multiple adjacent drives together.

Fresh English reconstruction of the two source In Progress states, with no invented ETA or successful completion.

If a replacement has a new/unadmitted state, verify slot, identity, supported spare and firmware before the case-specific admission action. That state alone does not establish a firmware mismatch or justify a downgrade. The source mentions admitpd and a manual resume example; use the actual target and approved procedure rather than copying its WWN or servicemag resume 4 6 as a universal fix. The related servicemag reference explains that operations can continue in the background and that removing a drive before relocation is complete can lose data.

Fresh English unadmitted-drive checks replacing the source’s generalized downgrade/admit example. No actual WWN or fabricated admission result is retained.

10. IOM, controller, SFP and enclosure service

After IOM replacement, check the enclosure state and firmware through the matching procedure. The source showcage -d cage0 example has Overall State Degraded, with one firmware status Unknown and another Current. It does not prove that a single universal command resolves the problem. showcage inspects enclosure information; upgradecage is a firmware-changing command and must be used only under the supported release and case instructions. The source’s pre-3.2.2 MU6 caveat is historical and is not proof that every newer release is automatically safe.

Original English degraded-cage/firmware example, preserving Unknown versus Current and the differing product revisions; it is not a healthy final result.

Controller, SFP, adapter, cable and whole-enclosure replacement have different preparation, shutdown and verification requirements. Use the exact component guide and service scope. The original controller section delegates to a separate guide and its enclosure section only mentions online/offline approaches; those abbreviated notes do not supply complete procedures. SFP replacement still requires the correct target, compatible optic, handling and link verification.

Close the actual service task only after the specified physical identity, status, firmware, paths and post-repair health checks pass. The screenshots in this article are archived teaching examples and do not constitute those checks for another array.

English references and source scope

No identical public English version of the protected mixed-family training article was established. Corresponding manufacturer English guides and original English figures were prioritized. Related CLI references are explicitly version-scoped; model-specific maintenance guides take precedence over the original generalized training comments.