HPE Storage Users Group

How do i findout if my A650 Array has reach its limits, and require an upgrade to A670 ?

or what is the trigger point i should stop introducing new workload to the array and get another array ?

JinSXS wrote:How do i findout if my A650 Array has reach its limits, and require an upgrade to A670 ?

or what is the trigger point i should stop introducing new workload to the array and get another array ?

A very generic answer, when your latency increases.

Your problem is probably that by the time you notice the latency it's too late

Depending on know scared you are about this issue, HPE provide a performance analysis (paid service) where they will measure the load for multiple days/weeks and provide a detailed performance overview compared to assumed maximum performance of the system. Do one every X months to monitor how the load increases to get an understanding of when you need to stop scale up and start scaling out.

Good question.

The short answer is HPE created a saturation % metric in Infosight and SSMC to help you measure that.

The long answer is it depends. QoS can help maintain a required latency on certain hosts, while non-latency sensitive applications "take the hit" to mitigate saturation. Troubleshooting should be done to locate the performance bottleneck to confirm controller upgrade is the right answer, and its not something else, like SAN bottleneck, or improper zoning thats the cause.

can controller CPU % be proper assessment too ?

yes i understand the saturation, is one key point...

cause somehow my 4N the node pair 0/1 seems to have 20 to 30% higher utilization compared with my pair 2/3

thats why i was wondering if im reaching the limits considering the CPU % on pair 0/1

JinSXS wrote:can controller CPU % be proper assessment too ?

yes i understand the saturation, is one key point...

cause somehow my 4N the node pair 0/1 seems to have 20 to 30% higher utilization compared with my pair 2/3

thats why i was wondering if im reaching the limits considering the CPU % on pair 0/1

If all hosts are zoned to all nodes and all traffic is RR so all nodes have the same traffic I would log a case.

That is a sign that nodes 0/1 are doing more work. Check if nodes 0/1 being used for remote replication while 2/3 are not.... also check how many hosts are attached to nodes 0/1 vs 2/3, and lastly check if you have more drives owned by nodes 0/1. If you can determine a logical explanation for the imbalance, that can help you get on the right track.

CPU% is a less critical metric on Primera than it was on 3PAR, because the storage services no longer run in kernel like the 3PAR did. Some of the Primera secret-sauce is the prioritization and automatic management of serving IO with low latency while still doing the background work required, like raid rebuilds, checksumming, garbage collection, compaction, etc.

What are you seeing CPU utilization wise across the 4 nodes?

there also seems to be another reason
as we started off with 2node then upgraded to 4 nodes,

most of the vv 95% of them the master is owned by 0/1 , according to support
somehow this is causing a higher utilization and they say there is a case with engineering about this, but can't say when it will be fix or how do we manually rebalance the mstr values on the vv

sorry for re-breathing this methusalem thread, but we recently faced the same issue: After upgrading an array from two to four nodes, load on nodes 0 and 1 was permanently higher (significantly higher) than load on nodes 2 and 3.

We balanced zonings, rc etc. across all four nodes. But this and tunesys did NOT help.

The reason was that all vvs were created with two nodes, so all work regarding vv ownership, ld ownership, garbage collection and stuff was only being done on nodes 0 and 1.

Support did advice to create a new cpg and copy all data over (tune vvs or create new ones and move data with vmware means), thus everything was well balanced again. Important: do not skip the "new cpg" part.

According to support, there is the option to have the system rebalanced by hpe in course of the expansion process, seems we missed to tick that box in the order.

Thanks for the update Apol, that is good info!