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
|
