|
You are here: 6.0 Managing Fairness - Throttling Policies, Fairshare, and Allocation Management > Charging a Workflow
|
|
6.6 Charging a Workflow |
|
|
You are here: 6.0 Managing Fairness - Throttling Policies, Fairshare, and Allocation Management > Charging a Workflow
|
|
6.6 Charging a Workflow |
|
The first thing you need to do is install Gold 3.0. You can do this through the Adaptive Computing website. After Gold is installed you can look at the createExampleGoldState.pl script to see examples of how to define users, projects, accounts, and charge rates in Gold. You can also run the script to set up a few test users, accounts, and charge rates in Gold. If ever you want to clear the sqlite database in Gold, run "./resetdb" as root with the first parameter being the Gold user and it will make the Gold state the same as a fresh install.
The out-of-the-box-solution doesn't use the Create or Modify NAMI URL. Moab uses the reserve URL to reserve funds and charge for setup costs, the charge URL to reserve funds and charge for reoccurring costs, and the delete URL to unreserve the funds. These three URLs must be defined in moab.cfg in order to charge a workflow. You should set a Reserve Failure Action in moab.cfg (the bottom line in the example) in case the customer doesn't have enough funds to proceed. Therefore a sample moab.cfg might look like this in the NAMI section:
AMCFG[nami] TYPE=NATIVE AMCFG[nami] ReserveURL=exec:///path/to/cloned/repo/bank.reserve.gold.pl AMCFG[nami] ChargeURL=exec:///path/to/cloned/repo/bank.charge.gold.pl AMCFG[nami] DeleteURL=exec:///path/to/cloned/repo/bank.delete.gold.pl AMCFG[nami] FLUSHINTERVAL=hour AMCFG[nami] ReserveFailureAction=HOLD
The nami.cfg file was designed to be similar to the moab.cfg. Each line is parsed as either "Predicate[constant] Attribute=value" or "key value". Everything but the constants Each constant in the JobTemplate predicate identifies specific job templates in moab.cfg. In respect to the workflow, nami.cfg needs to know about:
(required) What job template in the workflow is the infinite job that you will charge based on a recurring bill cycle. In order to specify this you must set the recurring attribute to true. For example:
JobTemplate[newvm] Recurring=True
(required) What job template starts off the workflow where you will reserve funds for the eventual infinite job's first recurring bill as well as any setup costs that might occur. For example:
JobTemplate[newvm] StartJob=newvmprovision
(required) What job templates proceed the infinite job. This is important to register these template names with NAMI in case of a job failure, otherwise NAMI will simply ignore them.
JobTemplate[newvm] TemplateDepend=newvmprovision JobTemplate[newvm] TemplateDepend=vmstoragehookup
(optional) Gold VBF charge rate associated with provision jobs. These charge rates will be fixed setup costs per provision job that will be summed up and reserved with the first recurring bill at the runtime of the start job. They will be charged at run time of the infinite job to ensure that all provision jobs ran successfully. It is important to note that the run time of the infinite job is also when the bill cycle starts. The first recurring bill is not charged with the setup costs at the beginning of the first bill cycle but rather at the end of each bill cycle after the resources are used. The following is an example of configuring multiple set up costs:
JobTemplate[newvmprovision] GoldChargeRateName=VmSetUpCost JobTemplate[vmstoragehookup] GoldChargeRateName=VmStorageHookUpCost
(optional) In case you want to toggle billing on and off for a workflow, you can use the "TrackUsage" attribute. The attribute only needs to be set on the recurring job for each workflow. Since having billing on is the default behavior, here is an example of turning billing off:
JobTemplate[newvm] TrackUsage=False
JOBCFG[newvmprovision] GENERICSYSJOB=TRUE JOBCFG[newvmprovision] INHERITRES=TRUE JOBCFG[newvmprovision] FLAGS=NORMSTART JOBCFG[newvmprovision] TRIGGER=AType=exec,Action="$TOOLSDIR/newvmprovision.pl $*.SM",EType=start,Timeout=2:00,Flags=objectxmlstdin JOBCFG[vmstoragehookup] GENERICSYSJOB=TRUE JOBCFG[vmstoragehookup] INHERITRES=TRUE JOBCFG[vmstoragehookup] FLAGS=NORMSTART JOBCFG[vmstoragehookup] TEMPLATEDEPEND=AFTEROK:newvmprovision JOBCFG[vmstoragehookup] TRIGGER=AType=exec,Action="$TOOLSDIR/vmstoragehookup.pl $.SM $.SMMAP",EType=start,Timeout=2:00,Flags=objectxmlstdin JOBCFG[newvm] FLAGS=VMTRACKING SELECT=true JOBCFG[newvm] TEMPLATEDEPEND=AFTEROK:vmstoragehookup JOBCFG[newvm] FLAGS=NORMSTART JOBCFG[newvm] DESTROYTEMPLATE=destroyvm
JOBCFG[newvm] MIGRATETEMPLATE=migratevm
JobTemplate[newvm] Recurring=True JobTemplate[newvm] StartJob=newvmprovision JobTemplate[newvm] TrackUsage=True JobTemplate[newvm] TemplateDepend=newvmprovision JobTemplate[newvm] TemplateDepend=vmstoragehookup JobTemplate[newvmprovision] GoldChargeRateName=VmSetUpCost JobTemplate[vmstoragehookup] GoldChargeRateName=VmStorageHookUpCost
Recurring jobs are represented in Gold as usage records. A usage record helps constrain what account to charge, how much to charge, as well as keep record of additional information about the job. The nami.cfg file defines what the usage record will like for the recurring job. Each constant in the UsageAttribute can be an account constraint, charge rate name, usage record property name, or any combination of the three. Because the constant can be a usage record property (something that gets recorded and shown when you do a glsusage) and a charge rate name, most people make charge rate names match the usage record property. For example, Processors is something that you probably want to both record and charge for, so it is easier if the charge rate name and usage record attribute name are both called "Processors" and nami.cfg has the line:
UsageAttribute[Processors] MoabXMLAttribute=Processors
The nami.cfg file interprets this to mean that the value in the Processors tag sent from Moab should be the same value passed in the Processors tag in the usage record sent to Gold. Gold will then recognize that it is the usage record property name, so it will record it and show it when you do a glsusage command and will also recognize that it is a charge rate so it will charge it accordingly. Other attributes like user and project help constrain which account gets charged. However, there is nothing preventing you from making additional charge rates in Gold for them as well.
Currently, the NAMI scripts allow anything in the Moab job xml to be sent to Gold, including gres and user-defined variables. Gres and variables are expressed with either a 'gres:' or 'var:' prepended to the name of what it is representing. For example you might see the following in nami.cfg:
UsageAttribute[Disk] MoabXMLAttribute=GRes:Os UsageAttribute[StorageHost] MoabXMLAttribute=Var:SH
SetupTime: The amount of time (in seconds) beyond the bill cycle time that the reservation for the setup cost and first bill cycle should last before it destroys itself(defaults to 43200). Here is an example of how to define it in nami.cfg
SetupTime 3213 (Defaults to 43200)
BillCycle: The amount of time of the bill cycle. It helps determine much funds to reserve for each bill cycle. Possible values are hour, day, week, month (the default is day). If you want to over- or under-reserve funds for the bill cycle, you can also configure the default values for hour (60), day (86400), week (604800), and month (2630000). Be careful to understand that if you use this with RoundChargeDuration, the charge duration will be rounded to the modified bill cycle which is probably not what you wanted to do. Configuring the bill cycle time is intended to increase or decrease the barrier of entry for your job and assumes that the charge duration is not rounded. Here is an example of setting the bill cycle and changing the time duration of "month."
BILLCYCLE Month (Defaults to Day) BILLCYCLE[Month] 2640000 (Defaults to average seconds in a month)
RoundChargeDuration: If set to true, then the charge duration sent from Moab will be rounded up or down to match what was quoted within the default bounds of plus or minus 0 seconds. Otherwise, charge duration will not be rounded.
The bound to round the charge duration is configurable with the Bound attribute. Here is an example of rounding the charge duration if it is within plus or minus a half a day:
RoundChargeDuration True (Defaults to False) RoundChargeDuration[config] Bound=43200 (Defaults to 0)
Log: If set to true, the nami.log will also include everything that is written to the gold.log in /opt/gold/log/. An example log configuration is:
LOG[config] path=../log/nami.log (Defaults to ../log/nami.log) LOG[config] loglevel=debug (Possible values are fatal, error, warn, info, debug and it defaults to info) LOG[config] includeGoldLog=false (Defaults to true) LOG[config] permissions=640 (Defaults to 666) LOG[config] maxSize=10000000 (Defaults to 10000000) LOG[config] rolloverLimit=7 (Defaults to 7)
Copyright © 2012 Adaptive Computing Enterprises, Inc.®