swapping.html 6.19 KB
Newer Older
Leigh Stoller's avatar
Leigh Stoller committed
1 2
<!--
   EMULAB-COPYRIGHT
3
   Copyright (c) 2000-2003 University of Utah and the Flux Group.
Leigh Stoller's avatar
Leigh Stoller committed
4 5
   All rights reserved.
  -->
Chad Barb's avatar
Chad Barb committed
6
<a name="top"></a>
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
<center>
<h1>Node Use Policies</h1>
</center>

<ul>
<li><a href="#summary">
What are your policies?</a>
<li><a href="#active">
What is "active use"?</a>
<li><a href="#idle">
How long is too long for a node to be idle?</a>
<li><a href="#state">
What is "node state"?</a>
<li><a href="#email">
I just received an email asking me to swap or terminate my
Chad Barb's avatar
Chad Barb committed
22
experiment.</a>
23 24 25 26 27
<li><a href="#swapped">
Someone swapped my experiment!</a>
</ul>


Chad Barb's avatar
Chad Barb committed
28
<a name="summary"></a>
29 30
<h3>What are your policies?</h3>

Chad Barb's avatar
Chad Barb committed
31
<p>
32 33 34 35 36 37
As a courtesy to other experimenters, we ask that experiments be
swapped out or terminated when they are no longer in active use. There
are a limited number of nodes available, and node reservations are
exclusive, so it is important to free nodes that will be idle so that
others may use them. By way of summary, our policy is that experiments
should be swapped out when they are not in use. In general, if they
38
are idle for several hours, we will send you mail about it and/or
39 40 41 42 43
swap out the experiment for you. The actual grace period will differ
depending on the size of the experiment and other factors. If you mark
your experiment "unswappable" at creation time, we will contact you
before swapping it, since local node state will be lost on
swapout. Please see full details below.
Chad Barb's avatar
Chad Barb committed
44
</p>
45

Chad Barb's avatar
Chad Barb committed
46
<a name="active"></a>
47 48
<h3>What is "active use"?</h3>

49
<p>
50 51 52 53 54
A node or experiment that is being actively used will be doing
something related to your experiment. In almost all cases, someone
will either be logged into it using it interactively, or some program
will be running, sending and receiving packets, and performing the
operations necessary to carry out the experiment.
Chad Barb's avatar
Chad Barb committed
55
</p>
56

Chad Barb's avatar
Chad Barb committed
57
<a name="idle"></a>
58 59
<h3>How long is too long for a node to be idle?</h3>

Chad Barb's avatar
Chad Barb committed
60
<p>
61 62
Ideally, an experiment should be used nearly continuously from start
to finish of the experiment, then swapped out or terminated. However,
63 64 65 66 67 68 69 70 71
this isn't always possible. In general, if your experiment will most
likely be idle for 2 hours or more, it should be swapped out. This is
especially true at night (in U.S. timezones) and on weekends. Many
experimenters take advantage of lower demand during evenings and
weekends to run their large-scale (50-150 node) tests. If your
experiment uses 10 nodes or more, it is even more important to release
your nodes as soon as possible. Swapin and swapout only take a few
minutes (typically 3-5 for swapin, and less than 1 for swapout), so
you won't lose much time by doing it.
Chad Barb's avatar
Chad Barb committed
72
</p>
73

Chad Barb's avatar
Chad Barb committed
74
<a name="state"></a>
75 76
<h3>What is "node state"?</h3>

Chad Barb's avatar
Chad Barb committed
77
<p>
78 79 80 81 82 83 84 85
Some experiments have state that is stored exclusively on the nodes
themselves, saved to the local hard drive. This is state that is not
in your NS file and files it references, and which is not preserved in
our database across swapin/swapout. This is state you add to your
machines "by hand" after Emulab sets up your experiment, like files
you add or modify on filesystems local to test nodes. Local node state
does not include any data you store in /users or /proj, since they are
saved on a fileserver, and not on the local nodes. 
Chad Barb's avatar
Chad Barb committed
86
</p>
87 88 89 90 91 92 93 94

<p>
Most experiments don't have any local node state, and can be swapped
out and in without losing any information. This is highly recommended,
since it is more courteous to other experimenters. It allows you to
easily free up your nodes on request without losing any of the work
you have done on your experiment. Please make your experiments adhere
to this guideline whenever possible.
Chad Barb's avatar
Chad Barb committed
95
</p>
96 97 98 99 100 101 102 103 104 105

<p>
Wherever possible it is discouraged to have local node state, since
swapping out causes this data to be lost. An experiment that needs
local state should be marked "unswappable" when you create it. If you
must have node state, you can save it before you swap out by creating
a disk image of the node in question, and later reloading it to a new
node after you swap in again. Disk images in effect create a "custom
OS" that can be loaded automatically based on your NS file. More
information about disk images can be found on our <a
106
href="https://www.emulab.net/newimageid_ez.php3"> Disk Image
107 108 109 110
page</a> (you must be logged in to use it). We are currently working
on a system that will allow you to save disk images from all the nodes
in your experiment at swapout time, and reload them automatically when
you swap back in.
Chad Barb's avatar
Chad Barb committed
111
</p>
112

Chad Barb's avatar
Chad Barb committed
113
<a name="email"></a>
114
<h3>I just received an email asking me to swap or terminate my
Chad Barb's avatar
Chad Barb committed
115 116
experiment.</h3>
<p>
117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135
Emulab has a system for detecting node use, to help achieve more
efficient and fair use of Emulab's limited resources. This system
sends email messages to experiment leaders whose experiments have been
idle for over 24 hours. If you get a message like this, your
experiment has been inactive for too long and should free up the nodes
it has allocated. If the experiment continues to be idle, more
reminders will be sent. On the third reminder and subsequent messages,
your project leader will be one of the recipients. If you feel you
receive the message in error, please respond to <a
href="mailto:testbed-ops@flux.cs.utah.edu"> Testbed Operations
(testbed-ops@flux.cs.utah.edu)</a> as soon as possible, describing how
you have used your node in the last 24 hours. There are some types of
activity that are difficult to accurately detect, so we'd like to know
how we can improve our activity detection system. Above all, <b>do not
ignore these messages</b>. If you get several reminders and don't
respond, your experiment may be swapped out, potentially causing loss
of some of your work (see "node state" above). If there is a reason
you need to keep your experiment running <b>tell us</b> so we don't
inadvertently cause problems for you.
Chad Barb's avatar
Chad Barb committed
136
</p>
137

Chad Barb's avatar
Chad Barb committed
138
<a name="swapped"></a>
139
<h3>Someone swapped my experiment!</h3>
Chad Barb's avatar
Chad Barb committed
140
<p>
141 142 143 144 145 146 147
As described above, we will typically try to contact you about your
idle experiment before we swap it out. However, if the experiment has
been idle for many hours, we may swap it out for you unless you marked
it as "unswappable" when you created your experiment. Because of this,
it is critical that you keep in close contact with us about an
experiment that we may perceive as idle if you want to avoid any loss
of your work.
Chad Barb's avatar
Chad Barb committed
148
</p>
149 150
<p>
<a href="#top"> Back to top of page</a>
Chad Barb's avatar
Chad Barb committed
151
</p>
152