Just a quick note that one thing I see missing from most billing schemes is memory usage. How much memory is assigned to the guest can have more of an impact on the system than CPU, depending on the environment. It's also easier to monitor as the virtual machine guest size stays fairly static. So I would include the memory as part of the billing scheme.. charge a fair amount per 1G of memory to discourage apps from grabbing large chunks of it 'just because'.
Scott On Thu, Apr 2, 2009 at 8:38 AM, Scott Rohling <[email protected]>wrote: > I did some work at one time to have a Linux server cut a z/VM accounting > record, setting the account code of the owning process before a process ran, > and a 'close' afterwards. Major flaw: this only works for one process at a > time. All the CPU used during the process run counted toward that process > - so you could only run one app at a time to reliably capture things.. BUT > - it was nice to feed this data in the existing z/VM accounting which we > already had a billing process for. > > I haven't seen a process level billing scheme, but it's certainly possible > .. typically though - the simplest thing to do is have a server dedicated > to a particular task and bill the owner of the task. > > As far as billing schemes .. they tend to fall into 2 camps: > > - 'Actual' : Prices are established for CPU usage and disk storage. A > monthly capture of the usage turns into a bill for each account. Alot like > a power bill. > > - 'Planned': Prices are established for expected usage, expected usage is > determined, and a static monthly bill is sent. A review of this compared > with 'actual' usage is necessary to ensure everyone is staying within their > expected usage. Going over the expected usage consistently means the bill > is renegotiated for more. > (Within 'planned' there are usually sizes established - small, medium, > large, etc.. 500$ for small, $1000 for medium $2000 large as an example). > Sort of like your cable/satellite bill -- have you got the 100 channel or > 500 channel package? > > Anyway - I would recommend: > > - Bill at the server level. Process level is just too cumbersome when you > can throw up another virtual server and separate workload that way. > > - Use planned billing. With actual -- the bill can vary wildly from > month to month and is usually upsetting to those getting billed. Like all > of us - they (the app owners) want a fairly static bill they can count on. > Which bills do I get upset at myself? Phone and power.. My static > satellite bill, loan payments, etc -- I can plan for. > > Hope this helps - > > Scott > > > > On Thu, Apr 2, 2009 at 8:15 AM, =?iso-8859-1?Q?Greg_Dyrda?= < > [email protected]> wrote: > >> We currently bill for Linux on a per guest basis. I'm wondering what >> approach others are taking. Specifically, I'm wondering if it is possible >> to bill at the process level and if anyone else is billing that way. >> > >
