|
1
|
This chapter provides a quick hands-on introduction to using Haizea in simulation mode. Even if you intend to use Haizea in combination with another system, such as OpenNebula, you may still find this guide useful to familiarise yourself with the Haizea configuration file and command-line interface. This chapter assumes that Haizea is installed on your system. If you have arrived at this chapter directly, you may want to read Chapter~\ref{chap:whatis} (``What is Haizea?'') first, although you should still be able to follow the instructions in this chapter without reading Chapter~\ref{chap:whatis} first.
|
|
2
|
|
|
3
|
\section{The \texttt{haizea} command}
|
|
4
|
|
|
5
|
The main command in the Haizea system is, unsurprisingly, the \texttt{haizea} command. Running this command starts up the Haizea lease manager, which is then ready to receive and schedule lease requests. As described in Chapter~\ref{chap:whatis}, Haizea can run in one of three modes: unattended simulated mode, interactive simulated mode, and OpenNebula mode. In this chapter we will focus on the simulation modes, starting with the ``unattended'' variety. Both simulation modes, and the OpenNebula mode, will be described in more detail in the next chapters.
|
|
6
|
|
|
7
|
When running Haizea in unattended simulation mode, the inputs to Haizea are going to be the following:
|
|
8
|
|
|
9
|
\begin{description}
|
|
10
|
\item [The Haizea configuration file:] A text file containing all the options
|
|
11
|
\item [A request \emph{tracefile}:] A text file containing a list of lease requests. Since we are using ``simulated time'', we won't be able to use Haizea interactively (we will be able to do this when we switch to the ``real time'' mode later in the chapter). Instead, we need to provide all the lease requests beforehand.
|
|
12
|
\end{description}
|
|
13
|
|
|
14
|
Based on the configuration file and the lease requests, the simulator produces a schedule for those leases, which you will be able to follow through logging messages printed by Haizea. At the end of the simulation, Haizea also saves a fair amount of raw data and statistics to disk which can be used to produce reports and graphs (a module to do this for you is in the works). This particular mode, with simulated time, is particularly useful when you want to take a list of request (potentially spanning weeks or months) to see what happens when you tweak the scheduling options (without having to wait weeks or months for the result).
|
|
15
|
|
|
16
|
So, let's start by writing a configuration file specifying the simulation options (e.g., the characteristics of the simulated cluster) and the scheduling options.
|
|
17
|
|
|
18
|
\section{The configuration file}
|
|
19
|
|
|
20
|
A sample configuration file is provided with Haizea and is located in \texttt{/usr/share/haizea/etc/sample\_trace.conf} (or \texttt{\$HOME/share/haizea/etc/sample\_trace.conf} if you installed Haizea in your home directory). For this guide, you may want to make a copy of this file and use that instead (so you can preserve the original sample file). If you look at the contents of the file, you will see that it also includes documentation on every option. For now, take a look at the following three options:
|
|
21
|
|
|
22
|
\begin{wideshellverbatim}
|
|
23
|
[simulation]
|
|
24
|
starttime: 2006-11-25 13:00:00
|
|
25
|
resources: 4 CPU:100 Memory:1024
|
|
26
|
\end{wideshellverbatim}
|
|
27
|
|
|
28
|
These options are used to describe the characteristics of our simulated cluster. In particular, we're using a 4-node cluster, each node with 1 CPU, 1024 MB of memory. In this document, we will represent this cluster over time like this:
|
|
29
|
|
|
30
|
\begin{center}
|
|
31
|
\includegraphics{images/quickstart_leasegraph1.png}
|
|
32
|
\end{center}
|
|
33
|
|
|
34
|
For example, the following figure shows a lease scheduled on Node 1 from 13:00 to 14:00:
|
|
35
|
|
|
36
|
\begin{center}
|
|
37
|
\includegraphics{images/quickstart_leasegraph2.png}
|
|
38
|
\end{center}
|
|
39
|
|
|
40
|
The \texttt{starttime} option is used to specify the time at which the simulated clock should start. As you will see, the configuration file has an abundance of other options. We will cover some of them in this chapter, but a more complete reference can be found in Appendix~\ref{app:conffile}.
|
|
41
|
|
|
42
|
\section{The tracefile}
|
|
43
|
|
|
44
|
As mentioned earlier, the simulator will read trace requests from a tracefile. The location of this tracefile is specified in the configuration file, in the \texttt{[tracefile]} section:
|
|
45
|
|
|
46
|
\begin{wideshellverbatim}
|
|
47
|
[tracefile]
|
|
48
|
tracefile: /usr/share/haizea/traces/sample.lwf
|
|
49
|
\end{wideshellverbatim}
|
|
50
|
|
|
51
|
The default value is a sample tracefile included with Haizea. If you copy the file to a different location, make sure to update the \texttt{tracefile} option accordingly. The format of this file is LWF (Lease Workload Format), an XML format which is particular to Haizea. For now, don't worry about parsing the trace format in detail; it is fairly human-readable and you can also find details on the LWF format in Appendix~\ref{app:lwf}.
|
|
52
|
|
|
53
|
\begin{wideshellverbatim}
|
|
54
|
<lease-workload name="sample">
|
|
55
|
<description>
|
|
56
|
A simple trace where an AR lease preempts a
|
|
57
|
best-effort lease that is already running.
|
|
58
|
</description>
|
|
59
|
|
|
60
|
<lease-requests>
|
|
61
|
|
|
62
|
<!-- The lease requests are initially commented out -->
|
|
63
|
|
|
64
|
<!-- First lease request -->
|
|
65
|
<!--
|
|
66
|
...
|
|
67
|
-->
|
|
68
|
|
|
69
|
<!-- Second lease request -->
|
|
70
|
<!--
|
|
71
|
...
|
|
72
|
-->
|
|
73
|
|
|
74
|
</lease-requests>
|
|
75
|
</lease-workload>
|
|
76
|
\end{wideshellverbatim}
|
|
77
|
|
|
78
|
As you can see, there are two lease requests in the file, but they are initially commented out. We will take a closer look at each of these requests next.
|
|
79
|
|
|
80
|
\section{Running the simulator}
|
|
81
|
|
|
82
|
Now that we have a configuration file and a tracefile, we can run the simulator. You can run Haizea with the sample configuration file like this:
|
|
83
|
|
|
84
|
\begin{shellverbatim}
|
|
85
|
haizea -c /usr/share/haizea/etc/sample_trace.conf
|
|
86
|
\end{shellverbatim}
|
|
87
|
|
|
88
|
Which results in the following output:
|
|
89
|
|
|
90
|
\begin{wideshellverbatim}
|
|
91
|
[2006-11-25 13:00:00.00] TFILE Loading tracefile /usr/share/haizea/traces/sample.lwf
|
|
92
|
[2006-11-25 13:00:00.00] TFILE Loaded workload with 0 requests ()
|
|
93
|
[2006-11-25 13:00:00.00] RM Starting resource manager
|
|
94
|
[2006-11-25 13:00:00.00] CLOCK Starting simulated clock
|
|
95
|
[2006-11-25 13:00:00.00] CLOCK Simulated clock has stopped
|
|
96
|
[2006-11-25 13:00:00.00] RM Stopping resource manager gracefully...
|
|
97
|
[2006-11-25 13:00:00.00] RM --- Haizea status summary ---
|
|
98
|
[2006-11-25 13:00:00.00] RM Number of leases (not including completed): 0
|
|
99
|
[2006-11-25 13:00:00.00] RM Completed leases: 0
|
|
100
|
[2006-11-25 13:00:00.00] RM Completed best-effort leases: 0
|
|
101
|
[2006-11-25 13:00:00.00] RM Queue size: 0
|
|
102
|
[2006-11-25 13:00:00.00] RM Accepted AR leases: 0
|
|
103
|
[2006-11-25 13:00:00.00] RM Rejected AR leases: 0
|
|
104
|
[2006-11-25 13:00:00.00] RM Accepted IM leases: 0
|
|
105
|
[2006-11-25 13:00:00.00] RM Rejected IM leases: 0
|
|
106
|
[2006-11-25 13:00:00.00] RM ---- End summary ----
|
|
107
|
\end{wideshellverbatim}
|
|
108
|
|
|
109
|
Now that you've seen the tracefile, you can see why the simulator starts up and immediately stops: all the lease requests in the tracefile are commented out, and there's nothing to schedule. Go ahead and uncomment the first lease request, which looks like this:
|
|
110
|
|
|
111
|
\begin{wideshellverbatim}
|
|
112
|
<lease-request arrival="00:00:00">
|
|
113
|
<lease preemptible="true">
|
|
114
|
<nodes>
|
|
115
|
<node-set numnodes="1">
|
|
116
|
<res type="CPU" amount="100"/>
|
|
117
|
<res type="Memory" amount="1024"/>
|
|
118
|
</node-set>
|
|
119
|
</nodes>
|
|
120
|
<start></start>
|
|
121
|
<duration time="01:00:00"/>
|
|
122
|
<software>
|
|
123
|
<disk-image id="foobar.img" size="1024"/>
|
|
124
|
</software>
|
|
125
|
</lease>
|
|
126
|
</lease-request>
|
|
127
|
\end{wideshellverbatim}
|
|
128
|
|
|
129
|
This is a request for a best-effort lease (notice how the starting time is left empty, meaning it's up to Haizea to determine the start time), requested at time 00:00:00 (right at the start of the simulation), requiring 1 hour, and only one node. Now run Haizea again. You should now see the following:
|
|
130
|
|
|
131
|
\begin{wideshellverbatim}
|
|
132
|
[2006-11-25 13:00:00.00] TFILE Loading tracefile /usr/share/haizea/traces/sample.lwf
|
|
133
|
[2006-11-25 13:00:00.00] TFILE Loaded workload with 1 requests (1 Best-effort)
|
|
134
|
[2006-11-25 13:00:00.00] RM Starting resource manager
|
|
135
|
[2006-11-25 13:00:00.00] CLOCK Starting simulated clock
|
|
136
|
[2006-11-25 13:00:00.00] LSCHED Lease #1 has been requested.
|
|
137
|
[2006-11-25 13:00:00.00] LSCHED Lease #1 has been marked as pending.
|
|
138
|
[2006-11-25 13:00:00.00] LSCHED Queued best-effort lease request #1, 1 nodes for 01:00:00.00.
|
|
139
|
[2006-11-25 13:00:00.00] LSCHED Next request in the queue is lease 1. Attempting to schedule...
|
|
140
|
[2006-11-25 13:00:00.00] VMSCHED Lease #1 has been scheduled on nodes [1]
|
|
141
|
from 2006-11-25 13:00:00.00
|
|
142
|
to 2006-11-25 14:00:00.00
|
|
143
|
[2006-11-25 13:00:00.00] VMSCHED Started VMs for lease 1 on nodes [1]
|
|
144
|
[2006-11-25 14:00:00.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
|
|
145
|
[2006-11-25 14:00:00.00] VMSCHED Lease 1's VMs have shutdown.
|
|
146
|
[2006-11-25 14:00:00.00] CLOCK Simulated clock has stopped
|
|
147
|
[2006-11-25 14:00:00.00] RM Stopping resource manager gracefully...
|
|
148
|
[2006-11-25 14:00:00.00] RM --- Haizea status summary ---
|
|
149
|
[2006-11-25 14:00:00.00] RM Number of leases (not including completed): 0
|
|
150
|
[2006-11-25 14:00:00.00] RM Completed leases: 1
|
|
151
|
[2006-11-25 14:00:00.00] RM Completed best-effort leases: 1
|
|
152
|
[2006-11-25 14:00:00.00] RM Queue size: 0
|
|
153
|
[2006-11-25 14:00:00.00] RM Accepted AR leases: 0
|
|
154
|
[2006-11-25 14:00:00.00] RM Rejected AR leases: 0
|
|
155
|
[2006-11-25 14:00:00.00] RM Accepted IM leases: 0
|
|
156
|
[2006-11-25 14:00:00.00] RM Rejected IM leases: 0
|
|
157
|
[2006-11-25 14:00:00.00] RM ---- End summary ----
|
|
158
|
\end{wideshellverbatim}
|
|
159
|
|
|
160
|
The above corresponds to the following schedule:
|
|
161
|
|
|
162
|
\begin{center}
|
|
163
|
\includegraphics{images/quickstart_leasegraph2.png}
|
|
164
|
\end{center}
|
|
165
|
|
|
166
|
A best-effort request is received at 13:00 and, since the cluster is empty, it is scheduled immediately. Notice how the VMs for the lease start at 13:00 and stop at 14:00. For now, we're assuming that the disk images are predeployed on the physical nodes (we will modify this option in the next section).
|
|
167
|
|
|
168
|
Now go ahead and uncomment the second lease request, which looks like this:
|
|
169
|
|
|
170
|
\begin{wideshellverbatim}
|
|
171
|
<lease-request arrival="00:15:00">
|
|
172
|
<lease preemptible="false">
|
|
173
|
<nodes>
|
|
174
|
<node-set numnodes="4">
|
|
175
|
<res type="CPU" amount="100"/>
|
|
176
|
<res type="Memory" amount="1024"/>
|
|
177
|
</node-set>
|
|
178
|
</nodes>
|
|
179
|
<start>
|
|
180
|
<exact time="00:30:00"/>
|
|
181
|
</start>
|
|
182
|
<duration time="00:30:00"/>
|
|
183
|
<software>
|
|
184
|
<disk-image id="foobar.img" size="1024"/>
|
|
185
|
</software>
|
|
186
|
</lease>
|
|
187
|
</lease-request>
|
|
188
|
\end{wideshellverbatim}
|
|
189
|
|
|
190
|
This is a request for an advance reservation lease (notice how there is an exact starting time specified), requesting all four nodes for 30 minutes. So, what would happen if we also added this AR lease? Since it requires all the cluster resources from 13:30 to 14:00, the best-effort lease will be unable to run in that time interval. Since the leases are implemented as VMs, Haizea will still schedule the best-effort lease to start at 13:00, but will suspend it before the AR lease starts, and will resume it once the AR lease has finished. In effect, we want the schedule to look like this:
|
|
191
|
|
|
192
|
\begin{center}
|
|
193
|
\includegraphics{images/quickstart_leasegraph3.png}
|
|
194
|
\end{center}
|
|
195
|
|
|
196
|
Uncomment the AR lease request, and run Haizea again. You should now see the following:
|
|
197
|
|
|
198
|
\begin{wideshellverbatim}
|
|
199
|
[2006-11-25 13:00:00.00] TFILE Loading tracefile /usr/share/haizea/traces/sample.lwf
|
|
200
|
[2006-11-25 13:00:00.00] TFILE Loaded workload with 2 requests (1 Best-effort + 1 AR)
|
|
201
|
[2006-11-25 13:00:00.00] RM Starting resource manager
|
|
202
|
[2006-11-25 13:00:00.00] CLOCK Starting simulated clock
|
|
203
|
[2006-11-25 13:00:00.00] LSCHED Lease #1 has been requested.
|
|
204
|
[2006-11-25 13:00:00.00] LSCHED Lease #1 has been marked as pending.
|
|
205
|
[2006-11-25 13:00:00.00] LSCHED Queued best-effort lease request #1, 1 nodes for 01:00:00.00.
|
|
206
|
[2006-11-25 13:00:00.00] LSCHED Next request in the queue is lease 1. Attempting to schedule...
|
|
207
|
[2006-11-25 13:00:00.00] VMSCHED Lease #1 has been scheduled on nodes [1]
|
|
208
|
from 2006-11-25 13:00:00.00
|
|
209
|
to 2006-11-25 14:00:00.00
|
|
210
|
[2006-11-25 13:00:00.00] VMSCHED Started VMs for lease 1 on nodes [1]
|
|
211
|
|
|
212
|
[2006-11-25 13:15:00.00] LSCHED Lease #2 has been requested.
|
|
213
|
[2006-11-25 13:15:00.00] LSCHED Lease #2 has been marked as pending.
|
|
214
|
[2006-11-25 13:15:00.00] LSCHED Scheduling AR lease #2, 4 nodes
|
|
215
|
from 2006-11-25 13:30:00.00
|
|
216
|
to 2006-11-25 14:00:00.00.
|
|
217
|
[2006-11-25 13:15:00.00] LSCHED Must preempt leases [1] to make room for lease #2
|
|
218
|
[2006-11-25 13:15:00.00] LSCHED Preempting lease #1...
|
|
219
|
[2006-11-25 13:15:00.00] LSCHED ... lease #1 will be suspended
|
|
220
|
at 2006-11-25 13:30:00.00.
|
|
221
|
[2006-11-25 13:15:00.00] LSCHED AR lease #2 has been scheduled.
|
|
222
|
|
|
223
|
[2006-11-25 13:29:28.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
|
|
224
|
[2006-11-25 13:29:28.00] VMSCHED Suspending lease 1...
|
|
225
|
|
|
226
|
[2006-11-25 13:30:00.00] VMSCHED Lease 1 suspended.
|
|
227
|
[2006-11-25 13:30:00.00] VMSCHED Started VMs for lease 2 on nodes [2, 3, 4, 1]
|
|
228
|
[2006-11-25 13:30:00.00] LSCHED Next request in the queue is lease 1. Attempting to schedule...
|
|
229
|
[2006-11-25 13:30:00.00] VMSCHED Lease #1 has been scheduled on nodes [1]
|
|
230
|
from 2006-11-25 14:00:00.00 (resuming)
|
|
231
|
to 2006-11-25 14:31:04.00
|
|
232
|
|
|
233
|
[2006-11-25 14:00:00.00] VMSCHED Stopped VMs for lease 2 on nodes [2, 3, 4, 1]
|
|
234
|
[2006-11-25 14:00:00.00] VMSCHED Resuming lease 1...
|
|
235
|
[2006-11-25 14:00:00.00] VMSCHED Lease 2's VMs have shutdown.
|
|
236
|
|
|
237
|
[2006-11-25 14:00:32.00] VMSCHED Resumed lease 1
|
|
238
|
[2006-11-25 14:00:32.00] VMSCHED Started VMs for lease 1 on nodes [1]
|
|
239
|
|
|
240
|
[2006-11-25 14:31:04.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
|
|
241
|
[2006-11-25 14:31:04.00] VMSCHED Lease 1's VMs have shutdown.
|
|
242
|
[2006-11-25 14:31:04.00] CLOCK Simulated clock has stopped
|
|
243
|
[2006-11-25 14:31:04.00] RM Stopping resource manager gracefully...
|
|
244
|
\end{wideshellverbatim}
|
|
245
|
|
|
246
|
Notice how the above corresponds to the previous figure. In particular, notice the following:
|
|
247
|
|
|
248
|
\begin{itemize}
|
|
249
|
\item When the AR lease request is received, Haizea looks at the schedule and determines that the only way to schedule the AR lease is to preempt the best-effort lease. However, instead of cancelling that lease, it will just reschedule it so it is suspended right before the AR lease start. Note that Haizea will always try to minimise the number of preemption (in this case, we're forcing the situation for demonstration purposes) by assigning the AR lease to resources that are available without preempting other leases.
|
|
250
|
\item Shortly before the AR lease starts, the best-effort lease is suspended (the time required to do this is estimated by Haizea based on an option in the configuration file). When the AR lease ends at 14:00, Haizea begins resuming the suspended best-effort lease.
|
|
251
|
\end{itemize}
|
|
252
|
|
|
253
|
\section{The scheduling options}
|
|
254
|
|
|
255
|
Haizea has several scheduling options that control how Haizea selects resources and schedules leases. For example, the above example assumed that leases can be suspended (which they generally always can be when running as virtual machines). What would happen if this were not possible? You can modify the suspension option in the \texttt{[scheduling]} section to find out:
|
|
256
|
|
|
257
|
\begin{wideshellverbatim}
|
|
258
|
[scheduling]
|
|
259
|
...
|
|
260
|
|
|
261
|
suspension: none
|
|
262
|
|
|
263
|
...
|
|
264
|
\end{wideshellverbatim}
|
|
265
|
|
|
266
|
Rerun Haizea. Now, when the AR lease arrives at 13:15, the scheduler will realise it has to preempt the best-effort lease to make room for the AR lease, but will no longer be able to suspend it. The only option is to cancel the best-effort lease and resubmit it to the queue:
|
|
267
|
|
|
268
|
\begin{wideshellverbatim}
|
|
269
|
[2006-11-25 13:15:00.00] LSCHED Preempting lease #1...
|
|
270
|
[2006-11-25 13:15:00.00] LSCHED ... lease #1 has been cancelled and requeued
|
|
271
|
\end{wideshellverbatim}
|
|
272
|
|
|
273
|
Now, the best-effort lease can only be scheduled after the AR lease, at 14:00:
|
|
274
|
|
|
275
|
\begin{wideshellverbatim}
|
|
276
|
[2006-11-25 13:15:00.00] VMSCHED Lease #1 has been scheduled on nodes [1]
|
|
277
|
from 2006-11-25 14:00:00.00
|
|
278
|
to 2006-11-25 15:00:00.00
|
|
279
|
\end{wideshellverbatim}
|
|
280
|
|
|
281
|
So, the schedule would end up looking like this:
|
|
282
|
|
|
283
|
\begin{center}
|
|
284
|
\includegraphics{images/quickstart_leasegraph4.png}
|
|
285
|
\end{center}
|
|
286
|
|
|
287
|
Notice how, although suspending a lease is a disruptive activity which can delay the completion time of a best-effort request, it is still much better than completely cancelling a request and waiting for enough resources to accommodate the entire (uninterrupted) duration of the lease.
|
|
288
|
|
|
289
|
Another scheduling option you can modify is whether Haizea should transfer the VM's disk image from an image repository before the lease can start. You can do this by modifying the \texttt{lease-deployment} option:
|
|
290
|
|
|
291
|
\begin{wideshellverbatim}
|
|
292
|
[general]
|
|
293
|
...
|
|
294
|
lease-preparation: imagetransfer
|
|
295
|
...
|
|
296
|
\end{wideshellverbatim}
|
|
297
|
|
|
298
|
If you look at the bottom of the sample configuration file, you will find a section called \texttt{[deploy-imagetransfer]} with all the image transfer options.
|
|
299
|
|
|
300
|
Rerun Haizea again. You should get a schedule similar to the previous one, but with some extra messages indicating that image transfers are taking place:
|
|
301
|
|
|
302
|
\begin{wideshellverbatim}
|
|
303
|
[2006-11-25 13:00:00.00] DEPLOY Starting image transfer for lease 1
|
|
304
|
[2006-11-25 13:01:22.00] DEPLOY Completed image transfer for lease 1
|
|
305
|
\end{wideshellverbatim}
|
|
306
|
|
|
307
|
As you can see, the best-effort lease can no longer start right at 13:00, since an image transfer has to take place before the starting time. The same is true of the AR lease, but notice how Haizea schedules the image transfer in such a way that the AR lease can still start at 13:30 as planned (instead of delaying the starting time until 13:31:22).
|
|
308
|
|
|
309
|
There are several other options you can modify in the \texttt{[scheduling]} section, such as what backfilling algorithm to use, whether to allow lease migration or not, etc. These options are described in the following chapters, and in Appendix~\ref{app:conffile}.
|
|
310
|
|
|
311
|
\section{Interactive simulations}
|
|
312
|
|
|
313
|
Up to this point, Haizea has been scheduling leases in ``simulated time''. This meant that we provided Haizea with a lease workload beforehand, ran it, and got the results of scheduling that workload much earlier than it would have actually taken to run the leases (e.g., if we requested a 30 minute lease, we didn't have to wait 30 minutes for the lease to complete; Haizea just skipped from the start to the end of the lease). This ``fast forward'' approach is useful if you want to experiment with different scheduling parameters and workloads. However, you can also run Haizea in simulation and in ``real time''. To do this, you need to change the \texttt{clock} option of the \texttt{[simulation]} section:
|
|
314
|
|
|
315
|
\begin{wideshellverbatim}
|
|
316
|
[simulation]
|
|
317
|
...
|
|
318
|
clock: real
|
|
319
|
...
|
|
320
|
\end{wideshellverbatim}
|
|
321
|
|
|
322
|
If you run Haizea in this mode, it will run a daemon that is ready to accept your requests interactively through a command-line interface, instead of processing a list of requests provided beforehand. You should see the following when running the \texttt{haizea} command:
|
|
323
|
|
|
324
|
\begin{wideshellverbatim}
|
|
325
|
Started Haizea daemon with pid NNNN
|
|
326
|
\end{wideshellverbatim}
|
|
327
|
|
|
328
|
You will then get control of your console back. If you're wondering where all the logging messages are being saved to, they're now being sent to a file. The default logfile is \texttt{/var/tmp/haizea.log}. You can take a peek at it like this:
|
|
329
|
|
|
330
|
\begin{shellverbatim}
|
|
331
|
tail /var/tmp/haizea.log
|
|
332
|
\end{shellverbatim}
|
|
333
|
|
|
334
|
You will notice messages like this:
|
|
335
|
|
|
336
|
\begin{wideshellverbatim}
|
|
337
|
[2008-09-24 14:14:18.58] CLOCK Going back to sleep.
|
|
338
|
Waking up at 2008-09-24 14:15:19.00
|
|
339
|
to see if something interesting has
|
|
340
|
happened by then.
|
|
341
|
\end{wideshellverbatim}
|
|
342
|
|
|
343
|
Since time is not simulated, Haizea doesn't know what the ``next time'' to skip to will be, so it will simply wake up periodically to see if anything interesting has happened (like a new request). This interval can be changed in the configuration file:
|
|
344
|
|
|
345
|
\begin{wideshellverbatim}
|
|
346
|
[simulation]
|
|
347
|
...
|
|
348
|
wakeup-interval: 10
|
|
349
|
...
|
|
350
|
\end{wideshellverbatim}
|
|
351
|
|
|
352
|
However, when Haizea plans an event (e.g., leases that have to start or end), it will wake up specifically to handle that event (instead of waiting for the wakeup interval to conclude).
|
|
353
|
|
|
354
|
So, let's give Haizea something to do. The \texttt{haizea-request-lease} command is used to request leases. For example, the following command is used to request an 1-node AR lease one minute in the future, for ten minutes:
|
|
355
|
|
|
356
|
\begin{wideshellverbatim}
|
|
357
|
haizea-request-lease -t +00:02:00 -d 00:10:00 -n 1 --non-preemptible \
|
|
358
|
-c 1 -m 512 -i foobar.img -z 600
|
|
359
|
\end{wideshellverbatim}
|
|
360
|
|
|
361
|
Additionally, you can also write a lease request using the XML format seen previous, save it to a file, and have \texttt{haizea-request-lease} command parse it:
|
|
362
|
|
|
363
|
\begin{wideshellverbatim}
|
|
364
|
haizea-request-lease -f request.xml
|
|
365
|
\end{wideshellverbatim}
|
|
366
|
|
|
367
|
You can find more details on this command's parameters by running \texttt{haizea-request-lease -h} or taking a look at Appendix~\ref{app:cli}. Once you've submitted the lease, you should see the following:
|
|
368
|
|
|
369
|
\begin{wideshellverbatim}
|
|
370
|
Lease submitted correctly.
|
|
371
|
Lease ID: 1
|
|
372
|
\end{wideshellverbatim}
|
|
373
|
|
|
374
|
You can check the status of your submitted lease by looking at the log file or, more conveniently, using this command:
|
|
375
|
|
|
376
|
\begin{shellverbatim}
|
|
377
|
haizea-list-leases
|
|
378
|
\end{shellverbatim}
|
|
379
|
|
|
380
|
You should see the following:
|
|
381
|
|
|
382
|
\begin{wideshellverbatim}
|
|
383
|
ID Type State Starting time Duration Nodes
|
|
384
|
1 AR Scheduled 2009-08-04 11:25:57.00 00:10:00.00 1
|
|
385
|
\end{wideshellverbatim}
|
|
386
|
|
|
387
|
Note: You may not see your lease right away, since Haizea has to ``become aware'' of it (which won't happen until it wakes up to check if there are any new requests). Future versions of Haizea will enable it to be notified immediately of incoming requests.
|
|
388
|
|
|
389
|
Remember that the lease has been requested one minute into the future, so it will remain in a ``Scheduled'' state for a couple seconds. If you run \texttt{haizea-list-leases} periodically, you should see it pass through a couple other states. If image transfers are still enabled, it will first transition to the ``Preparing'' state:
|
|
390
|
|
|
391
|
\begin{wideshellverbatim}
|
|
392
|
ID Type State Starting time Duration Nodes
|
|
393
|
1 AR Preparing 2009-08-04 11:25:57.00 00:10:00.00 1
|
|
394
|
\end{wideshellverbatim}
|
|
395
|
|
|
396
|
And then to the ``Active'' state:
|
|
397
|
|
|
398
|
\begin{wideshellverbatim}
|
|
399
|
ID Type State Starting time Duration Nodes
|
|
400
|
1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1
|
|
401
|
\end{wideshellverbatim}
|
|
402
|
|
|
403
|
Now let's request a best-effort lease:
|
|
404
|
|
|
405
|
\begin{wideshellverbatim}
|
|
406
|
haizea-request-lease -t best_effort -d 00:10:00 -n 4 --non-preemptible \
|
|
407
|
-c 1 -m 512 -i foobar.img -z 600
|
|
408
|
\end{wideshellverbatim}
|
|
409
|
|
|
410
|
The list of leases will now look like this:
|
|
411
|
|
|
412
|
\begin{wideshellverbatim}
|
|
413
|
ID Type State Starting time Duration Nodes
|
|
414
|
1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1
|
|
415
|
2 Best-effort Scheduled Unspecified 00:10:00.00 4
|
|
416
|
\end{wideshellverbatim}
|
|
417
|
|
|
418
|
Note how, for best-effort leases, the starting time is set to ``Unspecified'', which means this time is not specified by the user, but instead determined on a best-effort basis by the scheduler. Since the lease is in a ``Scheduled'' state, that means that it has been assigned a starting time (although that information is currently not available through the command-line interface; it can be seen in the Haizea log).
|
|
419
|
|
|
420
|
Now try to rerun the \texttt{haizea-request-lease} command a couple times (i.e., lets submit a couple more best-effort requests). The scheduler won't be able to schedule them, since they require all the available nodes, and the AR lease is using up one of them. The previous best-effort lease was scheduled because Haizea's default behaviour is to schedule at most one best-effort lease in the future if resources cannot be found right away (this is due to Haizea's use of backfilling algorithms; for now, don't worry if you don't know what they are). Anyway, the list of leases should now look like this:
|
|
421
|
|
|
422
|
\begin{wideshellverbatim}
|
|
423
|
ID Type State Starting time Duration Nodes
|
|
424
|
1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1
|
|
425
|
2 Best-effort Scheduled Unspecified 00:10:00.00 4
|
|
426
|
3 Best-effort Queued Unspecified 00:10:00.00 4
|
|
427
|
4 Best-effort Queued Unspecified 00:10:00.00 4
|
|
428
|
5 Best-effort Queued Unspecified 00:10:00.00 4
|
|
429
|
6 Best-effort Queued Unspecified 00:10:00.00 4
|
|
430
|
\end{wideshellverbatim}
|
|
431
|
|
|
432
|
Notice how the extra best-effort requests have been queued. If you only want to see the contents of the queue, you can use the following command:
|
|
433
|
|
|
434
|
\begin{shellverbatim}
|
|
435
|
haizea-show-queue
|
|
436
|
\end{shellverbatim}
|
|
437
|
|
|
438
|
This should show the following:
|
|
439
|
|
|
440
|
\begin{wideshellverbatim}
|
|
441
|
ID Type State Starting time Duration Nodes
|
|
442
|
3 Best-effort Queued Unspecified 00:10:00.00 4
|
|
443
|
4 Best-effort Queued Unspecified 00:10:00.00 4
|
|
444
|
5 Best-effort Queued Unspecified 00:10:00.00 4
|
|
445
|
6 Best-effort Queued Unspecified 00:10:00.00 4
|
|
446
|
\end{wideshellverbatim}
|
|
447
|
|
|
448
|
When you're done, you can shut Haizea down cleanly by running the following:
|
|
449
|
|
|
450
|
\begin{shellverbatim}
|
|
451
|
haizea --stop
|
|
452
|
\end{shellverbatim}
|
|
453
|
|
|
454
|
|
|
455
|
\section{Other things you can do with Haizea}
|
|
456
|
|
|
457
|
At this point, we have seen how to run simple simulations with Haizea. However, there is a lot more that Haizea can do:
|
|
458
|
|
|
459
|
\begin{description}
|
|
460
|
\item[Run on real hardware] First and foremost, almost everything you just saw above in simulation can be done on real hardware. This is accomplished by using Haizea with the OpenNebula virtual infrastructure manager. So, if you have a Xen or KVM cluster, you can just install OpenNebula and Haizea to enable your users to request VM-based leases on your cluster. This is explained in Chapter~\ref{chap:opennebula}.
|
|
461
|
\item[Run complex simulations] This chapter concerned itself mostly with scheduling two leases on a 4-node cluster during a span of roughly 2 hours. \emph{Boring}. Haizea can handle more complex simulations, and also provides the necessary tools for you to easily run multiple simulations with different profiles. For example, in the Haizea paper ``Combining Batch Execution and Leasing Using Virtual Machines'' (see the Haizea publication page: \url{http://haizea.cs.uchicago.edu/pubs.html}) we simulated running 72 30-day workloads in six different configurations, or 36 years of lease scheduling. Running multiple simulations is explained in Section~\ref{sec:multiplesim}
|
|
462
|
\item[Produce reports and graphs] The above examples relied on reading the Haizea log messages or peeking into Haizea's schedule using command-line tools. This is ok for a simple simulation, but no fun when you're scheduling thousands of leases. Haizea saves a fair amount of raw data to disk with scheduling metrics, utilization information, etc. which can be used to generate reports and graphs. We are in the process of producing tools that will allow you to easily analyse that data and create graphs, although some pointers on how to interpret the raw data produced by Haizea are presented in Chapter~\ref{chap:analysing}.
|
|
463
|
\end{description}
|