Revision 632
Added by Borja Sotomayor almost 15 years ago
| simulation.tex | ||
|---|---|---|
| 48 | 48 |
|
| 49 | 49 |
\section{Specifying the simulated physical resources}
|
| 50 | 50 |
|
| 51 |
The simulated physical resources are specified using the \texttt{nodes} and \texttt{resources} options in the \texttt{[simulation]} section:
|
|
| 51 |
The simulated physical resources are specified using the \texttt{resources} option in the \texttt{[simulation]} section. This option can take two values, "in-tracefile", which means that the description of the simulated site is in the tracefile, or a string specifying the site's resources. For the former, see Appendix~\ref{app:lwf} for details on how the simulated site is specified in the tracefile. When using the latter, the format of the string is:
|
|
| 52 | 52 |
|
| 53 | 53 |
\begin{wideshellverbatim}
|
| 54 |
<numnodes> <resource_type>:<resource_quantity>[,<resource_type>:<resource_quantity>]* |
|
| 55 |
\end{wideshellverbatim}
|
|
| 56 |
|
|
| 57 |
For example: |
|
| 58 |
|
|
| 59 |
\begin{wideshellverbatim}
|
|
| 54 | 60 |
[simulation] |
| 55 | 61 |
... |
| 56 |
nodes: 4 |
|
| 57 |
resources: CPU,1;Mem,1024;Net (in),100;Net (out),100;Disk,20000 |
|
| 62 |
resources: 4 CPU:100 Memory:1024 |
|
| 58 | 63 |
... |
| 59 | 64 |
\end{wideshellverbatim}
|
| 60 | 65 |
|
| 61 |
Haizea currently only allows homogeneous resources to be specified. In other words, Haizea will manage a number of simulated physical machines, all with the same resources. The \texttt{resources} specifies the per-node resources using a semicolon-delimited list. Each entry in the list contains a pair: a resource name and its maximum capacity. Haizea currently recognises the following:
|
|
| 66 |
The above describes a site with four nodes, each with one CPU and 1024 MB of memory. Note that you must always specify at least the ``CPU'' and ``Memory'' resource types.
|
|
| 62 | 67 |
|
| 63 |
\begin{itemize}
|
|
| 64 |
\item \texttt{CPU}: Number of processors per node.
|
|
| 65 |
\item \texttt{Mem}: Memory (in MB)
|
|
| 66 |
\item \texttt{Net (in)}: Inbound network bandwidth (in Mbps)
|
|
| 67 |
\item \texttt{Net (out)}: Outbound network bandwidth (in Mbps)
|
|
| 68 |
\item \texttt{Disk}: Disk space in MB (not counting space for disk image cache).
|
|
| 69 |
\end{itemize}
|
|
| 70 |
|
|
| 71 |
These five resources must always be specified, since Haizea depends on them for fundamental resource reservations (running VMs, suspension of VMs, etc.) which involve these five types of resources. Additional resource types can be specified, but Haizea's scheduling code would have to be modified for them to be taken into account when scheduling leases. In the future, it will be possible to specify additional resources in the simulated nodes and in the lease requests with less effort. |
|
| 72 |
|
|
| 73 | 68 |
\section{Scheduling options}
|
| 74 | 69 |
|
| 75 | 70 |
The scheduling options control how leases are assigned to resources. |
| 76 | 71 |
|
| 72 |
\subsection{Scheduling policies}
|
|
| 73 |
|
|
| 74 |
Haizea includes a policy decision module that supports ``pluggable policies'', allowing developers to write their own scheduling policies. This is described in more detail in Chapter~\ref{chap:policies}, and we describe here only the built-in policies that are included with Haizea.
|
|
| 75 |
|
|
| 76 |
The first policy is lease admission, which controls what leases are accepted by Haizea. Take into account that this decision takes place before Haizea even attempts to schedule the lease (so, you can think of lease admission as ``eligibility to be scheduled''). The two built-in policies are to accept all leases, and to accept all leases \emph{except} advance reservations.
|
|
| 77 |
|
|
| 78 |
\begin{wideshellverbatim}
|
|
| 79 |
[scheduling] |
|
| 80 |
... |
|
| 81 |
policy-admission: accept-all | no-ARs | <custom policy> |
|
| 82 |
... |
|
| 83 |
\end{wideshellverbatim}
|
|
| 84 |
|
|
| 85 |
The next policy is lease preemptability, or what leases can be preempted. The two built-in policies are to not allow any preemptions, and to allow all ARs to preempt other leases. |
|
| 86 |
|
|
| 87 |
\begin{wideshellverbatim}
|
|
| 88 |
[scheduling] |
|
| 89 |
... |
|
| 90 |
policy-preemption: no-preemption | ar-preempts-everything | <custom policy> |
|
| 91 |
... |
|
| 92 |
\end{wideshellverbatim}
|
|
| 93 |
|
|
| 94 |
Finally, the host selection policy controls how Haizea chooses what physical hosts to map VMs to. The two built-in policies are to choose nodes arbitrarily (i.e., ``no policy''), or to apply a greedy policy that tries to minimize the number of preemptions. Currently, you should choose the greedy policy unless you really know what you're doing. |
|
| 95 |
|
|
| 96 |
\begin{wideshellverbatim}
|
|
| 97 |
[scheduling] |
|
| 98 |
... |
|
| 99 |
policy-host-selection: no-policy | greedy | <custom policy> |
|
| 100 |
... |
|
| 101 |
\end{wideshellverbatim}
|
|
| 102 |
|
|
| 103 |
|
|
| 77 | 104 |
\subsection{Backfilling algorithms}
|
| 78 | 105 |
|
| 79 | 106 |
\begin{warning}
|
| ... | ... | |
| 138 | 165 |
... |
| 139 | 166 |
\end{wideshellverbatim}
|
| 140 | 167 |
|
| 141 |
Lease migration can be allowed or not allowed. When allowed, we can specify whether a migration will involve transferring only the memory image of a VM (i.e., the file containing the contents of the VM when it was suspended), or will require transferring both the memory image and the disk image:
|
|
| 168 |
Lease migration can be disallowed, allowed, or allowed but without having to transfer any files from one to another:
|
|
| 142 | 169 |
|
| 143 | 170 |
\begin{wideshellverbatim}
|
| 144 | 171 |
[scheduling] |
| 145 | 172 |
... |
| 146 |
migration: True | False |
|
| 147 |
what-to-migrate: nothing | mem | mem+disk |
|
| 173 |
migration: no | yes | yes-notransfer |
|
| 148 | 174 |
... |
| 149 | 175 |
\end{wideshellverbatim}
|
| 150 | 176 |
|
| 151 |
Setting \texttt{what-to-migrate} to \texttt{nothing} means that migration \emph{is} allowed, but does not involve transferring any files from one node to another.
|
|
| 152 | 177 |
|
| 153 |
|
|
| 154 | 178 |
\subsection{Lease preparation scheduling}
|
| 155 | 179 |
|
| 156 | 180 |
Before a lease can start, it may require some preparation, such as transferring a disk image from a repository to the physical node where a VM will be running. When no preparation is necessary (e.g., assuming that all required disk images are predeployed on the physical nodes), the \texttt{lease-preparation} option must be set to \texttt{unmanaged}:
|
| ... | ... | |
| 183 | 207 |
|
| 184 | 208 |
\subsubsection{Transfer mechanisms}
|
| 185 | 209 |
|
| 186 |
The transfer mechanism specifies how the images will be transferred from the repository to the physical nodes. haizea currently only supports a multicast transfer mechanism:
|
|
| 210 |
The transfer mechanism specifies how the images will be transferred from the repository to the physical nodes. Haizea supports a unicast or a multicast transfer mechanism:
|
|
| 187 | 211 |
|
| 188 | 212 |
\begin{wideshellverbatim}
|
| 189 | 213 |
[deploy-imagetransfer] |
| 190 | 214 |
... |
| 191 |
transfer-mechanism: multicast |
|
| 215 |
transfer-mechanism: unicast | multicast
|
|
| 192 | 216 |
... |
| 193 | 217 |
\end{wideshellverbatim}
|
| 194 | 218 |
|
| 195 |
This mechanism assumes that it is possible to multicast the same image from the repository node to more than one physical node at the same time.
|
|
| 219 |
Whe using a unicast transfer mechanism, one image can only be transferred to one node at a time. When using multicast, it is possible to transfer the same image from the repository node to more than one physical node at the same time.
|
|
| 196 | 220 |
|
| 197 | 221 |
\subsubsection{Avoiding redundant transfers}
|
| 198 | 222 |
|
Also available in: Unified diff
Merged TP2.0/0.9 branch into trunk.