NVRAM Battery Fault on a PowerStore 5200T During Business Hours
At 09:20 on a Tuesday, a two-node PowerStore 5200T cluster running PowerStoreOS 3.2 raises a major alert: node B has an NVRAM battery fault and its NVRAM cache is disabled. The array remains available and all 180 VMware VMs are still running over Fibre Channel, but PowerStore Manager shows the system as Degraded and host latency has risen from about 2 ms to 12 ms. The customer has a change window at 22:00 and wants to know whether waiting is acceptable. They replicate one 8 TB volume asynchronously to a PowerStore 1200T at a DR site with a 1-hour RPO. Replacing the NVRAM module requires powering off node B. The customer has no spare node and cannot take an outage.
1. Is there an immediate data-loss risk if the customer waits until 22:00? Explain how PowerStore write caching and node redundancy affect the answer.
Read the worked answer
There is no immediate data loss, but the risk is elevated because redundancy is reduced. PowerStore mirrors write cache between the two nodes, so a write is normally protected on both nodes before it is acknowledged. With node B's NVRAM cache disabled, that mirroring is no longer fully available on B. The array can continue serving I/O through node A and the peer, but if node A also fails before B is repaired, writes that were acknowledged only on A's NVRAM could be at risk. The DR replica does not eliminate this risk because it is asynchronous with a 1-hour RPO.
Waiting until 22:00 is therefore a business risk decision, not a technical all-clear. It is defensible only if node A is healthy, there are no other alerts, the replication session is in sync, and backups are current. If the customer cannot accept any exposure, replace the NVRAM sooner during a low-I/O period rather than at peak.
2. What checks and sequence should be completed before powering off node B, and what impact should the customer expect?
Read the worked answer
Before the change, verify that node A is healthy and not reporting any hardware alerts, that all hosts have redundant paths to node A, that the replication session is healthy and within RPO, and that backups or snapshots exist for critical volumes. Confirm SupportAssist connectivity so the replacement is logged and any parts are dispatched correctly. Schedule the work for the lowest I/O period, not simply the stated window.
During the replacement, expect node B to be taken out of service and its host paths to drop. Multipathing hosts should continue I/O through node A, but a short pause or path failover is normal. After replacing the NVRAM module and powering node B back on, confirm that it rejoins the cluster, its NVRAM cache is enabled, and both nodes show healthy. Then rescan hosts and validate that all paths have returned before closing the change.
3. Why did latency increase when node B's NVRAM cache was disabled?
Read the worked answer
NVRAM is the write-cache layer that allows PowerStore to acknowledge writes quickly before destaging to media. When node B's cache was disabled, the array lost part of its normal write-cache capability and had to rely more heavily on the surviving node and on destaging behavior. That increases write latency, especially for small random writes, and can also reduce effective parallelism because one node is no longer contributing a full cache.
The jump from 2 ms to 12 ms is consistent with a degraded cache path rather than a capacity or SAN problem. The key diagnostic point is the timing: latency changed at the same time as the NVRAM alert, and other volumes remain available. Fixing the NVRAM fault should restore normal latency; until then, avoid heavy batch jobs that amplify write pressure.