Dell PowerStore Operate cheat sheet

PowerStore runs on a scale-up/scale-out appliance model: a base enclosure (2U, 25 x 2.5" NVMe drives) plus optional 2U 24-drive NVMe expansion enclosures (ENS24); each appliance contains two active-active nodes that share the same drives.

Both nodes in an appliance are active-active and present the same volumes to hosts; a node failure triggers automatic failover of its resources to the peer node with no host-side reconfiguration, but performance is reduced until the node returns.

PowerStore models differ by node CPU/memory and IO capability: PowerStore 500T/1000T/1200T/3000T/3200T/5000T/5200T/9000T/9200T - 'T' denotes NVMe-based unified (block + file) appliances; model number scales CPU, memory, and maximum drive count.

The internal architecture uses NVMe drives connected to both nodes; there is no traditional RAID controller pair - data protection is provided by the PowerStore RAID/mirroring scheme configured per volume or automatically.

PowerStore supports Unified (block + file) and Block-only configurations; file (NAS) services run on the same appliance nodes and require the Unified license/configuration; block-only appliances do not serve SMB/NFS.

PowerStore Manager is the HTML5 GUI; PowerStore CLI (pstcli) and REST API provide equivalent programmatic access; the REST API is the recommended automation interface and is versioned by PowerStoreOS release.

Data-in-place upgrade paths: PowerStoreOS major releases are non-disruptive when the upgrade path is supported; always check the PowerStoreOS support matrix for the current appliance model before upgrading.

PowerStore appliances can be clustered (scale-out) up to four appliances in a single PowerStore cluster, with volumes and file systems presented cluster-wide; a cluster shares a single management IP and appears as one system.

Initial deployment uses PowerStore Discovery Tool (or manual connection to the service port) to find the appliance, then the Initial Configuration Wizard in PowerStore Manager to set management IP, DNS, NTP, and admin credentials.

The appliance requires a management network (for PowerStore Manager/API) and a separate storage/data network for host I/O; iSCSI and NVMe/TCP use the data network, while replication uses dedicated or shared data ports.

NTP configuration is mandatory for correct operation: replication, certificate validation, and event timestamps depend on synchronized time; configure at least one reliable NTP source during initial setup.

The service account (service user) is used for low-level troubleshooting and is separate from the admin account; the service password should be changed from default and stored securely.

PowerStore supports IPv4 and IPv6 for management and data networks; dual-stack is possible but the management and data networks must be planned consistently to avoid routing conflicts.

For a clustered (scale-out) deployment, the first appliance is deployed standalone, then additional appliances are added to the cluster; all appliances in a cluster must run compatible PowerStoreOS versions.

Storage network planning: iSCSI and NVMe/TCP initiators need reachable target portals on each node of each appliance; multipath configuration (MPIO for iSCSI, native NVMe multipath for NVMe/TCP) is required for HA.

After initial configuration, run the system health check and verify both nodes are in 'Healthy' state, all drives are discovered, and the management and data networks show link up before presenting storage.

PowerStore volumes are thin-provisioned by default; a volume has a defined size, a protection policy (snapshot/replication rules), and a host/host-group mapping for access.

Volume protection policies define snapshot rules (interval and retention) and replication rules; a volume can have one protection policy, and the policy is applied at creation or later.

PowerStore supports volume groups for consistent snapshots and replication across multiple related volumes; a volume group snapshot creates a crash-consistent set.

Thin clones and snapshots are space-efficient; a clone is an independent writable copy, a snapshot is a point-in-time read-only (or refreshable) copy; both consume space only for changed blocks.

Host and host group mapping controls which initiators can access a volume; a volume mapped to multiple hosts must use a host group or be mapped individually; LUN IDs are assigned per host/host group.

PowerStore supports volume mobility (non-disruptive migration) between appliances in a cluster and to/from external arrays via native migration or import.

Capacity reporting distinguishes physical used, logical provisioned, and thin savings; monitor subscription rate and alert thresholds to avoid over-provisioning.

File systems (NAS) are provisioned on Unified appliances: create a NAS server, then a file system, then export it via NFS export or SMB share; file systems have their own protection policies.

Block protocols: iSCSI (software or hardware initiator), Fibre Channel (FC/FC-NVMe), and NVMe/TCP; PowerStore supports FC, iSCSI, and NVMe/TCP for block, and SMB/NFS for file on Unified appliances.

For FC, configure zoning between host HBA WWPNs and PowerStore node ports; PowerStore presents one target port per node per fabric; use single-initiator, single-target zones for best practice isolation.

For iSCSI, configure the host initiator to log in to target portals on both nodes of every appliance; enable MPIO with the PowerStore-recommended DSM/ALUA settings for path failover.

For NVMe/TCP, use native NVMe multipath on the host; PowerStore advertises ANA (Asymmetric Namespace Access) states to optimize path selection.

Host connectivity is validated in PowerStore Manager under Hosts & Host Groups; each host shows initiators, mapped volumes, and connection status; a host can have multiple initiators (multipath).

NAS configuration: create a NAS server (with its own IP and DNS), then file systems, then NFS exports or SMB shares; SMB requires AD/LDAP or local user configuration; NFS uses export policies with host access rules.

For NAS high availability, NAS servers can be configured with a preferred node and failover to the peer node; NFSv3, NFSv4.1, SMB 2.1/3.x are supported depending on PowerStoreOS release.

Multipath best practice: at least two paths per volume per node to survive a single port, cable, or switch failure; verify path state 'active/optimized' in host MPIO output.

Protection policies combine snapshot rules and replication rules; a snapshot rule defines frequency (e.g., every 5 min, hourly, daily) and retention count/age; a replication rule defines RPO and target.

PowerStore native replication is asynchronous (and supports synchronous for some configurations) between PowerStore systems; replication pairs are configured per volume or volume group and require a remote system connection.

Snapshot operations: create on demand, schedule via protection policy, refresh a volume from a snapshot, clone a snapshot, and restore; snapshots are thin and space-efficient.

Volume group snapshots provide crash-consistent copies of multiple volumes; use for applications spanning multiple LUNs (e.g., databases with log and data volumes).

Replication failover/failback: a destination volume can be promoted for failover; after failback, re-establish replication; plan RPO and network bandwidth for the replication link.

Remote replication requires network connectivity between the source and destination systems (FC or IP), matching or compatible PowerStoreOS, and sufficient capacity on the destination.

Snapshot retention and space: snapshots consume space as source data changes; monitor snapshot space and configure automatic deletion policies to prevent pool exhaustion.

For external protection, PowerStore supports native migration and import from supported external arrays, and can replicate to a remote PowerStore cluster for DR.

PowerStore Manager dashboards show capacity, performance (IOPS, bandwidth, latency), and health; the Performance page provides per-resource metrics for volumes, hosts, appliances, and nodes.

Alerts are generated for hardware faults, capacity thresholds, replication lag, and connectivity issues; alerts can be forwarded via SNMP traps, email (SMTP), and syslog.

Performance metrics: IOPS, bandwidth (MB/s), latency (ms), and queue depth; analyze per-volume and per-appliance to identify hotspots and imbalance between nodes.

PowerStore uses an internal performance archive; historical metrics are available for trending; use the REST API for automated metric collection and integration with external monitoring.

Capacity alerts: configure thresholds for pool and volume subscription; thin-provisioning over-subscription should be monitored against physical free space.

Health monitoring: both nodes should report 'Healthy'; drive, fan, power supply, and port faults appear as alerts with recommended actions; use the service account for detailed diagnostics.

SupportAssist (or equivalent remote support) can be configured to automatically send alerts and logs to Dell support; verify connectivity and registration during initial setup.

Performance troubleshooting order: check host multipath (path count/state), then node balance, then volume-level latency, then backend drive utilization; correlate with alert timeline.

PowerStoreOS upgrades are performed via PowerStore Manager (or CLI); the upgrade is non-disruptive for supported paths but requires healthy nodes, sufficient free space, and a verified support matrix.

Before upgrade: verify both nodes healthy, no active alerts, replication in sync, and a recent configuration backup; upgrades cannot proceed if the system is in a degraded state.

Node replacement and drive replacement are service procedures; use the service account and follow the documented procedure; drive replacement is automatic rebuild in the background.

Configuration backup and restore: PowerStore supports configuration backup to an external server; restore is used for disaster recovery of management configuration, not data.

Troubleshooting connectivity: verify physical link, VLAN/zone configuration, initiator login, and target portal reachability; check PowerStore alerts and host MPIO status.

Log collection: use PowerStore Manager to collect support logs (or the service CLI) for Dell support; logs include alerts, performance data, and configuration.

Common issues: replication lag (check bandwidth/RPO), snapshot space exhaustion (check retention), host path failures (check zoning/multipath), and capacity alerts (check subscription).

Firmware and drive compatibility: use the PowerStore support matrix to confirm drive and firmware compatibility before adding or replacing hardware.

PowerStore uses role-based access control (RBAC): built-in roles include Administrator, Storage Administrator, and VM Administrator, with granular permissions; assign least privilege.

User authentication: local users and external directory (AD/LDAP) integration for management access; configure AD/LDAP for centralized authentication and group-to-role mapping.

Multitenancy: PowerStore supports multiple tenants (in newer PowerStoreOS) with isolated resources; each tenant has its own users, hosts, volumes, and networks; verify tenant support in the installed release.

Data security: encryption at rest via Self-Encrypting Drives (SED) and/or external key manager (KMIP); configure the key manager and back up keys before enabling encryption.

Network security: management and data networks should be separated; use VLANs and firewall rules; restrict management access to trusted networks; enable HTTPS/TLS for PowerStore Manager and API.

Audit and logging: events and alerts are logged; forward syslog to a central server for audit; monitor for unauthorized access attempts and configuration changes.

Certificate management: replace default certificates with CA-signed certificates for PowerStore Manager and API; ensure NTP is configured so certificate validity checks pass.

Session and password policy: configure password complexity, session timeout, and account lockout; disable unused accounts and rotate service credentials per policy.