Re: Setting up ASP

Doug,

Geez ... it's only an example <g>

Actually, the drive counts were from the original post as a point of
reference, the percentage of usage was from my own experience.  We did
not have the same mix of drives.

I did not mean to imply that our solution could directly be translated
into their situation, just making a statement of factors to consider.

In the real case, we doubled our total disk capacity (but not arms, due
to drive difference) and dropped from pushing 70% to 35% utilization in
the base ASP.

I agree, it is all a matter of numbers.  And one -must- do their own
math.

I also admit, I do not have the model number/capacity memorized, nor did
I research the original post to truly understand the particular
scenario.  Duh, lower model number, lower capacity ... should have
caught that one! <g>

From your post, the 30 drives, each, have twice the capacity of the
other 6.  Our situation is not the same.  We added half the number of
drives at twice the capacity each.

And yes, the customer services department (90% of the users) are
creating high arm usage against a normalized gazillion file data base as
they talk on the phone and require subsecond response time.  The rest of
the users are back room accounting that primarily perform batch type
process against a different set of files.

Well, OK, it's not a gazillion, but just off the top of my head, these
staff members are performing at least 20 CHAIN/READE's once they enter
an account number, until they want to display detailed invoice history. 
It's the detailed invoice history file that is the heavy hitter that we
moved to a separate ASP.

And once I told the back room people about this thing, wouldn't you know
it, they started mining it! Go figure.

Hence, by moving the activity against this file to a separate ASP, the
90% users were no longer penalized by access to this huge file.  (3
years of detail) BTW, the file has enough records in it that it is
created to reuse deleted records and it hasn't been reorganized in over
two years.  The last time we did it, it took 12 hours. And that was when
we moved it to fewer drives/arms! Each month we archive out old data
making room for new, but who knows where, or how far scattered, the
complete set for a given entity will wind up.  (The company only shuts
down 2 days per year)

Maybe what I'm getting to is that it's more than just the hardware
numbers that determine if one should or should not have a separate ASP,
but the user community and/or data base structure and demand that makes
this kind of request an "it depends".

BTW, I won't tease you too much for stating drive capacity in MB instead
of GB, it's these types of easy mistakes that can cause someone to get
picky with your post. <G>

P.S. I've seen a lot of email shorthand, but never YMMV. I'm guessing:
Your Move M... V...?  Or maybe: You Make Me Vomit?  I hope you're
playing nice.



Douglas Handy wrote:
>  
> The math seems creative.  If we ignore capacity lost to device parity
> for the sake of simplicity, we have:
> 
>   <<snip>> a lot of good stuff detailing drive capacity planning
> 
> I'm not arguing the theory, but I think you'd need more arms left in
> the system ASP in relation to the recommended minimum and/or for the
> historical data to be a bigger percentage of the total capacity to
> come out ahead.  Those scenarios can well exist, and evidently did in
> your case, but I think they are the exception rather than the norm.
> 
> How many arms did you move to a history data ASP, and how many arms
> were left in the live data ASP?  What is your system's recommended
> minimum disk arms?
> 
> YMMV,
> Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---