HPE ASE Storage Architect study materials
HPE ASE Storage Architect study resources

HPE ASE Storage Architect: Storage Management and Operations

HPE ASE Storage Architect · Work through your exam, one topic at a time.

All guide sections

Storage Management and Operations

This domain covers day-2 operations: proving the array is healthy and fast, forecasting capacity before it runs out, and making changes in a supported, auditable way.

The observability stack

  • HPE InfoSight consumes array telemetry for predictive analytics, wellness recommendations and cross-stack correlation.
  • DSCC manages cloud-managed Alletra and Primera estates, including firmware, health and provisioning.
  • OneView covers compute and fabric; GreenLake Cloud Platform holds subscriptions, contracts and metering.
  • Remote support must be enabled, because many predictive and automated case-creation features depend on it.

Performance triage order

Scope the symptom first (one host, one LUN or the whole array), then work outward:

  • Host: queue depth, path state, HBA errors, OS-level latency.
  • Fabric: ISL oversubscription, buffer credits, CRC and link-reset counters.
  • Array: per-port, per-VLUN and per-volume statistics, QoS or priority optimisation limits, controller CPU and cache.
  • Backend: drive latency, media errors and rebuild activity.

Array-side versus host-side latency localises the fault. If per-VLUN array latency is 0.6 ms while the host reports 20 ms, the array is not the bottleneck and escalation should go to fabric or host first.

Capacity management

  • Track thin volume overprovisioning ratio, CPG growth increment and warning limits.
  • Run host-side unmap or reclaim, monitor compaction savings, and use Adaptive Optimization where tiering exists.
  • Report snapshot and replication reserve separately from user data.

Lifecycle

  • Apply firmware through DSCC or OneView with pre-checks and health validation; follow supported node and shelf replacement procedures; reconcile GreenLake usage against subscribed capacity.

Worked example

A database team reports 20 ms reads. Host metrics show 20 ms, per-VLUN array latency is 0.6 ms, one fabric ISL runs at 85% utilisation, and an HBA port logs CRC errors. Conclusion: fabric congestion and physical errors, not the array. Rebalance the ISL, replace the optic, and confirm path failover policy. Raising an array firmware case without this evidence loses a day.

Traps that cost marks

Diagnosing from host metrics alone; using averages that hide tail latency; ignoring rebuild impact; aggressive thin provisioning without alerts; leaving CPG warning limits unset; making unsupported changes outside managed tooling; and operating with remote support disabled.