Dell PowerStore Operate 2023 cheat sheet

PowerStore runs a container-based microservices architecture on two active-active nodes (appliance); both nodes serve I/O simultaneously, and losing one node fails over workloads to the survivor.

PowerStore 500T/1000T/1200T/3000T/3200T/5000T/5200T/9000T/9200T models differ by CPU, memory, and drive-slot count; the T suffix denotes the base enclosure, and expansion enclosures (ENS24) add 24 NVMe slots each.

The base enclosure holds 25 NVMe drive slots; the first four slots are reserved for NVRAM and boot/OS M.2 modules, so usable data drive slots in the base enclosure are 21.

Internal architecture: nodes connect through a midplane; NVMe drives are dual-ported and shared by both nodes, so a node failure does not lose drive access.

PowerStore uses end-to-end NVMe (NVMe drives, NVMe over Fabrics front end) with no SAS or SATA backend; NVRAM in each node provides write caching and power-loss protection.

PowerStore X models run a VMware ESXi-based controller with embedded vSphere; PowerStore T models are the block-and-file unified (native) deployment.

Front-end ports per node typically include 4x 25 GbE (SFP28) for iSCSI/NVMe-TCP, 2x 32 Gb FC (SFP+), plus 1 GbE management and service ports; exact port count varies by model.

Drive types are NVMe TLC (read/write intensive), NVMe QLC (capacity-optimized), and NVMe SCM (storage-class memory, lowest latency); mixing rules apply per model.

A cluster is composed of 1 to 4 appliances; a multi-appliance cluster requires PowerStore Manager and provides scale-out capacity and performance.

Initial deployment is done with the PowerStore Initial Configuration Wizard (ICW) via a direct laptop connection to the service port or through the management network; the wizard discovers unconfigured appliances by service tag.

A management network (1 GbE) is required for PowerStore Manager access, and a separate storage network must be defined for front-end host connectivity; do not share the two.

Cluster creation: first appliance becomes the primary; additional appliances join an existing cluster and must run compatible PowerStoreOS versions.

iSCSI/NVMe-TCP front-end ports are grouped into link aggregation or bond ports; both nodes' ports must be cabled symmetrically to the same switches.

Fibre Channel zoning: each node's FC ports are zoned to the host HBAs; single-initiator, multiple-target zoning is the recommended practice, and both nodes' ports must be zoned for HA.

After the ICW, PowerStore Manager is reached at the appliance management IP over HTTPS; the default admin account is created during the wizard, and no factory default password is shipped.

NTP, DNS, and SMTP must be configured during or immediately after installation; an unsynchronized clock breaks replication, snapshot scheduling, and certificate validation.

Expansion enclosures are cabled to the base enclosure with dual SAS/NVMe paths; each node connects to each expansion enclosure so a single cable failure does not detach drives.

PowerStore Manager is the HTML5 GUI; the same tasks are available through REST API, CLI (pstcli), and PowerStore Manager.

Default roles: Administrator (full control), Storage Administrator (storage objects, no system settings), VM Administrator (for X models), and Read-Only.

Alerts are surfaced in the Dashboard and Alerts page; alert definitions can be enabled/disabled, and email notification requires configured SMTP.

The Dashboard shows capacity, performance, and health summaries; drill-down to a specific appliance, node, or object is done from the same view.

SupportAssist (or Secure Remote Services) sends telemetry and alerts to Dell support; it must be enabled and connected for remote support and automated case creation.

Event log and audit log are separate: event log records system events, audit log records user/API actions; both are exportable.

Firmware and software upgrades are initiated from the Settings > Upgrades page; the system performs a health check first and blocks the upgrade if checks fail.

User accounts can be local or LDAP/AD-integrated; directory services are configured under Settings > Directory Services with a bind account and user/group mapping.

A volume is a block LUN presented to a host; a volume group is a container of volumes that are managed and protected together (snapshots, replication, policy).

Thin provisioning is the default: capacity is allocated on write, and a volume's advertised size can exceed physical capacity; monitor subscription to avoid overcommit.

Host objects represent initiators (FC WWPN or iSCSI/NVMe IQN/NQN); a host must be created and mapped to a host group or volume before I/O is allowed.

Host group is a set of hosts that share access to the same volumes; use it for clusters where every node must see the same LUNs.

A volume can be mapped to multiple hosts/host groups; LUN ID assignment can be automatic or manual, and the same LUN ID must be consistent across a cluster's hosts.

Protection policies attach snapshot and replication rules to volumes and volume groups; a volume without a policy has no scheduled protection.

Volume creation options include thin/thick, size, protection policy, performance policy, and whether to enable compression/deduplication (applies at the storage-pool level).

File provisioning (SMB/NFS) requires a NAS server, file system, and SMB share or NFS export; NAS servers are created on PowerStore T models only.

Snapshots are point-in-time, space-efficient copies; they capture only changed blocks and are the basis for both local recovery and replication.

A protection policy defines a snapshot rule (interval and retention) and/or a replication rule (RPO, destination); policies are assigned to volumes, volume groups, and file systems.

Snapshot rules: schedule (every N minutes/hours, daily, weekly) plus retention count; the oldest snapshot is deleted when the retention limit is reached.

Replication is asynchronous by default; RPO is the maximum acceptable data loss window, and the replication rule sets the RPO/schedule.

Metro replication (synchronous) requires a low-latency link and provides zero RPO with active-active access from both sites; it is limited to supported distances and configurations.

Replication requires a remote system object (the peer cluster) configured with its management IP and credentials; the peer must be reachable and version-compatible.

Failover promotes the destination copy to read/write; failback re-synchronizes and returns production to the original site. Planned migration uses a controlled switchover.

Snapshot recovery restores a volume from a snapshot; refresh/clone creates a new writable volume from a snapshot without affecting the source.

FC: configure zones on the SAN switch (single-initiator, multiple-target), then register host initiators by WWPN in PowerStore; FC ports support 16/32 Gb depending on model and SFP.

iSCSI: front-end Ethernet ports are bonded (LACP) or configured as link aggregation; the host uses the target portal IP, and CHAP can be enabled for authentication.

NVMe over TCP: uses the same Ethernet front-end ports as iSCSI; the host connects with an NQN and a target portal, and the subsystem NQN identifies the PowerStore target.

NVMe over FC: supported on FC front-end ports with Gen 6 (32G) HBAs/switches; the host uses the target's NQN and WWPN-based discovery.

Multipath: each host should have at least two paths, one per node, using native MPIO (iSCSI/NVMe-TCP) or PowerPath/MPIO (FC) for failover and load balancing.

Jumbo frames (MTU 9000) must be configured end-to-end on the storage network (host, switch, and PowerStore ports) or performance degrades and connectivity may fail.

VLAN tagging on front-end ports isolates storage traffic; the host and switch must use matching VLAN IDs on the storage interfaces.

Interface/IP changes on front-end ports interrupt I/O; schedule them in a maintenance window and verify host multipath health before and after.

Capacity views: physical (raw), usable (after RAID and metadata overhead), and subscription (sum of provisioned volume sizes); overcommit ratio = subscription / usable.

Storage pool capacity is consumed by thin volumes on write, snapshots, and metadata; the system raises alerts at configurable thresholds (default warning ~70-80%).

Deduplication and compression are pool-level settings; enabling them on an existing pool triggers a background scan and does not shrink existing data immediately.

Performance metrics include IOPS, bandwidth (MB/s), latency (ms), and queue depth, viewable per appliance, node, volume, host, and port.

Latency is read as an average plus percentiles; a rising 99th-percentile latency with flat IOPS usually indicates a host or network bottleneck rather than array saturation.

Health checks: system checks (alerts, drive health, node status, replication state) are shown on the Dashboard; a degraded node or drive triggers a specific alert code.

Alerts have severities (critical, major, minor, info); each alert has a description, probable cause, and recommended action in PowerStore Manager.

Capacity forecasting and performance historical data are retained for a rolling window; export metrics before the window rolls off if long-term trending is needed.

PowerStoreOS upgrades are non-disruptive when the cluster is healthy: nodes upgrade one at a time, and I/O continues on the peer node.

Pre-upgrade health check verifies node status, drive health, replication state, and free capacity; resolve failures before retrying, because the upgrade aborts on failed checks.

Upgrade paths: only supported versions can be jumped directly; check the release notes for the minimum source version and required intermediate steps.

Drive replacement: identify the failed slot from the alert, pull the drive, insert the replacement, and the system rebuilds automatically; use only supported drive part numbers.

Node replacement uses the service procedures and requires the replacement node to be cabled and discovered; data is restored from the peer node and rebuild occurs automatically.

Collect support materials (logs, SPCollect-style bundle) from PowerStore Manager or CLI before escalation; this is required for Dell support case analysis.

Common connectivity troubleshooting: verify host initiator registration, zoning or VLAN/MTU, target portal reachability, and multipath path state before assuming an array fault.

Service ports and the service user account are for Dell support use; customer access to service-level commands is restricted and should not be used for routine administration.