|
1
|
This chapter describes how to run Haizea in simulation mode. Since the Quickstart Guide (Chapter~\ref{chap:quickstart}) already provides a tutorial-like introduction to running simulations, this chapter is meant mostly as a reference guide, and covers the main simulation and scheduling options. However, it does not cover \emph{all} possible options in the configuration file (a description of all options and their valid values can be found in Appendix~\ref{app:conffile}). It also refers to scheduling algorithms that are not currently explained in the manual (they are described in some of the Haizea scientific publications, but these might be hard to swallow). Future versions of the Haizea manual will include a description of the main scheduling algorithms used, to better orient your choice of scheduling options. Finally, this chapter also covers how to run multiple unattended simulations.
|
|
2
|
|
|
3
|
\section{Unattended simulations}
|
|
4
|
|
|
5
|
To run Haizea as an unattended simulation requires setting the following options in the configuration file:
|
|
6
|
|
|
7
|
\begin{wideshellverbatim}
|
|
8
|
[general]
|
|
9
|
...
|
|
10
|
mode: simulated
|
|
11
|
...
|
|
12
|
|
|
13
|
[simulation]
|
|
14
|
...
|
|
15
|
clock: simulated
|
|
16
|
...
|
|
17
|
\end{wideshellverbatim}
|
|
18
|
|
|
19
|
Additionally, the starting time of the simulation must be specified, along with a stopping condition:
|
|
20
|
|
|
21
|
\begin{wideshellverbatim}
|
|
22
|
[simulation]
|
|
23
|
...
|
|
24
|
starttime: 2006-11-25 13:00:00
|
|
25
|
stop-when: all-leases-done |
|
|
26
|
besteffort-submitted |
|
|
27
|
besteffort-done
|
|
28
|
...
|
|
29
|
\end{wideshellverbatim}
|
|
30
|
|
|
31
|
|
|
32
|
\section{Interactive simulations}
|
|
33
|
|
|
34
|
To run Haizea as an interactive simulation, the following options must be set in the configuration file:
|
|
35
|
|
|
36
|
\begin{wideshellverbatim}
|
|
37
|
[general]
|
|
38
|
...
|
|
39
|
mode: simulated
|
|
40
|
...
|
|
41
|
|
|
42
|
[simulation]
|
|
43
|
...
|
|
44
|
clock: real
|
|
45
|
...
|
|
46
|
\end{wideshellverbatim}
|
|
47
|
|
|
48
|
|
|
49
|
\section{Specifying the simulated physical resources}
|
|
50
|
|
|
51
|
The simulated physical resources are specified using the \texttt{resources} option in the \texttt{[simulation]} section. This option can take two values, "in-tracefile", which means that the description of the simulated site is in the tracefile, or a string specifying the site's resources. For the former, see Appendix~\ref{app:lwf} for details on how the simulated site is specified in the tracefile. When using the latter, the format of the string is:
|
|
52
|
|
|
53
|
\begin{wideshellverbatim}
|
|
54
|
<numnodes> <resource_type>:<resource_quantity>[,<resource_type>:<resource_quantity>]*
|
|
55
|
\end{wideshellverbatim}
|
|
56
|
|
|
57
|
For example:
|
|
58
|
|
|
59
|
\begin{wideshellverbatim}
|
|
60
|
[simulation]
|
|
61
|
...
|
|
62
|
resources: 4 CPU:100 Memory:1024
|
|
63
|
...
|
|
64
|
\end{wideshellverbatim}
|
|
65
|
|
|
66
|
The above describes a site with four nodes, each with one CPU and 1024 MB of memory. Note that you must always specify at least the ``CPU'' and ``Memory'' resource types.
|
|
67
|
|
|
68
|
\section{Scheduling options}
|
|
69
|
|
|
70
|
The scheduling options control how leases are assigned to resources.
|
|
71
|
|
|
72
|
\subsection{Scheduling policies}
|
|
73
|
|
|
74
|
Haizea includes a policy decision module that supports ``pluggable policies'', allowing developers to write their own scheduling policies. This is described in more detail in Chapter~\ref{chap:policies}, and we describe here only the built-in policies that are included with Haizea.
|
|
75
|
|
|
76
|
The first policy is lease admission, which controls what leases are accepted by Haizea. Take into account that this decision takes place before Haizea even attempts to schedule the lease (so, you can think of lease admission as ``eligibility to be scheduled''). The two built-in policies are to accept all leases, and to accept all leases \emph{except} advance reservations.
|
|
77
|
|
|
78
|
\begin{wideshellverbatim}
|
|
79
|
[scheduling]
|
|
80
|
...
|
|
81
|
policy-admission: accept-all | no-ARs | <custom policy>
|
|
82
|
...
|
|
83
|
\end{wideshellverbatim}
|
|
84
|
|
|
85
|
The next policy is lease preemptability, or what leases can be preempted. The two built-in policies are to not allow any preemptions, and to allow all ARs to preempt other leases.
|
|
86
|
|
|
87
|
\begin{wideshellverbatim}
|
|
88
|
[scheduling]
|
|
89
|
...
|
|
90
|
policy-preemption: no-preemption | ar-preempts-everything | <custom policy>
|
|
91
|
...
|
|
92
|
\end{wideshellverbatim}
|
|
93
|
|
|
94
|
Finally, the host selection policy controls how Haizea chooses what physical hosts to map VMs to. The two built-in policies are to choose nodes arbitrarily (i.e., ``no policy''), or to apply a greedy policy that tries to minimize the number of preemptions. Currently, you should choose the greedy policy unless you really know what you're doing.
|
|
95
|
|
|
96
|
\begin{wideshellverbatim}
|
|
97
|
[scheduling]
|
|
98
|
...
|
|
99
|
policy-host-selection: no-policy | greedy | <custom policy>
|
|
100
|
...
|
|
101
|
\end{wideshellverbatim}
|
|
102
|
|
|
103
|
|
|
104
|
\subsection{Backfilling algorithms}
|
|
105
|
|
|
106
|
\begin{warning}
|
|
107
|
NOTE: This section assumes that you are familiar with backfilling algorithms. We will try to include a brief, didactic, explanation of backfilling algorithms in future versions of the manual.
|
|
108
|
\end{warning}
|
|
109
|
|
|
110
|
Haizea supports both aggressive and conservative backfilling:
|
|
111
|
|
|
112
|
\begin{wideshellverbatim}
|
|
113
|
[scheduling]
|
|
114
|
...
|
|
115
|
backfilling: off | aggressive | conservative
|
|
116
|
...
|
|
117
|
\end{wideshellverbatim}
|
|
118
|
|
|
119
|
An exact number of allowed future reservations can also be specified:
|
|
120
|
|
|
121
|
\begin{wideshellverbatim}
|
|
122
|
[scheduling]
|
|
123
|
...
|
|
124
|
backfilling: intermediate
|
|
125
|
backfilling-reservations: 4
|
|
126
|
...
|
|
127
|
\end{wideshellverbatim}
|
|
128
|
|
|
129
|
|
|
130
|
\subsection{Lease suspension and migration}
|
|
131
|
|
|
132
|
Lease suspension can be allowed for all leases, only for 1-node leases (``serial'' leases), or not allowed at all. Additionally, Haizea can schedule suspensions and resumptions to be locally or globally exclusive:
|
|
133
|
|
|
134
|
\begin{wideshellverbatim}
|
|
135
|
[scheduling]
|
|
136
|
...
|
|
137
|
suspension: none | serial-only | all
|
|
138
|
...
|
|
139
|
\end{wideshellverbatim}
|
|
140
|
|
|
141
|
When suspending or resuming a VM, the VM's memory is dumped to a
|
|
142
|
file on disk. To correctly estimate the time required to suspend
|
|
143
|
a lease with multiple VMs, Haizea makes sure that no two
|
|
144
|
suspensions/resumptions happen at the same time (e.g., if eight
|
|
145
|
memory files were being saved at the same time to disk, the disk's
|
|
146
|
performance would be reduced in a way that is not as easy to estimate
|
|
147
|
as if only one file were being saved at a time).
|
|
148
|
|
|
149
|
Depending on whether the files are being saved to/read from a global
|
|
150
|
or local filesystem, this exclusion can be either global or local:
|
|
151
|
|
|
152
|
\begin{wideshellverbatim}
|
|
153
|
[scheduling]
|
|
154
|
...
|
|
155
|
suspendresume-exclusion: local | global
|
|
156
|
...
|
|
157
|
\end{wideshellverbatim}
|
|
158
|
|
|
159
|
When allocating time for suspending or resuming a single virtual machine with $M$ MB of memory, and given a rate $R$ MB/s of read/write disk throughput, Haizea will estimate the suspension/resumption time to be $\frac{M}{R}$. The \texttt{suspendresume-rate} option is used to specify $R$:
|
|
160
|
|
|
161
|
\begin{wideshellverbatim}
|
|
162
|
[simulation]
|
|
163
|
...
|
|
164
|
suspendresume-rate: 32
|
|
165
|
...
|
|
166
|
\end{wideshellverbatim}
|
|
167
|
|
|
168
|
Lease migration can be disallowed, allowed, or allowed but without having to transfer any files from one to another:
|
|
169
|
|
|
170
|
\begin{wideshellverbatim}
|
|
171
|
[scheduling]
|
|
172
|
...
|
|
173
|
migration: no | yes | yes-notransfer
|
|
174
|
...
|
|
175
|
\end{wideshellverbatim}
|
|
176
|
|
|
177
|
|
|
178
|
\subsection{Lease preparation scheduling}
|
|
179
|
|
|
180
|
Before a lease can start, it may require some preparation, such as transferring a disk image from a repository to the physical node where a VM will be running. When no preparation is necessary (e.g., assuming that all required disk images are predeployed on the physical nodes), the \texttt{lease-preparation} option must be set to \texttt{unmanaged}:
|
|
181
|
|
|
182
|
\begin{wideshellverbatim}
|
|
183
|
[general]
|
|
184
|
...
|
|
185
|
lease-preparation: unmanaged
|
|
186
|
...
|
|
187
|
\end{wideshellverbatim}
|
|
188
|
|
|
189
|
When disk images are located in a disk image repository, Haizea can schedule the file transfers from the repository to the physical nodes to make sure that images arrive on time (when a lease has to start at a specific time) and to minimise the number of transfers (by reusing images on the physical nodes). To do this, \texttt{lease-preparation} option must be set to \texttt{imagetransfer}, we need to specify the network bandwidth of the image repository (in Mbits per second), and specify several options in the \texttt{[deploy-imagetransfer]} section:
|
|
190
|
|
|
191
|
\begin{wideshellverbatim}
|
|
192
|
[general]
|
|
193
|
...
|
|
194
|
lease-preparation: imagetransfer
|
|
195
|
...
|
|
196
|
|
|
197
|
[simulation]
|
|
198
|
...
|
|
199
|
imagetransfer-bandwidth: 100
|
|
200
|
...
|
|
201
|
|
|
202
|
[deploy-imagetransfer]
|
|
203
|
...
|
|
204
|
\# Image transfer scheduling options
|
|
205
|
...
|
|
206
|
\end{wideshellverbatim}
|
|
207
|
|
|
208
|
\subsubsection{Transfer mechanisms}
|
|
209
|
|
|
210
|
The transfer mechanism specifies how the images will be transferred from the repository to the physical nodes. Haizea supports a unicast or a multicast transfer mechanism:
|
|
211
|
|
|
212
|
\begin{wideshellverbatim}
|
|
213
|
[deploy-imagetransfer]
|
|
214
|
...
|
|
215
|
transfer-mechanism: unicast | multicast
|
|
216
|
...
|
|
217
|
\end{wideshellverbatim}
|
|
218
|
|
|
219
|
Whe using a unicast transfer mechanism, one image can only be transferred to one node at a time. When using multicast, it is possible to transfer the same image from the repository node to more than one physical node at the same time.
|
|
220
|
|
|
221
|
\subsubsection{Avoiding redundant transfers}
|
|
222
|
|
|
223
|
Haizea can take steps to
|
|
224
|
detect and avoid redundant transfers (e.g., if two leases are
|
|
225
|
scheduled on the same node, and they both require the same disk
|
|
226
|
image, don't transfer the image twice; allow one to ``piggyback''
|
|
227
|
on the other). There is generally no reason to avoid redundant transfers.
|
|
228
|
|
|
229
|
\begin{wideshellverbatim}
|
|
230
|
[deploy-imagetransfer]
|
|
231
|
...
|
|
232
|
avoid-redundant-transfers: True | False
|
|
233
|
...
|
|
234
|
\end{wideshellverbatim}
|
|
235
|
|
|
236
|
|
|
237
|
\subsubsection{Disk image reuse}
|
|
238
|
|
|
239
|
Haizea can create disk image caches on the physical nodes with the goal of reusing frequent disk images and reducing the number of transfers:
|
|
240
|
|
|
241
|
\begin{wideshellverbatim}
|
|
242
|
[deploy-imagetransfer]
|
|
243
|
...
|
|
244
|
diskimage-reuse: image-caches
|
|
245
|
diskimage-cache-size: 20000
|
|
246
|
...
|
|
247
|
\end{wideshellverbatim}
|
|
248
|
|
|
249
|
|
|
250
|
\subsection{The scheduling threshold}
|
|
251
|
|
|
252
|
To avoid thrashing, Haizea will not schedule a lease unless all overheads
|
|
253
|
can be correctly scheduled (which includes image transfers, suspensions, etc.).
|
|
254
|
However, this can still result in situations where a lease is prepared,
|
|
255
|
and then immediately suspended because of a blocking lease in the future.
|
|
256
|
The scheduling threshold factor can be used to specify that a lease must
|
|
257
|
not be scheduled unless it is guaranteed to run for a minimum amount of
|
|
258
|
time (the rationale behind this is that you ideally don't want leases
|
|
259
|
to be scheduled if they're not going to be active for at least as much time
|
|
260
|
as was spent in overheads).
|
|
261
|
|
|
262
|
The default value is 1, meaning that the lease will be active for at least
|
|
263
|
as much time $t$ as was spent on overheads (e.g., if preparing the lease requires
|
|
264
|
60 seconds, and we know that it will have to be suspended, requiring 30 seconds,
|
|
265
|
Haizea won't schedule the lease unless it can run for at least 90 minutes).
|
|
266
|
In other words, a scheduling factor of $F$ required a minimum duration of
|
|
267
|
$F\cdot t$. A value of 0 could lead to thrashing, since Haizea could end up with
|
|
268
|
situations where a lease starts and immediately gets suspended.
|
|
269
|
|
|
270
|
\begin{wideshellverbatim}
|
|
271
|
[scheduling]
|
|
272
|
...
|
|
273
|
scheduling-threshold-factor: 1
|
|
274
|
...
|
|
275
|
\end{wideshellverbatim}
|
|
276
|
|
|
277
|
\section{Running multiple unattended simulations}
|
|
278
|
\label{sec:multiplesim}
|
|
279
|
Haizea's configuration file allows for, at most, one tracefile to be used. However, when running simulations, it is often necessary to run through multiple tracefiles in a variety of configurations to compare the results of each tracefile/configuration combination. The ``multi-configuration ''file allows you to easily do just this. It is similar to the regular configuration file (all the options are the same), but it allows you to specify multiple tracefiles and multiple configuration profiles.
|
|
280
|
|
|
281
|
The multi-configuration file must contain a section called "\texttt{multi}" where you must specify the following:
|
|
282
|
|
|
283
|
\begin{itemize}
|
|
284
|
\item The tracefiles you want to use
|
|
285
|
\item The "injected tracefiles" you want to use. In our own experiments, we found that it was easier to create workloads starting from a base workload and then "injecting" different types of workloads (e.g., a base workload of best-effort leases where AR leases of varying characteristics are "injected"). You can, of course, not specify any injected tracefiles.
|
|
286
|
\item The directory where Haizea should store all the information it collects during the simulation (scheduling metrics, utilization information, etc.)
|
|
287
|
\end{itemize}
|
|
288
|
|
|
289
|
The \texttt{[multi]} section should look like this:
|
|
290
|
|
|
291
|
\begin{wideshellverbatim}
|
|
292
|
[multi]
|
|
293
|
tracedir: Directory with tracefiles
|
|
294
|
tracefiles: Tracefiles to use in experiments
|
|
295
|
injectiondir: Directory with injectable tracefiles
|
|
296
|
injectionfiles: Injectable tracefiles
|
|
297
|
basedatadir: Directory where raw data will be saved
|
|
298
|
\end{wideshellverbatim}
|
|
299
|
|
|
300
|
Next, for each section you would ordinarily include in a regular configuration file, you can include common options (shared by all profiles) and profile-specific options. For example, assuming you want to specify options in the \texttt{general} and \texttt{simulation} sections, and you want to create two profiles called \texttt{nobackfilling} and \texttt{withbackfilling}, you would have to create the following sections:
|
|
301
|
|
|
302
|
\begin{wideshellverbatim}
|
|
303
|
[common:general]
|
|
304
|
...
|
|
305
|
|
|
306
|
[common:simulation]
|
|
307
|
...
|
|
308
|
|
|
309
|
[nobackfilling:general]
|
|
310
|
...
|
|
311
|
|
|
312
|
[nobackfilling:simulation]
|
|
313
|
...
|
|
314
|
|
|
315
|
[withbackfilling:general]
|
|
316
|
...
|
|
317
|
|
|
318
|
[withbackfilling:simulation]
|
|
319
|
...
|
|
320
|
\end{wideshellverbatim}
|
|
321
|
|
|
322
|
An example multi-configuration file is provided in \texttt{/usr/share/haizea/etc/sample-multi.conf}. Using this file, or once you've created your own, you can use the \texttt{haizea-generate-configs} to create the individual configuration files (one for every combination of tracefile, injected tracefile, and profile):
|
|
323
|
|
|
324
|
\begin{wideshellverbatim}
|
|
325
|
haizea-generate-configs -c config -d dir
|
|
326
|
\end{wideshellverbatim}
|
|
327
|
|
|
328
|
The \texttt{-c} parameter is used to specify the multi-config file, and the \texttt{-d} parameter is used to specify where the configuration files should be created. Since running each configuration individually would be cumbersome, you can also use the \texttt{haizea-generate-script} command to generate a script that will run through all the generated configuration files. This command requires Mako Templates for Python, so make sure you install Mako before using \texttt{haizea-generate-scripts}. Haizea currently includes two script templates: one to generate a BASH script that will call haizea with each individual configuration file, and one to generate a basic Condor submission script. For example, to generate the BASH script, you would run the command like this:
|
|
329
|
|
|
330
|
\begin{wideshellverbatim}
|
|
331
|
haizea-generate-scripts -c config -d dir -t /usr/share/haizea/etc/run.sh.template
|
|
332
|
\end{wideshellverbatim}
|