2nd forward for Shelby
dt
----------
> From: Dwight E. Cook <decook AT AMOCO DOT COM>
> From: Dwight E. Cook <decook AT AMOCO DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Charging for ADSM backup services
> Date: Tuesday, July 29, 1997 11:58 PM
>
> Item Subject: Charging for ADSM backup services
> (there really is some good info within, please don't let my attitude
> prevent you from reading this)
>
> funny you should ask this, right as I'm finishing up all the
automatic
> number generating for the "bean counters"
>
> Now Ray, where I used to be an MVS Sys Prog but now a Unixhead, I
have
> to say "bummer dude" just 'cause MVS ADSM puts its accounting
records
> in the form of "SMF" records, AIX dumps them into a nice easy to
read
> text based file (which provides immediate access).
>
> We (Amoco) are running 2 MVS ADSM servers, 4 AIX servers, and will
> have 4 more AIX servers running by the middle of next month. Bean
> count'n wise the AIX servers are killing the MVS servers. MVSADSM
> sucks CPU cycles, it is just about our top started task EVEN MORE
THAN
> CICS! How much does a processor for MVS cost? How much does it cost
> for the support crew? How many SYS PROG's do you have? All our AIX
> boxes have ONE/A SINGLE (poor soul) SYS PROG and about 1/2 dozen
adsm
> administrators trying to keep the clients from KILLING us with their
> "oh, we wanted to swap processors for this one machine and we didn't
> think anyone would mind us doing an adhoc archive of 400GB and then
> immediately pulling the 400GB back off to a different box and try to
> get it all done in less than a 12:00 hr time frame" ARGH! Had one
> little RS/6000 (single processor) with only 2 3590's in a shared
> 3494ATL and it peaked at 8.2 terabytes of traffic in a single
month...
>
> Anyway... BILLING !
>
> What kills the ADSM servers ?
> (a) inbound traffic
> (b) outbound traffic
> (c) data stored on the server
> (d) all the above
>
> Yep, (d) all the above... so recovery$=actualcost$*150% (got to
turn
> a profit) then billingrate$=(recovery$/totalresourcesused)*110%
(slip
> in even more profit) leading to
due$=clientsusedresources*billingrate$
> and then amoritize it, glamorize it, chastize it, multiplize it by
> 115% AND COLLECTIZE IT!
>
> OK, I'll get back to the subject... (and you'all just thought GOD
> answered your prayers & I had died ;-) )
>
> So each ADSM server (AIX or MVS) has a daily admin event scheduled
for
> 00:05 to run an "audit license" which updates the information for a
> "query auditocc". From a single AIX box at 00:10ish I have a cron
job
> kick off that does:
> #!/bin/ksh
> /home/dsmadmin/bin/qdlyaocc adsmsrv01
> /home/dsmadmin/bin/qdlyaocc adsmsrv02
> /home/dsmadmin/bin/qdlyaocc adsmsrv03
> /home/dsmadmin/bin/qdlyaocc adsmsrv04
> /home/dsmadmin/bin/qdlyaocc adsmsrv05
> /home/dsmadmin/bin/qdlyaocc adsmsrv06
> /home/dsmadmin/bin/qdlyaocc adsmsrv07
> exit
>
>
> #!/bin/ksh
> # /home/dsmadmin/bin/qdlyaocc
> # generates billing info, part 1 of 2
> OUTFILE=/home/dsmadmin/auditocc/nodeocc.$(date +%b%y)
> dsmadmc -serv=$1 -id=operator -pass=operator q auditocc | egrep -v
> '(^ANS51|^ADSTAR|^Command|^\(C|^License|^Node)' | grep ^[A-Z] |&
> read -p LINEIN
> while [ $? -eq 0 ] ; do
> echo $(date +%D) $1 $LINEIN >> $OUTFILE
> read -p LINEIN
> done
> exit
>
>
> so now I have a nice neat SINGLE file, in a SINGLE/CENTRAL/EASY TO
> ACCESS LOCATION with daily records which are (1) date stamped (2)
> indicate what server it is coming from (3) indicates what client it
is
> for (4) backup storage used (MB) (5) archive storage used (MB) (6)
> total storage used (MB)
> Any and every bean counters wildest desires!
> Naturally if the data is on the server is had to get there but this
> provides no indication of how much they pull off, which can kill a
> server also... so (this is where I dislike our MVS servers) each AIX
> box, monthly, sucks out the accounting records for the previous
month,
> cuts daily total records by client of archincnt archinMB archoutcnt
> archoutMB bkupincnt bkupinMB bkupoutcnt bkupoutMB totalxmitMB. Bean
> counters will faint over these numbers... Take these numbers,
> processor utilization numbers, calculus, voodoo magic, and stats and
> you can assign "weights" to each activity/condition you'll find
> archives are easier on the server 'cause there's no "version"
> calculations, tons of GB in a few files is WAY easier than a
bazillion
> little files who's data occupies less space in ADSM than the DB
> records keeping track of client, path, filename, owner, permissions,
> etc....
>
> So I guess what I'm really trying to say is billing should take into
> consideration two things (1) how much tape space are they using (2)
> how much other resources (that get tossed together in one big slush
> pool... ie CPU cycles in DB updates, network load, temporary
diskpool
> load, using of tape drives for restores when you need them to
migrate
> off the diskpool, and on and on and on...)
>
> This is, I feel, real fair 'cause if a client wishes to utilize
their
> own CPU to perform compression, the transmitted bytes reflect the
> COMPRESSED data, the occupied space on the server reflects the
> COMPRESSED data... but then there are the folks who want the speedie
> backups and send us 500GB's which shows 500GB transmitted, which
shows
> 500GB's stored, and compress down to a couple 3590 tapes...
> (20-physical GB's) but a few have caught on and send us 10GB, we
> store 10GB and it is actually 150GB of their file space.
>
> So I hope this does you some good... as far as how the weights
against
> activities go, I'm clueless. I just provide them with the base
> numbers.
>
> later
> Dwight
>
> DISCLAIMER: the attitudes & beliefs reflected above are those of
> Dwight Cook alone and don't necessarily reflect those of his
employer
> which would never refer to their accountants as "bean counters".
>
>
> ______________________________ Reply Separator
_________________________________
> Subject: Charging for ADSM backup services
> Author: ADSM-L at unix,sh/DD.RFC-822=ADSM-L AT VM.MARIST DOT EDU
> Date: 7/29/97 5:54 PM
>
>
> We are looking at alternatives to running ADSM; which we currently run on
> the mainframe. We are looking at moving ADSM to Unix; possibly investing
> in a Magstar. We are expecting management to ask for cost justification
> and we are concerned about recovering the cost of the expenditures.
>
> Question...How to you recover the costs? Does anyone have a charge back
> mechanism in place for recovering costs for backing up distributed
> services?
>
> Any ideas, suggestions, and experiences would be appreciated.
>
> Ray Mamaradlo, Systems Programmer
> Boeing
|
