HPE Storage Users Group

Hi all,

I have an AO schedule that has an 8am-5pm reference period. Last night it moved 1023gb from NL to FC storage, and I have no idea why. It's highly unusual.

I've got over a large number of virtual volumes, and trying to track it back to what was actually moved is difficult. Obviously I can see the changes in CPG utilisation, and the AO region move graphs only show this one movement last night (Tier 2 to Tier 1).

How does everyone track their AO movements per volume?




Joe

What 3PAR OS version are you running?

And what does srrgiodensity state for the given AO config? Use -etsecs and -btsecs to get the information from the sample period.

If I was to make an assumption, 1023GB is so close to an even number (1024) that I think you are either maxing out how much data AO can do in one run, or you're hitting a bug limiting you from moving even more. Srrgiodensity will show which one it is.

_________________
The views and opinions expressed are my own and do not necessarily reflect those of my current or previous employers.

The strange thing is, the night after, it moved 1023gb back down to NL storage. Exactly the same movement but reversed.

I am trying to explain how bizarre this is to HP support, but all they keep telling me is that it was an unusual IO pattern which caused it, and refuse to look into it any further.

Obviously this means the issue automatically resolved itself, but I want some reassurance that it's not going to happen again.

Version is as follows:

cli% showversion
Release version 3.2.1 (MU3)
Patches: P17,P18

Component Name Version
CLI Server 3.2.1 (MU3)
CLI Client 3.2.1
System Manager 3.2.1 (P18)
Kernel 3.2.1 (MU3)
TPD Kernel Code 3.2.1 (P17)
TPD Kernel Patch 3.2.1 (P18)

AO simply responds to your workload so I'm not sure why this would warrant further investigation other than maybe within your server / application estate. It could be the data in those regions is borderline for promotion and a transitory load forced AO to push them up, once passed AO demoted the data. You could spend an inordinate amount of time trying to track down volumes those regions belong to only for it never to happen again. It looks like AO simply did its job based on the data supplied at that point in time

I think I'm just going to have to accept that, as much as it puzzles me. There was nothing else out of order that day. Literally just a normal day in every statistic..... except for 1023gb of data moved one way and then back the day after.

Appreciate the responses.
Joe