thanks for the responses. its really good to get some discussion going on this subject area. you are certainly right about 3par not considering 'real world' use when it comes to AO.
hdtvguy wrote:
rickyy7
Multiple AO configs are tricky, you will want to be careful with how you set them up and use growth warnings to govern how much AO puts in a given tier. The problem with growth warnings is you are basically capping AO for a given conifig even if there is plenty of space in that physical tier. With 3.2.1 you are allowed to run AO configs against VV Sets and I have had talks with 3par to understand how all these competing AO configs are prioritized. My biggest complaint with 3par is they often do not think through these features on how they will be used in the real world and how many problems they can introduce.
We ran 3 different AO configs on our V400 and while it works great when you have plenty of free space, it becomes very problematic if your array gets space constrained. Also if you look at some of my other posts about AO, AO needs some improvement as it will try an push data down even in Performance mode, thus you potentially wind up with very constrained lower tier disk space and free faster tiers. One thisg you do not want to do is ever run out of your lowest tier of disk. Even if you fill your fastest tier the array will always try to write to a lower tier, but will not do so if the lower tier is full.
On a scale of 1-10 I give 3par AO a 6 maybe 7, it is decent, but has a long way to go. Also with multiple AO configs you need to be careful about all the AO schedules and the amount of overhead and time it will take for all those AO schedules to get any work done, especially if they are competing for same physical tiers. And remember it is easy to crush NL drive performance.
In our experience if you ave plenty f free space in all your tiers multiple AO conifgs are ok, if you have any space limitations then managing multiple AO configs requires constant supervision. We have taken all our arrays to basically single AO configs and as we grew purchased new arrays for specific workload. We have one array for general purpose use that has 3 tiers of disk (FC, 10K and NL) which has a single AO config. We then purchased another array for our IO intense workload and it only has SSD and 10K with a single AO config. I now spend less time dealing with AO babysitting.
thanks for taking the time to post. we are fortunate to have plenty of space to play with so we may get away with multiple AO configs. The thinking was to have 3 AO groups. AO1 across SSD/FC to ensure performance. AO2 spanning all three tiers SSD/FC/NL and AO3 spanning just FC/NL. We would have CPGs for each tier for none AO VVs and to allow DO if required.
The scheduling and data allocation for multiple AOs is where I seem to find a lack of information.
zQUEz wrote:
My experience with AO has been very positive, though I do run multiple AO configs. When I first implemented I used a single config, but found AO'ing a 400TB frame would take days to complete which made me very nervous. I basically have 6-8 configs (depending on the frame), and split them so they run on alternate days.
I also found that on days where configs run together, they should be scheduled to start at the same time because then the system seems to do a better job looking at the multiple configs as a single job. This was more an issue in 3.1.1, but I still do it today with good results.
I also found out (the hard way) that going into AO, it should be an all or nothing thing with respect to NL tier. In other words, make sure AO has full control of all your NL. Don't have some VV's that are not part of an AO config also writing to NL because you kill your performance. I would extend that to say AO should have access to all your tiers. The benefit then is you only really have to manage space on your T1 tier (assuming all your usrCPGs point to that).
The only other thing is timing. I have found AO does a good job not impacting performance on other loads, and as our frames are all 24/7/365 I don't have good down windows with which to run AO at a time when users aren't also using it. but that hasn't been a problem for us.
Interesting about your findings with scheduling. My thinking was to stagger them. Thanks for sharing your findings.