[haizea-commit] r511 - trunk/doc/manual
haizea-commit at mailman.cs.uchicago.edu
haizea-commit at mailman.cs.uchicago.edu
Wed Sep 24 13:31:55 CDT 2008
Author: borja
Date: 2008-09-24 13:31:55 -0500 (Wed, 24 Sep 2008)
New Revision: 511
Modified:
trunk/doc/manual/analysing.tex
trunk/doc/manual/install.tex
trunk/doc/manual/leases.tex
trunk/doc/manual/manual.tex
trunk/doc/manual/opennebula.tex
trunk/doc/manual/quickstart.tex
trunk/doc/manual/simulation.tex
trunk/doc/manual/title.tex
trunk/doc/manual/whatis.tex
Log:
Updates to manual for TP1.2
Modified: trunk/doc/manual/analysing.tex
===================================================================
--- trunk/doc/manual/analysing.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/analysing.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -11,7 +11,7 @@
...
\end{wideshellverbatim}
-Haizea currently includes no tools to easily convert this datafile into an easily readable format (like a graph) although these will eventually be added to Haizea. For now, if you want to access the data collected by Haizea, you will have to do so programatically. The data file contains a pickled \texttt{StatsData} object (see module \texttt{haizea.resourcemanager.stats}) with all the information collected during a simulation experiment. An example of how this file is unpickled, and some of its information accessed, can be found in function \texttt{haizea\_convert\_data} in module \texttt{haizea.cli.commands}.
+Haizea currently includes no tools to easily convert this datafile into an easily readable format (like a graph) although these will eventually be added to Haizea. For now, if you want to access the data collected by Haizea, you will have to do so programatically. The data file contains a pickled \texttt{AccountingData} object (see module \texttt{haizea.resourcemanager.accounting}) with all the information collected during a simulation experiment. An example of how this file is unpickled, and some of its information accessed, can be found in function \texttt{haizea\_convert\_data} in module \texttt{haizea.cli.commands}.
The \texttt{StatsData} object contains the following information:
@@ -29,14 +29,15 @@
\item \texttt{COUNTER\_CPUUTILIZATION}: Percentage of CPUs used in node pool.
\end{itemize}
A "counter list" (which should more appropriately be called a "metric log") includes an entry for each time a metric changes. Each entry is a tuple (time, lease\_id, value, average). If the metric is not associated with any particular lease, then the lease ID will be \texttt{None}. The average is a running average which will be \texttt{None} when it does not make sense to keep an average (e.g., the number of accepted AR requests).
-\item[Node state log] A dictionary with one entry per physical node. Each entry has a list with the state of a physical node at certain points in time. The possible states are:
-\begin{itemize}
- \item \texttt{DOING\_IDLE}: The node is idle.
- \item \texttt{DOING\_VM\_RUN}: The node is running a VM.
- \item \texttt{DOING\_VM\_SUSPEND}: The node is suspending a VM.
- \item \texttt{DOING\_VM\_RESUME}: The node is resuming a VM.
- \item \texttt{DOING\_TRANSFER\_NOVM}: The node is idle, and an image transfer is in progress.
-\end{itemize}
- This information is only useful if you have one VM per physical node. The node state log will be modified in future versions of Haizea to provide more useful utilization data for configurations that have more than one VM per physical node.
\item[Lease descriptors] The lease descriptors (i.e., \texttt{ARLease}, \texttt{BestEffortLease}, or \texttt{ImmediateLease} objects) of all the leases that have been scheduled are included in the object. The resource reservations are removed, as it would make the datafile too big. However, this still conserves interesting metrics like starting and ending times, waiting times, etc.
\end{description}
+
+\section{Analysing data from multiple simulations}
+
+When running multiple simulations (as described in \ref{sec:multiplesim}), Haizea will add information on the simulation profile to the \texttt{AccountingData} object. In particular, the profile name can be accessed through the \texttt{attrs} attribute:
+
+\begin{wideshellverbatim}
+profile = accounting_data_obj.attrs["profile"]
+\end{wideshellverbatim}
+
+In the future, it will be possible to automatically add other attributes based on the trace files and injection files used in the simulations, to facilitate analysing the different not just between simulation profiles, but also different workloads.
Modified: trunk/doc/manual/install.tex
===================================================================
--- trunk/doc/manual/install.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/install.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -1,4 +1,4 @@
-Haizea has been tested only on Unix systems, and these installation instructions are given with a Unix system in mind. However, Haizea includes no platform-specific code, and should run fine on other systems. If there is enough interest, we can produce installers and installation instructions for other platforms.
+Haizea has been tested only on Unix systems, and these installation instructions are given with a Unix system in mind. However, Haizea includes a small amount of platform-specific code, and should run fine on other systems with minimal effort. If there is enough interest, we can produce installers and installation instructions for other platforms.
Installing Haizea can be accomplished in four simple steps:
@@ -55,7 +55,7 @@
copying traces/multi/withprematureend.lwf -> /usr/share/haizea/traces/multi
copying traces/multi/withoutprematureend.lwf -> /usr/share/haizea/traces/multi
running install_egg_info
-Writing /usr/lib/python2.5/site-packages/haizea-TP1.XXX.egg-info
+Writing /usr/lib/python2.5/site-packages/haizea-XXX.egg-info
\end{wideshellverbatim}
If you see this, installation has been successful!
@@ -72,7 +72,7 @@
\begin{wideshellverbatim}
[2006-11-25 13:00:00.00] TFILE Loading tracefile /usr/share/haizea/traces/sample.lwf
-[2006-11-25 13:00:00.00] TRACE Loaded workload with 0 requests (0 best-effort + 0 AR)
+[2006-11-25 13:00:00.00] TFILE Loaded workload with 0 requests (0 best-effort + 0 AR)
[2006-11-25 13:00:00.00] RM Starting resource manager
[2006-11-25 13:00:00.00] CLOCK Starting simulated clock
[2006-11-25 13:00:00.00] CLOCK Stopping simulated clock
@@ -82,7 +82,7 @@
[2006-11-25 13:00:00.00] RM Rejected AR leases: 0
\end{wideshellverbatim}
-Ok, not terribly exciting, but if you see this then the basic machinery is working fine. To see how to do more elaborate simulations, take a look at the Quickstart Guide.
+Ok, not terribly exciting, but if you see this then the basic machinery is working fine. We will see how to do more elaborate simulations, and how to use Haizea to manage real hardware, in the next chapters.
Note: If you installed Haizea in your home directory, you will have to run the following:
Modified: trunk/doc/manual/leases.tex
===================================================================
--- trunk/doc/manual/leases.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/leases.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -1,3 +1,37 @@
+
+Let's say you need computational resources...
+
+Maybe you're a scientist who needs to run some simulations. You have specific hardware requirements, but you're not particularly picky about when the simulations run, and probably won't even notice if they are interrupted at some point, as long as they finish running (correctly) at some point, maybe before a given deadline. A job scheduler, and a compute cluster, would probably be a good fit for you.
+
+You could also be a software developer who wants to test his or her code on a pristine machine, which you would only need for a relatively short period of time. Plus, every time you use this machine, you'd like it to start up with the exact same pristine software environment. Oh, and you want your machine now. As in right now. One option could be to install a virtual machine (VM) manager (such as Xen, VMWare, etc.) to start up these pristine machines as VMs on your own machine. Even better, you could go to a cloud (like Amazon EC2 or the Science Clouds) and have those VMs appear automagically somewhere else, so you don't have to worry about setting up the VM manager or having a machine powerful enough to run those VMs.
+
+Or perhaps you're a run-of-the-mill geek who wants his or her own web/mail/DNS/etc server. This server will presumably be running for months or even years with high availability: your server has to be running all the time, with no interruptions. There's a whole slew of hosting providers who can give you a dedicated server or a virtual private server. The latter are typically managed with VM-based datacenter managers.
+
+As you can see, there are a lot of resource provisioning scenarios in nature. However, the solutions that have emerged tend to be specific to a particular scenario, to the exclusion of other ones. For example, while job-based systems are exceptionally good at managing complex batch workloads, they're not too good at provisioning resources at specific times (some job-based systems do offer advance reservations, but they have well-known utilization problems) or at giving users unfettered access to provisioned resources (forcing them, instead, to interact with the resources through the job abstraction).
+
+A lease is a general resource provisioning abstraction that could be used to satisfy a variety of use cases, such as the ones described above. In our work, we've defined a lease as "a negotiated and renegotiable agreement between a resource provider and a resource consumer, where the former agrees to make a set of resource available to the latter, based on a set of lease terms presented by the resource consumer". In our view, the lease terms must include the following dimensions:
+
+\begin{description}
+ \item[Hardware] The hardware resources (CPU, memory, etc.) required by the resource consumer.
+ \item[Software] The software environment that must be installed in those resources.
+ \item[Availability] The period during which the hardware and software resources must be available. It is important to note that the availability period can be specified in a variety of ways, like "just get this to me as soon as you can", "I need this from 2pm to 4pm on Mondays, Wednesdays, and Fridays (and, if I don't get exactly this, I will be a very unhappy resource consumer)", or even "I need four hours sometime before 5pm tomorrow, although if you get the resources to me right now I'll settle for just two hours". A lease-based system must be able to efficiently combine all these different types of availability.
+\end{description}
+
+Furthermore, if you don't get any of these dimensions, then you're being shortchanged by your resource lessor. For example, Amazon EC2 is very good at providing exactly the software environment you want, and reasonably good at providing the hardware you want (although you're limited to a few hardware configurations), but not so good at supporting a variety of availability periods.
+
+So, Haizea aims to support resource leasing along these three dimension. For now, Haizea supports three types of availability:
+
+\begin{description}
+\item[Best-effort lease] Resources are provisioned as soon as they are available.
+\item[Advance reservation-style leases (or "AR leases")] Resources are provisioned during a strictly defined time period (e.g., from 2pm to 4pm).
+\item[Immediate leases] Resources must be provisioned right now, or not at all.
+\end{description}
+
+Although there are many systems (particularly job-based systems) that support these two types availability, Haizea differs in that it efficiently schedules heterogeneous workloads (combining best-effort and AR leases), overcoming the utilization problems typically resulting from using ARs. Haizea does this by using virtual machines to implement leases. Virtual machines also enable Haizea to provide exactly the hardware and software requested by the user. Additionally, Haizea also manages the overhead of preparing a lease, to make sure that any deployment operations (such as transferring a VM disk image) are taken care of before the start of a lease, instead of being deducted from the lessee's allocation.
+
+In the future, Haizea will support additional lease types, such as urgent leases, periodic leases, deadline-driven leases, etc.
+
+
Haizea supports a variety of resource leases. There's a more detailed description of what a lease is in the What is Haizea? page, and this page just describes the supported types of leases. Throughout this page, let's assume you have a 4-node cluster, and that you want to lease parts of that cluster over time. We'll represent the four nodes over time like this:
\section{"Advance Reservation" lease}
Modified: trunk/doc/manual/manual.tex
===================================================================
--- trunk/doc/manual/manual.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/manual.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -6,6 +6,7 @@
\usepackage{fullpage}
\include{utils}
+\setcounter{tocdepth}{1}
\begin{document}
\frontmatter
@@ -19,7 +20,6 @@
\maketitle
\end{htmlonly}
-
\tableofcontents
\chapter{Preface}
@@ -30,23 +30,22 @@
\part{Fundamental Concepts}
\chapter{What is Haizea?}
+\label{chap:whatis}
\input{whatis}
\chapter{Resource leases}
-
+\label{chap:leases}
\input{leases}
\part{Using Haizea}
-Foobar foobaz
-
\chapter{Installing Haizea}
\input{install}
\chapter{Quickstart guide}
-
+\label{chap:quickstart}
\input{quickstart}
\chapter{Running scheduling simulations}
@@ -54,11 +53,11 @@
\input{simulation}
\chapter{Haizea and OpenNebula}
-
+\label{chap:opennebula}
\input{opennebula}
\chapter{Analysing scheduling data}
-
+\label{chap:analysing}
\input{analysing}
@@ -76,14 +75,15 @@
\appendix
\chapter{Command-line interface reference}
-
+\label{app:cli}
\input{appendix_cli}
\chapter{Configuration file reference}
-
+\label{app:conffile}
\input{appendix_conf}
\chapter{LWF file format}
+\label{app:lwf}
+\input{appendix_lwf}
-
\end{document}
Modified: trunk/doc/manual/opennebula.tex
===================================================================
--- trunk/doc/manual/opennebula.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/opennebula.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -1,25 +1,21 @@
-OpenNebula is a virtual infrastructure manager that enables the dynamic deployment and re-allocation of virtual machines on a pool of physical resources. Haizea can be used to extend OpenNebula's scheduling capabilities, allowing it to support advance reservation of resources and queuing of best effort requests (more generally, it allows you to lease your resources as VMs, with a variety of lease terms). OpenNebula and Haizea complement each other, since OpenNebula provides all the enactment muscle (OpenNebula can manage Xen and KVM VMs on a cluster, with VMWare support to follow shortly) and Haizea provides the scheduling brains. Using them together is very simple since Haizea can be installed as a drop-in replacement for OpenNebula's scheduling daemon (i.e., you can use the latest version of OpenNebula, without any modifications).
+OpenNebula (\url{http://www.opennebula.org/}) is a virtual infrastructure manager that enables the dynamic deployment and re-allocation of virtual machines on a pool of physical resources. Haizea can be used to extend OpenNebula's scheduling capabilities, allowing it to support advance reservation of resources and queuing of best effort requests. OpenNebula and Haizea complement each other, since OpenNebula provides all the enactment muscle (OpenNebula can manage Xen and KVM VMs on a cluster, with VMWare support to follow shortly) and Haizea provides the scheduling brains. Using both of them together is simple, since Haizea acts as a drop-in replacement for OpenNebula's scheduling daemon.
-This document explains how to use OpenNebula and Haizea together, and explains how to submit requests to OpenNebula to use Haizea's scheduling capabilities.
+This chapter explains how to use OpenNebula and Haizea together, and explains how to submit requests to OpenNebula to use Haizea's scheduling capabilities.
-NOTE: Although Haizea supports scheduling multiple VMs in parallel (e.g., 16 VMs which must run at the same time, or not at all), the current 1.0 version of OpenNebula only allows VMs to be managed one at a time (OpenNebula 1.2 will include support for "VM groups"). As such, this document only explains how to schedule individual VMs. There is a "dirty hack" way of scheduling groups of VMs with Haizea and OpenNebula 1.0, but we're not including it here since OpenNebula 1.2 will make this issue moot. However, if you really really really need to schedule VMs as groups and can't wait for OpenNebula 1.2, please don't hesitate to contact us.
-
\begin{warning}
Please remember that, although we have tested Haizea considerably with OpenNebula 1.0, Haizea is still a technology preview and, thus, not a good choice for production environments (yet). There are a couple of known issues and limitations which are listed at the end of this document. If you need to use OpenNebula in a production environment, and don't need any of Haizea's scheduling features (advance reservations, queuing of requests, etc.), you may want to use OpenNebula's default scheduler instead.
\end{warning}
\section{Installing OpenNebula and Haizea}
-If you have not already done so, you will need to install OpenNebula 1.0 and Haizea Technology Preview 1.1. Start by installing OpenNebula, and then installing Haizea.
+If you have not already done so, you will need to install OpenNebula 1.0 and the latest version of Haizea. Start by installing OpenNebula, and then installing Haizea.
-Before proceeding, you may want to follow the OpenNebula quickstart guide to verify that your OpenNebula installation is working fine. The rest of this document assumes that OpenNebula is correctly installed, and that you know what a virtual machine template is ("VM templates" is how VMs are requested to OpenNebula, so we'll be working with them quite a bit). You may also want to follow the Haizea Quickstart Guide, to verify that Haizea is correctly installed.
+Before proceeding, you may want to follow the OpenNebula quickstart guide (\url{http://www.opennebula.org/doku.php?id=documentation:rel1.0:qg}) to verify that your OpenNebula installation is working fine. The rest of this document assumes that OpenNebula is correctly installed, and that you know what a \emph{virtual machine template} is (``VM templates'' is how VMs are requested to OpenNebula, so we'll be working with them quite a bit). You may also want to follow the Haizea Quickstart Guide (see Chapter~\ref{chap:quickstart}, to verify that Haizea is correctly installed.
\section{Configuring Haizea}
-Haizea must be configured to run in OpenNebula mode. Haizea includes a sample OpenNebula configuration file that you can use as a starting point. This file is installed, by default, in \texttt{/usr/share/haizea/etc/sample\_opennebula.conf}.
+Haizea must be configured to run in OpenNebula mode. Haizea includes a sample OpenNebula configuration file that you can use as a starting point. This file is installed, by default, in \texttt{/usr/share/haizea/etc/sample\_opennebula.conf}. In OpenNebula mode, Haizea will process requests coming from OpenNebula, and will send all enactment commands to OpenNebula. To activate this mode, the \texttt{mode} option of the \texttt{general} section in the Haizea configuration file must be set to \texttt{opennebula}:
-In OpenNebula mode, Haizea will process requests coming from OpenNebula, and will send all enactment commands to OpenNebula. To activate this mode, the \texttt{mode} option of the \texttt{general} section in the Haizea configuration file must be set to \texttt{opennebula}:
-
\begin{wideshellverbatim}
[general]
...
@@ -38,7 +34,7 @@
onevm: /opt/nebula/ONE/bin/onevm
\end{wideshellverbatim}
-There are some additional options described at the end of this document, but which you do not need to concern yourself with yet.
+There are some additional options described at the end of this chapter, but which you do not need to concern yourself with yet.
\section{Running OpenNebula and Haizea together}
@@ -54,10 +50,10 @@
haizea -c /usr/share/haizea/etc/sample_opennebula.conf
\end{wideshellverbatim}
-Haizea currently always runs in the foreground (a daemon mode will be added in future versions). If you want Haizea to run in the background, you can run it like this:
+By default, Haizea runs as a daemon when running in OpenNebula mode. For this chapter, you may want to run it in the foreground so you can see the Haizea log messages in your console:
\begin{wideshellverbatim}
-nohup haizea -c /usr/share/haizea/etc/sample_opennebula.conf 2> /var/tmp/haizea.log &
+haizea --fg -c /usr/share/haizea/etc/sample_opennebula.conf
\end{wideshellverbatim}
When Haizea starts up, it will print out something like this:
@@ -88,7 +84,7 @@
]
\end{wideshellverbatim}
-The exact meaning of these parameters is explained later on in this document. In a nutshell, the values specified above tell Haizea to schedule the VM to start exactly 30 seconds in the future, to run for one minute, and to not allow the allocated resources to be preempted by other requests. As we will see later on, this is called an "advance reservation" (or AR) request.
+The exact meaning of these parameters is explained later on in this document. In a nutshell, the values specified above tell Haizea to schedule the VM to start exactly 30 seconds in the future, to run for one minute, and to not allow the allocated resources to be preempted by other requests. This corresponds to an Haizea \emph{advance reservation lease} (see Chapter~\ref{chap:leases}).
Before you submit your request to OpenNebula, take a look at the Haizea log. You should see something like this repeating every minute:
@@ -131,7 +127,7 @@
Notice how Haizea detected that OpenNebula had an AR request, and then scheduled it to start 30 seconds in the future. In fact, Haizea takes care to wake up at that time so the VM can start at exactly that time.
\begin{warning}
-If you run \texttt{onevm list}, the request will still be shown as \texttt{pending}. OpenNebula doesn't track Haizea's internal states, so it will consider the request "pending" until Haizea starts up the VM. Future versions will provide more information on a VMs state.
+If you run \texttt{onevm list}, the request will still be shown as \texttt{pending}. OpenNebula doesn't track Haizea's internal states, so it will consider the request "pending" until Haizea starts up the VM. You can check the state of Haizea leases using the \texttt{haizea-list-leases} command.
\end{warning}
\begin{warning}
@@ -186,6 +182,7 @@
\item ISO-formatted time: i.e., \texttt{HH:MM:SS}
\end{itemize}
\item \texttt{preemptible}: This option can be either yes or no. Haizea currently uses a very simple priority scheme where VMs are either preemptible or non-preemptible (furthermore, a non-preemptible VM can preempt preemptible VMs, while preemptible VMs can't preempt anything). If a VM is preemptible, and a preempting VM needs its resources, then the preemptible VM will be suspended while the preempting VM is running. Future versions of Haizea will include better priority schemes.
+\item \texttt{group}: This option can take on any string value, and allows you to schedule several VMs as a group (or, in Haizea terminology, as a single lease with multiple nodes). All OpenNebula VM templates with the same group name will be considered part of the same lease (i.e., all the VMs will be scheduled in a all-or-nothing fashion: all VMs must be able to start/stop at the same time). Future versions of OpenNebula will automatically manage this option, so users don't have to worry about manually setting this option in multiple VM templates (which can be error-prone).
\end{itemize}
Usually, you will want to use these options to create one of Haizea's supported lease types:
@@ -216,7 +213,7 @@
\subsection{Best-effort provisioning}
-When you instruct Haizea to determine the start time on a best-effort basis, your request will be allocated resources as soon as they become available. Take into account that your request may be placed on a queue, and you'll have to wait until your turn is up (there is currently no way to query the state of the queue, although this functionality will be added soon).
+When you instruct Haizea to determine the start time on a best-effort basis, your request will be allocated resources as soon as they become available. Take into account that your request may be placed on a queue, and you'll have to wait until your turn is up. You can use the \texttt{haizea-list-leases} and \texttt{haizea-show-queue} to check on the state of your lease.
\begin{wideshellverbatim}
HAIZEA = [
@@ -257,7 +254,7 @@
\subsection{Suspend/resume rate interval}
-This option provides Haizea with an estimate of how long it takes for OpenNebula to suspend or resume a virtual machine. This is estimated in MB per second, and is largely dependent on the disk read/write transfer speeds on your system (so, if a VM has 1024 MB of memory, and the suspend rate is estimated to be 64MB/s, Haizea will estimate that suspension will take 16 seconds). If you do not specify a value, Haizea will conservatively assume a rate of 32MB/s. A good estimate will allow Haizea to more correctly schedule resources, but an incorrect estimation will not result in an error (although a warning will be noted in the logs).
+This option provides Haizea with an estimate of how long it takes for OpenNebula to suspend or resume a virtual machine. This is estimated in MB per second, and is largely dependent on the disk read/write transfer speeds on your system (so, if a VM has 1024 MB of memory, and the suspend rate is estimated to be 64MB/s, Haizea will estimate that suspension will take 16 seconds). If you do not specify a value, Haizea will conservatively assume a rate of 32MB/s. A good estimate will allow Haizea to more correctly schedule resources, but an incorrect estimate will not result in an error (although a warning will be noted in the logs).
\begin{wideshellverbatim}
[opennebula]
@@ -266,6 +263,17 @@
...
\end{wideshellverbatim}
+Additionally, since OpenNebula currently only supports suspending to a global filesystem (i.e., the RAM file created when suspending a VM is saved to a global filesystem, such as an NFS drive), you will need to specify that suspensions and resumptions must be globally exclusive (to make sure that no more than one RAM file is being saved to the global filesystem at any one time). You can control this using the \texttt{suspendresume-exclusion} option in the \texttt{[scheduling]} section:
+
+\begin{wideshellverbatim}
+[scheduling]
+...
+suspendresume-exclusion: global
+...
+\end{wideshellverbatim}
+
+This option is set to \texttt{global} in the sample OpenNebula configuration file, but defaults to \texttt{local} when not specified.
+
\subsection{Non-schedulable interval}
The minimum amount of time that must pass between when a request is scheduled to when it can actually start (i.e., this makes sure that the scheduling function doesn't make reservations with starting times that will be in the past by the time the scheduling function ends). The default (10 seconds) should be good for most configurations, but may need to be increased if you're dealing with exceptionally high loads.
@@ -279,11 +287,11 @@
\section{Known issues and limitations}
-Known issues and limitations when using Haizea with OpenNebula:
+The following are known issues and limitations when using Haizea with OpenNebula:
\begin{itemize}
\item As pointed out in this guide, Haizea has to poll OpenNebula every minute to ask if there are any new requests. Additionally, OpenNebula has no way of notifying Haizea of a change of state in a VM (e.g., a VM that died, a suspend operation that finished before expected, etc.). An upcoming version of OpenNebula will add this feature, and Haizea (in turn) will support receiving events from OpenNebula (this includes being instantly notified of new requests, instead of having to poll OpenNebula periodically).
-\item If a command sent to OpenNebula fails, Haizea currently ignores this. This will be fixed in Haizea TP 1.3. Nonetheless, OpenNebula commands run from Haizea shouldn't fail unless you're running incredibly heavy loads, or if you manually shutdown a VM managed by Haizea.
+\item If a command sent to OpenNebula fails, Haizea currently ignores this. Nonetheless, OpenNebula commands run from Haizea shouldn't fail unless you're running incredibly heavy loads, or if you manually shutdown a VM managed by Haizea.
\item Haizea currently cannot do any image deployment with OpenNebula, and VM images are assumed to be predeployed on the physical nodes, or available on a shared NFS filesystem. An upcoming version of OpenNebula will allow OpenNebula and Haizea to work with a \emph{transfer manager} to handle various VM deployment scenarios.
\item Haizea cannot enact cold migrations in OpenNebula (i.e., migrating a suspended VM to a different node if resources become available earlier on a different node than the one where the VM was suspended on). Haizea actually has all the scheduling code for this, and only the enactment "glue" is missing (should be added in TP 1.3 or 1.4)
\end{itemize}
\ No newline at end of file
Modified: trunk/doc/manual/quickstart.tex
===================================================================
--- trunk/doc/manual/quickstart.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/quickstart.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -1,16 +1,23 @@
-This guide provides an 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 familiarize yourself with the Haizea configuration file and command-line interface. This guide assumes that you've downloaded and installed Haizea. Also, make sure you've read the What is Haizea? page before following this guide.
+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 familiarize 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.
\section{The \texttt{haizea} command}
-The main command in the Haizea system is, unsurprisingly, the haizea command. Running this command starts up the Haizea lease manager, which is then ready to receive and schedule lease requests. When running Haizea in simulation mode, lease requests are read from a tracefile, a text file containing a list of lease requests. Based on these requests, the simulator produces a schedule for those leases, which you will be able to follow through the 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).
+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: Simulation mode with simulated time, Simulation mode with real time, and OpenNebula mode. In this chapter we will focus on the simulation modes, starting with the ``simulated time'' variety. Both simulation modes, and the OpenNebula mode, will be described in more detail in the next chapters.
-When not running in simulation, Haizea runs as a daemon that can accept requests (e.g., through a command-line interface) and sends out enactment commands ("start VM", "stop VM", etc.) to the appropriate enactment module. For example, when running OpenNebula with Haizea as a scheduling backend, Haizea is in charge of processing the requests received by OpenNebula, coming up with a schedule, and then instructing OpenNebula on when VMs should be start/stop/suspend/resume on what physical nodes. A document describing how to use Haizea with OpenNebula will be available soon.
+When running Haizea in simulation mode with simulated time, the inputs to Haizea are going to be the following:
-But, anyway, back to how to run Haizea in simulation. The first thing we need to do is to write a configuration file specifying simulation options (e.g., the characteristics of the simulated cluster) and scheduling options.
+\begin{description}
+ \item [The Haizea configuration file:] A text file containing all the options
+ \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.
+\end{description}
+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).
+
+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.
+
\section{The configuration file}
-A sample configuration file is provided with Haizea and is located in /usr/share/haizea/etc/sample.conf (or \$HOME/share/haizea/etc/sample.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:
+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:
\begin{wideshellverbatim}
[simulation]
@@ -31,7 +38,7 @@
\includegraphics{images/quickstart_leasegraph2.png}
\end{center}
-The 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 explain some of them in this document.
+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}.
\section{The tracefile}
@@ -42,7 +49,7 @@
tracefile: /usr/share/haizea/traces/sample.lwf
\end{wideshellverbatim}
-The default value is a sample tracefile included with Haizea. If you copy the file to a different location, make sure to update the tracefile option accordingly. The format of this file is LWF (Lease Workload Format), which is particular to Haizea. The sample file includes documentation on the file format, and several sample workloads. For now, we will focus on the first workload, "PREEMPT":
+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), which is particular to Haizea. The sample file includes documentation on the file format, and several sample workloads. You can also find details on the LWF format in Appendix~\ref{app:lwf}. For now, we will focus on the first workload, "PREEMPT":
\begin{wideshellverbatim}
# 0 -1 3600 3600 1 1 1024 0 foobar.img 1024
@@ -60,7 +67,7 @@
\section{Running the simulator}
-Now that we have a configuration file and a tracefile, we can run the simulator. As shown in the installation guide, you can run Haizea with the sample configuration file like this:
+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:
\begin{shellverbatim}
haizea -c /usr/share/haizea/etc/sample.conf
@@ -91,7 +98,7 @@
1 nodes for 01:00:00.00.
[2006-11-25 13:00:00.00] SCHED Next request in the queue is lease 1.
Attempting to schedule...
-[2006-11-25 13:00:00.00] SLOT Lease #1 has been scheduled on nodes [1]
+[2006-11-25 13:00:00.00] SCHED Lease #1 has been scheduled on nodes [1]
from 2006-11-25 13:00:00.00
to 2006-11-25 14:00:00.00
[2006-11-25 13:00:00.00] SCHED Started VMs for lease 1 on nodes [1]
@@ -111,13 +118,13 @@
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).
-So, what would happen if we also added the 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 one the AR lease has finished. In effect, we want the schedule to look like this:
+So, what would happen if we also added the 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:
\begin{center}
\includegraphics{images/quickstart_leasegraph3.png}
\end{center}
-Uncomment the AR lease request, and run Haizea again. You should now see the following (for clarity, log messages pertaining to the best-effort lease are highlighted in green, and those pertaining to the AR lease are highlighted in brown):
+Uncomment the AR lease request, and run Haizea again. You should now see the following:
\begin{wideshellverbatim}
[2006-11-25 13:00:00.00] TRACE Loading tracefile /usr/share/haizea/traces/sample.lwf
@@ -128,7 +135,7 @@
1 nodes for 01:00:00.00.
[2006-11-25 13:00:00.00] SCHED Next request in the queue is lease 1.
Attempting to schedule...
-[2006-11-25 13:00:00.00] SLOT Lease #1 has been scheduled on nodes [1]
+[2006-11-25 13:00:00.00] SCHED Lease #1 has been scheduled on nodes [1]
from 2006-11-25 13:00:00.00
to 2006-11-25 14:00:00.00
[2006-11-25 13:00:00.00] SCHED Started VMs for lease 1 on nodes [1]
@@ -176,21 +183,22 @@
\section{The scheduling options}
-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 [scheduling] section to find out:
+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:
+\begin{wideshellverbatim}
[scheduling]
...
suspension: none
...
+\end{wideshellverbatim}
Rerun Haizea. Now, when the AR lease arrives at 13:15, the scheduler will realize 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:
\begin{wideshellverbatim}
[2006-11-25 13:15:00.00] SCHED Preempting lease #1...
[2006-11-25 13:15:00.00] SCHED ... lease #1 has been cancelled and requeued
- (cannot be suspended)
\end{wideshellverbatim}
Now, the best-effort lease can only be scheduled after the AR lease, at 14:00:
@@ -209,7 +217,7 @@
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 canceling a request and waiting for enough resources to accommodate the entire (uninterrupted) duration of the lease.
-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 lease-deployment option:
+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:
\begin{wideshellverbatim}
[general]
@@ -222,18 +230,160 @@
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:
+\begin{wideshellverbatim}
[2006-11-25 13:00:00.00] SCHED Starting image transfer for lease 1
[2006-11-25 13:01:22.00] SCHED Completed image transfer for lease 1
+\end{wideshellverbatim}
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).
-There are several other options you can modify in the [scheduling] section, such as what backfilling algorithm to use, whether to allow lease migration or not, etc. See the description of these option in the sample configuration file for more details.
-Other things you can do with Haizea
+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}.
-At this point, you can run simple simulations with Haizea. However, there is a lot more that you can do with Haizea:
+\section{Interactive simulations}
-\begin{itemize}
-\item Run on real hardware: First and foremost, 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.
-\item Run complex simulations: The above shows only two leases on a 4-node cluster during a span of roughly 2 hours. 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 we simulated running 72 30-day workloads in six different configurations, or 36 years of lease scheduling. To set up this kind of simulations, take a look at the Running Multiple Simulation Experiments with Haizea document.
-\item Produce reports and graphs: The above examples relied on you reading the Haizea log messages, which 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.
-\end{itemize}
\ No newline at end of file
+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:
+
+\begin{wideshellverbatim}
+[simulation]
+...
+clock: real
+...
+\end{wideshellverbatim}
+
+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:
+
+\begin{wideshellverbatim}
+Started Haizea daemon with pid NNNN
+\end{wideshellverbatim}
+
+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:
+
+\begin{shellverbatim}
+tail /var/tmp/haizea.log
+\end{shellverbatim}
+
+You will notice messages like this:
+
+\begin{wideshellverbatim}
+[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.
+\end{wideshellverbatim}
+
+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:
+
+\begin{wideshellverbatim}
+[simulation]
+...
+wakeup-interval: 10
+...
+\end{wideshellverbatim}
+
+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 \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:
+
+\begin{wideshellverbatim}
+haizea-request-lease -t +00:01:00 -d 00:10:00 -n 1 --non-preemptible \
+ -c 1 -m 512 -i foobar.img -z 600
+\end{wideshellverbatim}
+
+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:
+
+\begin{wideshellverbatim}
+Lease submitted correctly.
+Lease ID: 1
+\end{wideshellverbatim}
+
+You can check the status of your submitted lease by looking at the log file or, more conveniently, using this command:
+
+\begin{shellverbatim}
+haizea-list-leases
+\end{shellverbatim}
+
+You should see the following:
+
+\begin{wideshellverbatim}
+ ID Type State Starting time Duration Nodes
+ 1 AR Scheduled 2008-09-24 14:24:47.00 00:10:00.00 1
+\end{wideshellverbatim}
+
+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 \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:
+
+\begin{wideshellverbatim}
+ ID Type State Starting time Duration Nodes
+ 1 AR Preparing 2008-09-24 14:24:47.00 00:10:00.00 1
+\end{wideshellverbatim}
+
+And then to the ``Active'' state:
+
+\begin{wideshellverbatim}
+ ID Type State Starting time Duration Nodes
+ 1 AR Active 2008-09-24 14:24:47.00 00:10:00.00 1
+\end{wideshellverbatim}
+
+Now let's request a best-effort lease:
+
+\begin{wideshellverbatim}
+haizea-request-lease -t best_effort -d 00:10:00 -n 4 --non-preemptible -c 1 -m 512 -i foobar.img -z 600
+\end{wideshellverbatim}
+
+The list of leases will now look like this:
+
+\begin{wideshellverbatim}
+ ID Type State Starting time Duration Nodes
+ 1 AR Active 2008-09-24 14:24:47.00 00:10:00.00 1
+ 2 BE Scheduled None 00:10:00.00 4
+\end{wideshellverbatim}
+
+Note how, for best-effort leases, the starting time is set to ``None'', 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 \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:
+
+\begin{wideshellverbatim}
+ ID Type State Starting time Duration Nodes
+ 1 AR Active 2008-09-24 14:24:47.00 00:10:00.00 1
+ 2 BE Scheduled None 00:10:00.00 4
+ 3 BE Queued None 00:10:00.00 4
+ 4 BE Queued None 00:10:00.00 4
+ 5 BE Queued None 00:10:00.00 4
+ 6 BE Queued None 00:10:00.00 4
+\end{wideshellverbatim}
+
+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:
+
+\begin{shellverbatim}
+haizea-show-queue
+\end{shellverbatim}
+
+This should show the following:
+
+\begin{wideshellverbatim}
+ ID Type State Sched. Start time Duration Nodes
+ 3 BE Queued None 00:10:00.00 4
+ 4 BE Queued None 00:10:00.00 4
+ 5 BE Queued None 00:10:00.00 4
+ 6 BE Queued None 00:10:00.00 4
+\end{wideshellverbatim}
+
+When you're done, you can shut Haizea down cleanly by running the following:
+
+\begin{shellverbatim}
+haizea --stop
+\end{shellverbatim}
+
+
+\section{Other things you can do with Haizea}
+
+At this point, we have seen how to run simple simulations with Haizea. However, there is a lot more that Haizea can do:
+
+When not running in simulation, Haizea runs as a daemon that can accept requests (e.g., through a command-line interface) and sends out enactment commands ("start VM", "stop VM", etc.) to the appropriate enactment module. For example, when running OpenNebula with Haizea as a scheduling backend, Haizea is in charge of processing the requests received by OpenNebula, coming up with a schedule, and then instructing OpenNebula on when VMs should be start/stop/suspend/resume on what physical nodes.
+
+\begin{description}
+\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}.
+\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}
+\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}.
+\end{description}
\ No newline at end of file
Modified: trunk/doc/manual/simulation.tex
===================================================================
--- trunk/doc/manual/simulation.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/simulation.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -6,7 +6,7 @@
\section{Scheduling options}
\section{Running multiple unattended simulations}
-
+\label{sec:multiplesim}
Haizea's regular configuration file (the one that is provided to the haizea command) 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.
The multi-configuration file must contain a section called "\texttt{multi}" where you must specify the following:
Modified: trunk/doc/manual/title.tex
===================================================================
--- trunk/doc/manual/title.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/title.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -7,7 +7,7 @@
% Title
\HRule \\[0.4cm]
\includegraphics[width=0.6\textwidth]{images/haizea.png}\\[1cm]
-\textsc{ \huge Haizea Manual}\\[0.4cm]
+\textsc{ \huge The Haizea Manual}\\{\large Technology Preview 1.2}\\[0.4cm]
\HRule \\[1.5cm]
\url{http://haizea.cs.uchicago.edu/}
Modified: trunk/doc/manual/whatis.tex
===================================================================
--- trunk/doc/manual/whatis.tex 2008-09-24 18:29:55 UTC (rev 510)
+++ trunk/doc/manual/whatis.tex 2008-09-24 18:31:55 UTC (rev 511)
@@ -23,40 +23,17 @@
You can find a couple (more specific) details about what you can do with Haizea in our list of features.
-\section{Leasing as a fundamental abstraction}
-
-Let's say you need computational resources...
-
-Maybe you're a scientist who needs to run some simulations. You have specific hardware requirements, but you're not particularly picky about when the simulations run, and probably won't even notice if they are interrupted at some point, as long as they finish running (correctly) at some point, maybe before a given deadline. A job scheduler, and a compute cluster, would probably be a good fit for you.
-
-You could also be a software developer who wants to test his or her code on a pristine machine, which you would only need for a relatively short period of time. Plus, every time you use this machine, you'd like it to start up with the exact same pristine software environment. Oh, and you want your machine now. As in right now. One option could be to install a virtual machine (VM) manager (such as Xen, VMWare, etc.) to start up these pristine machines as VMs on your own machine. Even better, you could go to a cloud (like Amazon EC2 or the Science Clouds) and have those VMs appear automagically somewhere else, so you don't have to worry about setting up the VM manager or having a machine powerful enough to run those VMs.
-
-Or perhaps you're a run-of-the-mill geek who wants his or her own web/mail/DNS/etc server. This server will presumably be running for months or even years with high availability: your server has to be running all the time, with no interruptions. There's a whole slew of hosting providers who can give you a dedicated server or a virtual private server. The latter are typically managed with VM-based datacenter managers.
-
-As you can see, there are a lot of resource provisioning scenarios in nature. However, the solutions that have emerged tend to be specific to a particular scenario, to the exclusion of other ones. For example, while job-based systems are exceptionally good at managing complex batch workloads, they're not too good at provisioning resources at specific times (some job-based systems do offer advance reservations, but they have well-known utilization problems) or at giving users unfettered access to provisioned resources (forcing them, instead, to interact with the resources through the job abstraction).
-
-A lease is a general resource provisioning abstraction that could be used to satisfy a variety of use cases, such as the ones described above. In our work, we've defined a lease as "a negotiated and renegotiable agreement between a resource provider and a resource consumer, where the former agrees to make a set of resource available to the latter, based on a set of lease terms presented by the resource consumer". In our view, the lease terms must include the following dimensions:
-
\begin{description}
- \item[Hardware] The hardware resources (CPU, memory, etc.) required by the resource consumer.
- \item[Software] The software environment that must be installed in those resources.
- \item[Availability] The period during which the hardware and software resources must be available. It is important to note that the availability period can be specified in a variety of ways, like "just get this to me as soon as you can", "I need this from 2pm to 4pm on Mondays, Wednesdays, and Fridays (and, if I don't get exactly this, I will be a very unhappy resource consumer)", or even "I need four hours sometime before 5pm tomorrow, although if you get the resources to me right now I'll settle for just two hours". A lease-based system must be able to efficiently combine all these different types of availability.
+ \item[Simulation mode, simulated time:] In this mode, Haizea works with a simulated set of hardware resources (which we'll be able to specify in a configuration file). When a lease is scheduled, all enactment commands (``start VM'', ``stop VM'', etc.) for that lease are simulated. Additionally, when time is simulated, Haizea will just ``fast forward'' through all the lease requests it receives. For example, suppose you've requested a lease that requires 30
+ \item[Simulation mode, real time:] The ``real time'' mode simply means that time will pass
+ \item[OpenNebula mode:]
\end{description}
-Furthermore, if you don't get any of these dimensions, then you're being shortchanged by your resource lessor. For example, Amazon EC2 is very good at providing exactly the software environment you want, and reasonably good at providing the hardware you want (although you're limited to a few hardware configurations), but not so good at supporting a variety of availability periods.
-So, Haizea aims to support resource leasing along these three dimension. For now, Haizea supports three types of availability:
+\section{Leasing as a fundamental abstraction}
-\begin{description}
-\item[Best-effort lease] Resources are provisioned as soon as they are available.
-\item[Advance reservation-style leases (or "AR leases")] Resources are provisioned during a strictly defined time period (e.g., from 2pm to 4pm).
-\item[Immediate leases] Resources must be provisioned right now, or not at all.
-\end{description}
+% Include very short spiel
-Although there are many systems (particularly job-based systems) that support these two types availability, Haizea differs in that it efficiently schedules heterogeneous workloads (combining best-effort and AR leases), overcoming the utilization problems typically resulting from using ARs. Haizea does this by using virtual machines to implement leases. Virtual machines also enable Haizea to provide exactly the hardware and software requested by the user. Additionally, Haizea also manages the overhead of preparing a lease, to make sure that any deployment operations (such as transferring a VM disk image) are taken care of before the start of a lease, instead of being deducted from the lessee's allocation.
-
-In the future, Haizea will support additional lease types, such as urgent leases, periodic leases, deadline-driven leases, etc.
-
\section{Features}
Foobar
More information about the Haizea-commit
mailing list