> In this day and age, when we are trying to get the message across that
> the old iron can still provide valuable services to the distributed systems
> across the campus; I am faced with a problem of incorporating ADSM into
> our chargeback scheme.
> Most departments would like a fixed price so that they can budget. At the
> same time, the pricing should be different for servers, who may dump
> millions of bytes vs some who will dump a few kilo bytes everyday.
> I simply can not translate the normal CPU and IO rates to Bytes transferred
> or recovered. When I do that, that will scare away the users the very first
> time they backup and see a big charge for their full backup.
We have a Storage Technology silo using e-tapes and 36-track drives. With
compression we can store terabytes without much problem. Charging by the
megabyte on ADSM would be a tragic mistake for us because we have plenty
of tape repository, but then charging at all is a tragic mistake (because
it makes extra work for me) but our scarce resource is disk space for our
catalog. I think it is imperative for us to charge by the object and almost
ignore the amount of data. We have had a few catalog corruptions in the
past and get very nervous when our catalog grows too large.
We have some filesystems with over 1/4 million objects stuffed into 1.5GB.
That 1.5GB is not a problem for us. The 1/4 million objects is. One might
speculate and say, "Ah, what if they take those 1/4 million objects and
stuff them into, say, 1000 huge tarfiles instead, in order to save charges?"
I would love it if all of our users did this! I would better prefer if they
stuffed the whole darned thing into one huge tarfile! Our database woes would
be virtually eliminated!
The other advantage to charging by the object would be to encourage
users to learn how to code their include/exclude files. Backing up
things like the X11R5 distribution to ADSM is stupid if it's never
being modified and it burns up a ton of database disk to boot.
ADSM is a splendid product for restoring ones'ies and twos'ies and
nothing else even comes close to it in terms of performance and
useability. I think something like X11R5 distributions are better
left to other methods of backup, especially if they are just there
spinning away and never get updated.
I suggest you explore something like the following:
1. Bill by some combination of object and KB counts from the
accounting records (velocity) that ADSM cuts
2. Bill for storage costs extracted from the "q occupancy" command
(position).
Both of these facilities provide very easy access to this data. You might
be able to estimate a charge by asking a user how large his filesystem
is, how many objects he has and how much is changing each day. Let's
say you charge the following (I just made this up, the numbers are just
for simplicity):
1 cent/object backed up
1/100 cent/object/day stored
1 cent/KB backed up
1/100 cent/KB/day stored
Get my drift? Now, I would give them the first fulldump for free. You're
going to make something for storage charges anyway. He can vary his
policies and management classes in order to lower his storage costs on
top of everything else. You might make a sliding scale, that is if he
has too many small objects, you might add a premium. This would encourage
him to "archive" old, seldom used directories into a single tarfile, thus
reducing his inode-count and his storage and backup charges.
Almost everyone benefits in this scenario. I have a few directories that
have a ton of small files (daily logs) that I occasionally tar into one
large file. With compression, the tarfile becomes quite compact.
Lastly, it will encourage people to use client compression, thus cutting
down on net traffic and resulting in lower KB counts in his accounting
chargebacks.
________________________________________________________________________
| Mitch Sako \\\\ \\\\ \\\\\\\\ |||||||| /////// // // |
| I-NET Corporation \\ \\ \\ \\ \\ || // // // |
| LSI Logic Contract \\ \\\ \\ \\ || // //////// |
| Mailstop E-195 \\ \\ \\ || // // // |
| 1501 McCarthy Blvd. \\ \\ \\\\\\\\ || /////// // // |
| Milpitas CA 95035 |
| local: mitch@dc49 Phone: (408) 433-4187 |
| internet: msako AT lsil DOT com FAX: (408) 433-8796 |
| uucp: lsil!msako Pager: (408) 989-3365 |
| ibmmail: USMILUN9 AT IBMMAIL |
| DISCLAIMER: Opinions expressed are mine alone |
|______________________________________________________________________|
|
