All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

Commit 2b956fde authored by Robert Ricci's avatar Robert Ricci

Pass on the "Basic concepts" chapter for CloudLab

parent 4c48c5e3
......@@ -44,7 +44,7 @@ to share research artifacts.
@subsection[#:tag "on-demand-profiles"]{On-demand Profiles}
Most profiles in @(tb) are @italic{on-demand profiles}, which means that they are
Profiles in @(tb) may be @italic{on-demand profiles}, which means that they are
designed to be instantiated for a relatively short period of time (hours or
days). Each person instantiating the profile gets their own
@seclink["experiments"]{experiment}, so everyone using the profile is doing so
......@@ -59,24 +59,24 @@ on top of @(tb)'s hardware and provisioning capabilities. Examples of persistent
profiles include:
@itemlist[
@item{An instance of a cloud software stack, providing VMs to a large community}
@item{A cluster set up with a specific software stack for a class}
@item{A persistent instance of a database or other resource used by a large
research community}
@item{Machines set up for a contest, giving all participants access to the same
hardware}
@item{An instance of a cloud software stack, providing VMs to a large community}
@item{An HPC cluster temporarily brought up for the running of a particular
set of jobs}
]
A persistent profile may offer its own user interface, and its users may not
necessarily be aware that they are using @(tb). For example, an HPC-style
persistent profile might run a standard cluster scheduler, which users interact
with rather than the @(tb) website. Or, a cloud-style profile might directly
offer its own API for provisioning virtual machines.
necessarily be aware that they are using @(tb). For example, a cloud-style
profile might directly offer its own API for provisioning virtual machines.
Or, an HPC-style persistent profile might run a standard cluster scheduler,
which users interact with rather than the @(tb) website.
For the time being, allocations for persistent profiles on @(tb) are handled
by directly @seclink["getting-help"]{contacting the @(tb) staff}.
@apt-only{For the time being, allocations for persistent profiles on @(tb) are
handled by directly @seclink["getting-help"]{contacting the @(tb) staff}.}
@section[#:tag "experiments"]{Experiments}
......@@ -91,9 +91,9 @@ resources used by an experiment are devoted to the individual use of the user
who instantiates the experiment. This means that no one else has an account,
access to the filesystems, etc. In the case of experiments using solely
@seclink["physical-machines"]{physical machines}, this also means strong
performance isolation from all other @(tb) users. In the case of
performance isolation from all other @(tb) users. @apt-only{In the case of
@seclink["virtual-machines"]{virtual machines}, there is still isolation from a
security and accounting standpoint, but weaker performance isolation. (The
security and accounting standpoint, but weaker performance isolation.} (The
exceptions to this rule are @seclink["persistent-profiles"]{persistent
profiles}, which may offer resources to many users.)
......@@ -117,12 +117,12 @@ All experiments have an @italic{expiration time}. By default, the expiration
time is short (a few hours), but users can use the ``Extend'' button on the
experiment page to request an extension. A request for an extension must
be accompanied by a short description that explains the reason for requesting
an extension, which will be reviewed by @(tb) staff. @seclink["guest-users"]{Guest
users} are not permitted to hold experiments for very long; if you are
using @(tb) as a guest, and find yourself running out of time frequently, we
recommend @seclink["register"]{registering for an account}. You will
receive email a few hours before your experiment expires reminding you to
copy your data off or request an extension.
an extension, which will be reviewed by @(tb) staff.
@apt-only{@seclink["guest-users"]{Guest users} are not permitted to hold
experiments for very long; if you are using @(tb) as a guest, and find yourself
running out of time frequently, we recommend @seclink["register"]{registering
for an account}.} You will receive email a few hours before your experiment
expires reminding you to copy your data off or request an extension.
@section[#:tag "projects"]{Projects}
......@@ -148,26 +148,36 @@ project-specific permissions features in the future.
@section[#:tag "virtual-machines"]{Virtual Machines}
The default node type in @(tb) is a @italic{virtual machine}, or VM. VMs in @(tb)
are currently implemented on
@hyperlink["http://blog.xen.org/index.php/2013/07/09/xen-4-3-0-released/"]{Xen
4.3} using
@hyperlink["http://wiki.xenproject.org/wiki/Paravirtualization_(PV)"]{paravirtualization}.
Users have full root access with their VMs via @tt{sudo}.
VMs in @(tb) are hosted on shared nodes; this means that while no one else
has access to your VMs, there are other users on the same hardware whose
activities may affect the performance of your VMs. @(tb) currently @italic{does}
oversubscribe virtual cores, meaning VMs may get less CPU time than would be
indicated by the number of virtual cores they have, depending on others'
activity. It @italic{does not} oversubscribe RAM, meaning that all virtual
RAM is backed by physical pages, though performance can still be affected
by others' use of the memory bus, which is a shared resource. @(tb) @italic{does
not} provide performance isolation for disks, so I/O performance may also vary
depending on use. Finally, @(tb) @italic{does not} oversubscribe bandwidth on
network links attached to VMs, though variance in performance due to
fine-grained timing effects is still possible.
@apt-only{
The default node type in @(tb) is a @italic{virtual machine}, or VM. VMs in
@(tb) are currently implemented on
@hyperlink["http://blog.xen.org/index.php/2013/07/09/xen-4-3-0-released/"]{Xen
4.3} using
@hyperlink["http://wiki.xenproject.org/wiki/Paravirtualization_(PV)"]{paravirtualization}.
Users have full root access with their VMs via @tt{sudo}.
VMs in @(tb) are hosted on shared nodes; this means that while no one else
has access to your VMs, there are other users on the same hardware whose
activities may affect the performance of your VMs. @(tb) currently @italic{does}
oversubscribe virtual cores, meaning VMs may get less CPU time than would be
indicated by the number of virtual cores they have, depending on others'
activity. It @italic{does not} oversubscribe RAM, meaning that all virtual
RAM is backed by physical pages, though performance can still be affected
by others' use of the memory bus, which is a shared resource. @(tb) @italic{does
not} provide performance isolation for disks, so I/O performance may also vary
depending on use. Finally, @(tb) @italic{does not} oversubscribe bandwidth on
network links attached to VMs, though variance in performance due to
fine-grained timing effects is still possible.
}
@clab-only{
While @(tb) does have the ability to provision virtual machines itself
(using the Xen hypervisor), we expect that the dominant use of @(tb) is
that users will provision @seclink["physical-machines"]{physical machines}.
Users (or the cloud software stacks that they run) may build their own
virtual machines on these physical nodes using whatever hypervisor they
wish.
}
@section[#:tag "physical-machines"]{Physical Machines}
......@@ -182,6 +192,8 @@ can be sure that your physical machines don't have any state left around from
the previous user. You can find descriptions of the
hardware in @(tb)'s clusters in the @seclink["hardware"]{hardware} chapter.
@apt-only{
Physical machines are relatively scarce, and getting access to large numbers of
them, or holding them for a long time, may require
@seclink["getting-help"]{contacting @(tb) staff}.
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment