Dell PowerMax Operate (DCA Operate) cheat sheet

PowerMax arrays are built from one or two engines; each engine contains two director boards (a pair), and each director exposes front-end (host) and back-end (DA) ports depending on its personality.

A brick is the building block: a 2U enclosure holding 25 NVMe SSDs plus two node pair controllers; engines scale by adding bricks, and capacity scales in brick increments.

Two-engine systems are configured as either a single-brick-per-engine or multi-brick-per-engine layout; the two engines form a redundant pair, and an array can tolerate loss of one engine while remaining available.

Virtual provisioning: thin devices (TDevs) are presented to hosts and draw from thin pools; thick/fully provisioned devices are allocated up front. A thin device has a defined size but consumes pool capacity only as written.

Thin pool oversubscription: subscribed capacity (sum of TDev sizes) divided by pool usable capacity; a ratio above roughly 2:1 to 3:1 warrants monitoring of pool free space and growth rate.

Data reduction on PowerMax includes inline compression and deduplication (on supported models); reduction is reported per pool and per storage group, and enabling it affects capacity accounting, not the presented device size.

PowerMaxOS runs on the array; Unisphere for PowerMax and Solutions Enabler (SYMCLI) are the management interfaces. Unisphere is the GUI/API layer; Solutions Enabler provides the CLI and host-based libraries.

Device identity: a PowerMax device is addressed by array serial (SID), device number, and WWN. Symmetrix-style device numbers (e.g., 0001, 00A1) are still the addressing convention in SYMCLI output.

Metro/remote replication requires SRDF directors or ports; SRDF groups are logical containers that pair devices between arrays (R1 source, R2 target).

Provisioning order in SYMCLI: create thin pool (or use existing) -> create TDev in pool -> add device to a storage group -> create masking view (storage group + port group + initiator group + optional SPP).

A storage group is a container of devices presented together; a masking view binds a storage group to a port group and an initiator group, which is what actually grants host access.

One device can belong to only one storage group at a time in a masking view context; adding a device to a second storage group can break the first masking view mapping.

Port group = set of front-end director ports; initiator group = set of host HBA WWNs (or iSCSI IQNs). A masking view references exactly one of each.

Child storage groups can be nested under a parent storage group; SRDF and some snapshot operations act on the parent and cascade to children.

Thin device creation: symconfigure -sid <SID> -cmd "create dev count=<n>, size=<n> [GB|CYL], emulation=FBA, config=TDEV, pool=<pool>;" commit -noprompt.

To add devices to a storage group: symaccess -sid <SID> -type storage -name <SG> add dev <dev>, then symaccess -sid <SID> -type storage -name <SG> -check to verify.

Deleting a masking view does not delete the devices; deleting a storage group removes the container. Always verify with symaccess list view and symsg show before removing.

Capacity efficiency: prefer thin devices in a shared pool over fully provisioned devices; monitor pool subscribed capacity and free capacity after each provisioning batch.

Host connectivity requires: front-end port in a port group, host HBA WWN (or IQN) in an initiator group, devices in a storage group, and a masking view tying them together.

symaccess -sid <SID> list view -name <MV> shows the masking view's storage group, port group, initiator group, and SPP.

symaccess -sid <SID> -type initiator -name <IG> add -wwn <WWN> adds a host HBA; symaccess -sid <SID> -type initiator -name <IG> remove -wwn <WWN> removes it.

symaccess -sid <SID> -type port -name <PG> add -dirport <dir:port> adds a front-end port to a port group.

A SPP (storage port to port) mapping is optional and used for specific host-to-port affinity; without SPP, any port in the port group can serve the host.

LUN presentation: the host sees a LUN number per device; symaccess -sid <SID> show view <MV> and symdev show <dev> display the LUN and WWN.

Verify host visibility: symmaskdb (legacy) or symaccess list view; on the host, rescan SCSI and check multipath -ll (Linux) or MPIO (Windows).

Removing a host: remove its WWN from the initiator group; if the IG becomes empty, delete the masking view before deleting the IG.

Zoning: FC zoning must include the host HBA and the front-end array port; a missing zone is the most common cause of a host not seeing a presented device.

Key array metrics: IOPS, MB/s (throughput), response time (ms), queue depth, and % busy per director and per device.

Response time is the primary SLO metric; rising response time at constant IOPS usually indicates queue buildup or backend contention.

symstat -sid <SID> -type <rdf|device|port|pool> -i <interval> -c <count> samples performance counters from SYMCLI; Unisphere Performance shows the same data graphically.

Unisphere for PowerMax Performance view: Dashboard, Performance (charts), and Performance Analyzer for historical trending and threshold alerts.

Diagnose front-end vs back-end: if front-end port % busy is high but backend is low, the bottleneck is host/port; if backend is high, it is disk/pool contention.

Thin pool performance: pool utilization above ~80% can increase response time; monitor pool subscribed capacity and free space.

SRDF impact: RDF traffic consumes front-end/RDF port bandwidth and adds write latency on the R1 side; monitor RDF port utilization and SRDF group lag.

Tuning levers: spread devices across pools, balance hosts across ports, adjust queue depth on the host HBA, and use SPP to pin hot hosts to specific ports.

Alerts: Unisphere threshold alerts on response time, IOPS, and capacity; Solutions Enabler symevent and stordaemon capture and forward events to syslog/SNMP.

PowerMax snapshots: TimeFinder SnapVX creates point-in-time copies (snapshots) of a source device into a target-less snapshot; a snapshot is linked to a target device only when needed.

SnapVX commands: symsnap -sid <SID> create -name <snap> -source <dev>, symsnap -sid <SID> list -name <snap>, symsnap -sid <SID> link -name <snap> -target <tdev>.

A snapVX snapshot has a generation; you can have multiple generations per source device, and each generation is addressable by name.

Restore: symsnap -sid <SID> restore -name <snap> -source <dev> reverts the source to the snapshot point in time.

Terminate: symsnap -sid <SID> terminate -name <snap> removes the snapshot; linked targets must be unlinked first.

Clone (TimeFinder Clone) creates a full copy of a device; it consumes full capacity and is independent of the source after creation.

SRDF/TimeFinder interaction: snapshots on the R2 side allow point-in-time copies at the remote site without impacting the R1 production array.

Snapshot capacity: snapVX consumes pool capacity for changed tracks (copy-on-write); monitor pool free space when many generations are retained.

Backup integration: PowerMax supports NDMP and third-party backup via snapshot mounts; a common pattern is to snap, link to a target, mount, back up, unlink, and terminate.

SRDF modes: Synchronous (SRDF/S) - write acknowledged after R2 commit; Asynchronous (SRDF/A) - write acknowledged at R1, R2 catches up in cycles; SRDF/Metro - active/active, both sites serve I/O.

SRDF group: a logical container pairing R1 devices on the source with R2 devices on the target; created with symrdf -sid <SID> createpair -type <S|A|M> -rdfg <g> -file <file>.

R1 = source device, R2 = target device. symrdf -sid <SID> -rdfg <g> list shows pair state, mode, and lag.

Pair states: Synchronized, Consistent, Suspended, Partitioned, Invalid, and Transitioning. A Partitioned pair means the SRDF link is down.

symrdf -sid <SID> -rdfg <g> suspend, resume, failover, failback, and swap control pair lifecycle.

SRDF/A uses delta sets and cycles; monitor cycle time and lag to confirm the R2 is keeping up. Long cycles indicate link or R2 performance issues.

SRDF/Metro requires both arrays to present the same device to the host (biased or unbiased); hosts use multipathing across both sites.

symrdf -sid <SID> -rdfg <g> -type <S|A> verify and symrdf -sid <SID> -rdfg <g> query confirm link and pair health.

Planning: RDF port bandwidth, RTT (round-trip time), and write rate determine whether SRDF/S is viable; high RTT favors SRDF/A.

Unisphere for PowerMax Health & Alerts shows array health, component status (directors, bricks, ports, power), and active alerts.

symcfg -sid <SID> list -v and symcfg -sid <SID> show report array configuration and status; symcfg -sid <SID> list -dir all lists directors.

symdisk -sid <SID> list shows disk status; symdisk -sid <SID> show -disk <n> shows detail including errors and sparing.

Event daemon: stordaemon start storevntd and stordaemon action storevntd -cmd show -type event display events; symevent monitors in real time.

Alert forwarding: configure SNMP traps or syslog in Unisphere or via symcfg; Solutions Enabler can forward events to a syslog server.

Threshold alerts: Unisphere Performance -> Alerts lets you set thresholds on response time, IOPS, and capacity; alerts fire into the Alerts view and can trigger email/SNMP.

Call-home: PowerMax can send health and alert data to Dell support; verify connectivity and the call-home configuration in Unisphere Settings.

Common health checks: director status (Online), port status (Online), disk status (Healthy), pool free capacity, SRDF pair state, and snapshot pool consumption.

Troubleshooting order: check array health -> component status -> port status -> host zoning -> masking view -> host multipath.

Unisphere for PowerMax is the web UI; the REST API is exposed at /univmax/rest/v1/ and uses basic auth or session tokens.

Solutions Enabler (SYMCLI) is the CLI; symcli commands require a SYMAPI database and a configured symapi_db.bin on the management host.

Discovery: symcfg discover refreshes the local SYMAPI database with arrays visible to the host.

Common prefixes: symcfg (config), symdev (devices), symsg (storage groups), symaccess (masking views), symsnap (snapshots), symrdf (SRDF), symstat (performance), symdisk (disks).

symconfigure -sid <SID> -cmd "<command>;" commit -noprompt executes configuration changes; -noprompt skips confirmation.

symdev -sid <SID> list lists devices; symdev -sid <SID> show <dev> shows detail including WWN, pool, and storage group.

symsg -sid <SID> show <SG> shows storage group contents; symsg -sid <SID> list lists all storage groups.

REST API examples: GET /univmax/rest/v1/sloprovision/storagegroup/<SID> and GET /univmax/rest/v1/performance/... for metrics; use curl with an auth token.

Unisphere roles: admin, storage admin, monitor, and auditor; assign least privilege and audit API/CLI access.

Capacity units: PowerMax reports in GB (decimal) and GiB (binary); confirm which unit a report uses before comparing to host-side numbers.

Physical capacity = sum of usable SSD capacity in the array; usable capacity is less than raw due to RAID and sparing overhead.

Thin pool metrics: usable capacity, subscribed capacity (sum of TDev sizes), free capacity, and % subscribed = subscribed / usable.

Device capacity: a TDev's configured size is what the host sees; its allocated capacity is what it actually consumes in the pool.

symcfg -sid <SID> list -pool -thin lists thin pools with capacity and subscription; symcfg -sid <SID> show -pool <pool> -thin -detail shows detail.

symdev -sid <SID> list -pool <pool> lists devices in a pool; symdev -sid <SID> show <dev> shows allocated vs configured capacity.

Unisphere Capacity view: Storage -> Capacity shows array, pool, and storage group capacity, plus trending over time.

Data reduction: compression and dedup reduce physical consumption; reported reduction ratio = logical / physical. Verify before assuming headroom.

Reporting: export capacity and performance data via Unisphere reports or REST API for chargeback and trending; schedule reports for recurring review.