Next: 7 Other things you Up: 5 Quickstart guide Previous: 5 The scheduling options Contents
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 clock option of the [simulation] section:
[simulation] ... clock: real ...
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 haizea command:
Started Haizea daemon with pid NNNN
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 /var/tmp/haizea.log. You can take a peek at it like this:
tail /var/tmp/haizea.log
You will notice messages like this:
[2008-09-24 14:14:18.58] CLOCK Going back to sleep.
Waking up at 2008-09-24 14:15:19.00
to see if something interesting has
happened by then.
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:
[simulation] ... wakeup-interval: 10 ...
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).
So, let's give Haizea something to do. The 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:
haizea-request-lease -t +00:02:00 -d 00:10:00 -n 1 --non-preemptible \
-c 1 -m 512 -i foobar.img -z 600
Additionally, you can also write a lease request using the XML format seen previous, save it to a file, and have haizea-request-lease command parse it:
haizea-request-lease -f request.xml
You can find more details on this command's parameters by running haizea-request-lease -h or taking a look at Appendix A. Once you've submitted the lease, you should see the following:
Lease submitted correctly. Lease ID: 1
You can check the status of your submitted lease by looking at the log file or, more conveniently, using this command:
haizea-list-leases
You should see the following:
ID Type State Starting time Duration Nodes 1 AR Scheduled 2009-08-04 11:25:57.00 00:10:00.00 1
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.
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 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:
ID Type State Starting time Duration Nodes 1 AR Preparing 2009-08-04 11:25:57.00 00:10:00.00 1
And then to the ``Active'' state:
ID Type State Starting time Duration Nodes 1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1
Now let's request a best-effort lease:
haizea-request-lease -t best_effort -d 00:10:00 -n 4 --non-preemptible \
-c 1 -m 512 -i foobar.img -z 600
The list of leases will now look like this:
ID Type State Starting time Duration Nodes 1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1 2 Best-effort Scheduled Unspecified 00:10:00.00 4
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).
Now try to rerun the 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:
ID Type State Starting time Duration Nodes 1 AR Active 2009-08-04 11:25:57.00 00:10:00.00 1 2 Best-effort Scheduled Unspecified 00:10:00.00 4 3 Best-effort Queued Unspecified 00:10:00.00 4 4 Best-effort Queued Unspecified 00:10:00.00 4 5 Best-effort Queued Unspecified 00:10:00.00 4 6 Best-effort Queued Unspecified 00:10:00.00 4
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:
haizea-show-queue
This should show the following:
ID Type State Starting time Duration Nodes 3 Best-effort Queued Unspecified 00:10:00.00 4 4 Best-effort Queued Unspecified 00:10:00.00 4 5 Best-effort Queued Unspecified 00:10:00.00 4 6 Best-effort Queued Unspecified 00:10:00.00 4
When you're done, you can shut Haizea down cleanly by running the following:
haizea --stop
Borja Sotomayor 2009-12-17