This post is more than 5 years old
13 Posts
0
1415
How can we get Storage Group metrics to fill in for "capacity" other than a zero for non vmax3 arrays?
We are running SRM version 4.0.1. Under "Explore>>Storage>> Storage Systems>> XYZ >> Components >> Storage Groups", for our non vmax3 arrays the cells for "Capacity" all fill in with just a 0. If you read the description for that column, it says "Total Capacity of the Storage Group. This is known as Subscription (GB) in UniVmax for VMAX3 arrays."
We need to see the actual real numbers and not just a bunch of zeros for this column for our non vmax3 arrays. How do we fix this? I couldn't find anything where I looked.
I found something in the vmax collecting config not sure if it means anything or not.
Here it is:
Can anyone help?
alanscopa2015
13 Posts
1
May 24th, 2017 06:00
During my WebEx with EMC support, we discovered Solutions Enabler for the server running Unisphere has version 8.1.0.0 and the Solutions Enabler for the collector is running version 8.3.0.6 which according to the Support Matrix is a no no. Client side version should be less than or equal to the version on the server side.
So with that said, I need to upgrade the SE on the server side and see if this solves the issue.
Sooksun_CCI
14 Posts
0
May 22nd, 2017 07:00
Hello alanscopa2015,
We are using 4.0.1 and we have VMAX systems from the first gen to all flash. Each one I check, the capacity cell for storage groups is populated. Also, quick side note, storage group capacity numbers provided in SRM is from the back-end calculating a sum up all the devices that make up the storage group. So for those arrays I would first check to see if you are seeing capacity numbers for individual devices. If you are, then you are polling the numbers and something isn't happening to calculate the storage group capacity. If the devices are also missing capacity numbers then you are not polling the VMAX systems correctly, which means double checking all configurations and proper operation of Solutions Enabler operation. I know for our environment, we are constantly fighting with stp file buildup in /var/symapi/stp/spa/DMF_ / and have to clear it every so often.
I'm interested to see what you find. Please update if you find something else. I'll update if I can think of anything else.
Sooksun_CCI
14 Posts
0
May 22nd, 2017 08:00
One other thing. I was reviewing our environment's configuration. I noticed an artifact from 3.7 days, but we do put VMAX and vmax3/AF on separate collectors. I don't believe that is a requirement for SRM 4.x, but it hasn't hurt us either.
alanscopa2015
13 Posts
0
May 23rd, 2017 08:00
Thank you for your feedback. We are running 2 different collectors for the 2 different arrays (vmax and vmax3). I did check the version of SE and we are running V8.1.0.0 which appears to be in range of the requirements. Must be something going on in the background. I'm opening an SR.
nerdnair
68 Posts
0
May 24th, 2017 11:00
Like sooksun_cci mentioned, Storage Group capacity is a calculated value on the lower nodes, where a spatial sum is done on the LUN capacity and sent up to the parent node using the nop formula.
If SG capacity is being returned as 0 then I would think the LUN "metrics" are not collected properly and only the "properties" are being collected, which sounds like a Solutions Enabler (SMI-S) data collection problem, as performance collection is done using SMI-S.
Once you upgrade Solutions Enabler on the Server side like you suggested above, a good way to test if the metrics are being collected properly is by setting up a file connector, the below link should help you with that.
Video Link : 161764
P.S : On a side note,alanscopa2015 I believe we were in the same ViPR SRM training session in Oct, 2015 at Milford. :-)