PowerMax Architecture and Components
The architecture domain checks whether you can connect physical redundancy to logical provisioning: which component survives a failure, which pool backs a device, and which object a host actually consumes.
Physical layer
- A PowerMax array is a scale-out cluster of nodes (directors). Each node carries front-end ports, back-end connectivity, CPU and global memory, and nodes are paired so that losing one leaves its partner serving I/O.
- PowerMax 2500/8500 systems running PowerMaxOS 10 are packaged as bricks: two nodes plus a 25-slot NVMe SSD enclosure. Performance and capacity scale out by adding bricks.
- Earlier PowerMax 2000/8000 systems use separate system bays whose engines hold two directors each, connected to flash drive enclosures.
- Front-end protocols include Fibre Channel (SCSI and FC-NVMe), iSCSI and NVMe/TCP; on PowerMaxOS 10 the back end is NVMe end to end.
- Management modules, power, fans and internal fabric are redundant, so "single point of failure" answers are almost always wrong.
Logical layer
- Physical drives are organized into Storage Resource Pools (SRPs). FBA SRPs carry a service level (Diamond, Platinum, Gold, Silver, Bronze, Optimized) that defines the workload profile the array applies when optimizing that pool.
- Thin devices (TDevs) are what hosts ultimately consume. They are created in an SRP, allocate capacity only as data is written, and are never presented directly: a device must sit in a storage group inside a masking view.
- A device belongs to exactly one storage group at a time (parent/child nesting aside).
- Storage groups aggregate devices; initiator groups and port groups describe the host and fabric sides of the presentation.
Worked example
An architect adds two 10 TB thin devices to an SRP with 40 TB usable and 30 TB already subscribed. At creation the SRP's used capacity does not move, but subscribed capacity rises by 20 TB to 50 TB against 40 TB usable, i.e. 125% subscription. That is legal, because thin devices are oversubscribed by design. So the correct analysis is capacity risk over time (monitor growth and set SRP alerts), not an immediate allocation failure. Reporting this as "used" capacity is where candidates lose marks.
Traps
- Mixing subscribed, used and usable capacity.
- Claiming a service level is set per device, when it is inherited from the SRP.
- Assuming a node or port failure takes the array down.
- Forgetting that a masking view, not a device, is what makes storage visible.