Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 191 lines (155 sloc) 7.215 kb
c53bebc @timf Consolidated all backfill and spot settings to async.conf and moved the ...
timf authored
1 ################################################################################
2 #
3 # This file is used for configuring asynchronous requests (Spot Instances and
4 # backfill requests) for this site.
5 #
6 ################################################################################
7
8
9 # SI ENABLED
10 #
11 # Indicates whether the spot instances feature is enabled (true) or disabled
12 # (false) for this site. This is for remote requests -- if backfill is enabled
13 # below, the superuser backfill reqs will be honored but any remote attempt to
14 # add asynchronous requests will not be honored. If you switch this from 'true'
15 # to 'false', it will only prevent new requests from being added.
16
17 si.enabled=false
18
19
20 # BACKFILL ENABLED
21 #
22 # Indicates whether the backfill feature is enabled (true) or disabled (false)
23 # for this site. If you switch this from 'true' to 'false', it will cause all
24 # currently running backfill nodes to be destroyed.
25
26 backfill.enabled=false
27
28
29 ################################################################################
30 #
31 # Backfill settings
32 #
33 ################################################################################
34
35 # The intent of backfill is to provide a Nimbus cloud with the ability to deploy
36 # a VM on idle nodes. Such a VM could be configured with a service like Condor,
37 # allowing the VM to contribute cycles to some other purpose instead of wasting
38 # cycles on idle cloud nodes. When a user request is recieved the VM is terminated
39 # immediately and the user VM is deployed.
40 #
41 # The VM used by backfill (and the services inside of it) must be able to handle
42 # a hard shutdown. A hard shutdown is used to minimize the turnaround time for
43 # responding to user requests.
44 #
45 # A way to think about backfill nodes is that they are spot instances with the
46 # very lowest priority (lower than the minimum spot bid) and only registered by
47 # the Nimbus administrator.
48
49 # MAX INSTANCES
50 #
51 # Max instances is the maximum number of VM instances that backfill will deploy
52 # if it is enabled. If there is not enough space on the cloud for the maximum #
53 # of instances it will deploy as many as it can. For example, if max.instances
54 # is set to 12 on a 16 node cloud but there are 10 active user VMs then backfill
55 # will still launch 6 backfill nodes. If the spot instances settings have space
56 # reserved for regular requests (see the 'minreservedmem' and 'maxutilization'
57 # confs below), these backfill requests will be subject to that as well, so the
58 # site will not fill up completely.
59 #
60 # If max instances is set to 0 then backfill will use all idle VMMs.
61 #
62 # The default is 0.
63
64 max.instances=0
65
66
67 # DISK IMAGE
68 #
69 # The disk image is the image to use in the repository of the user configured
70 # below (repo.user). To set the instance type, see below (async.instancetype).
71
72 disk.image=backfill.img
73
74
75 # USER
76 #
77 # Authorization will be bypassed for this user but it needs to exist in order
78 # to have a repository account for propagating "disk.image". Add this user
79 # with the nimbus-new-user "--dn" option (set an explicit DN) or refer to a
80 # pre-existing (administrator) one.
81
82 repo.user=BACKFILL-SUPERUSER
83
84
85 ################################################################################
86 #
87 # Spot Instances settings
88 #
89 ################################################################################
90
91 # INSTANCE TYPE
92 #
93 # Defines the instance type that will become available as spot instances or backfill.
94 # Supported instance types are: small, large and xlarge.
95 #
96 # Currently, Nimbus supports only one type of spot instance or backfill VM per
97 # service. The amount of memory for each instance type is defined in the
98 # elastic.conf file.
99
100 async.instancetype=small
101
102
103 # PRICING MODEL
104 #
105 # A pricing model is invoked every time the Spot Instances environment changes.
106 # This can happen in many situations: when a request arrives, is canceled or
107 # terminated, when the quantity of resources available for Spot Instances
108 # increases or decreases, etc.
109 #
110 # Given the actual requests, the maximum quantity of VMs for Spot Instances and
111 # the current spot price, a pricing model defines the next spot price based on
112 # this variables. Usually a spot price change causes requests to be allocated,
113 # if their bid is above the spot price, or pre-empted, if their bid is below
114 # the current spot price.
115 #
116 # This property defines which implementation of the
117 # org.globus.workspace.async.spotinstances.PricingModel Java interface should be
118 # used by the Spot Instances module to set the spot price. This class will be
119 # constructed by reflection, so it must be in the classpath of the Nimbus service.
120 #
121 # Currently there are two default implementations of the module, explained
122 # as follows:
123 #
124 # ** org.globus.workspace.async.pricingmodel.MaximizeUtilizationPricingModel **
125 #
126 # This pricing model aims to satisfy the maximum number of requests, giving
127 # priority to higher bid requests when there aren't available VMs to fulfill
128 # all requests. Suitable for scientific clouds.
129 #
130 # ** org.globus.workspace.async.pricingmodel.MaximizeProfitPricingModel **
131 #
132 # This pricing model aims to maximize the revenue of the cloud provider, without
133 # necessarily increasing cloud utilization. Suitable for commercial clouds.
134
135 si.pricingmodel=org.globus.workspace.async.pricingmodel.MaximizeUtilizationPricingModel
136
137
138 # MINIMUM PRICE
139 #
140 # Defines the minimum price (in allocation units) per minute that a Spot Instance
141 # can cost
142
143 si.minprice=0.1
144
145
146 ################################################################################
147 #
148 # Memory Management Policies
149 #
150 ################################################################################
151
152 # RESERVED MEMORY
153 #
154 # The policies below define how the total resource pool memory is divided between
155 # ordinary Workspace Service requests (1st class requests) and Asynchronous
156 # requests (SI or backfill requests).
157 #
158 # It's important to note that these policies are preventive, in the sense that
159 # free space is reserved for future 1st class requests, but if the reserved space
160 # is still not sufficient to satisfy a 1st class request, SI or backfill requests
161 # will be pre-empted on-the-fly in order to free the needed amount of space
162 # (emergency pre-emption).
163
164 # This policy defines the minimum amount of free memory (in MB) that should be
165 # reserved exclusively for 1st class requests, and thus will not be allocated for
166 # SI or backfill requests.
167
168 async.policies.minreservedmem=2048
169
170
171 # MAX UTILIZATION
172 #
173 # This policy defines the maximum utilization (in %) for 1st class requests. When
174 # the utilization raises above this value, Spot Instance or backfill requests are
175 # pre-empted (preventive pre-emption) in order to decrease the utilization of 1st
176 # class requests.
177 #
178 # The Workspace Service will reserve an amount of free memory for 1st class requests
179 # in order to ensure that the utilization of 1st class requests is equal or below
180 # that value, unless there is no more available memory to reserve.
181 #
182 # The amount of reserved memory for 1st class requests is derived from this formula:
183 #
184 # * maxUtilization = usedMem / (usedMem + reservedMem)
185 #
186 # Reorganized, becomes:
187 #
188 # * reservedMem = (1 - maxUtilization)*usedMem/maxUtilization
189
190 async.policies.maxutilization=0.7
Something went wrong with that request. Please try again.