Commit 679ab818 authored by Robert Ricci's avatar Robert Ricci

Editing pass and write the VM section

parent d159560f
......@@ -4,12 +4,16 @@
@title[#:tag "basic-concepts" #:version apt-version]{Basic Concepts}
This chapter covers the basic concepts that you'll need to understand in
order to use Apt.
@section[#:tag "profiles"]{Profiles}
A @italic{profile} encapsulates everything needed to run an @italic{experiment}.
It consists of two main parts: a description of the resources (hardware,
storage, network, etc.) needed to run the experiment, and the software
artifacts that run on those resources.
A @italic{profile} encapsulates everything needed to run an
@seclink["experiments"]{@italic{experiment}}. It consists of two main parts: a
@seclink["rspecs"]{description of the resources} (hardware, storage, network,
etc.) needed to run the experiment, and the @seclink["disk-images"]{software
artifacts} that run on those resources.
The resource specification is in the @seclink["rspecs"]{RSpec} format. The
RSpec describes an entire @italic{topology}: this includes the nodes (hosts)
......@@ -20,7 +24,7 @@ network that connects them. The nodes may be
properties of these nodes, such as how much RAM they should have, how many
cores, etc., or can directly reference a specific @seclink["hardware"]{class of
hardware} available in one of Apt's clusters. The network topology can include
point to point links, LANs, etc. can may be either built from Ethernet or
point to point links, LANs, etc. and may be either built from Ethernet or
Infiniband.
The primary way that software is associated with a profile are through
......@@ -34,7 +38,7 @@ boots from; more than one node in a given profile may reference the same disk
image, and more than one profile may use the same disk image as well.
Profiles come from two sources: some are provided by Apt itself; these tend
to be (fairly) standard installation of popular operating systems and software
to be standard installations of popular operating systems and software
stacks. Profiles may also be provided by Apt's users, as a way for communities
to share research artifacts.
......@@ -43,7 +47,7 @@ to share research artifacts.
Most profiles in Apt are @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 it
@seclink["experiments"]{experiment}, so everyone using the profile is doing so
independently on their own set of resources.
@subsection[#:tag "persistent-profiles"]{Persistent Profiles}
......@@ -67,9 +71,9 @@ set of jobs}
A persistent profile may offer its own user interface, and its users may not
necessarily be aware that they are using Apt. For example, an HPC-style
persistent profile might run a standard cluster scheduler, and this is how
users intact with it. Or, a cloud-style profile might directly offer its own
web interface to provisioning virtual machines.
persistent profile might run a standard cluster scheduler, which users interact
with rather than the Apt website. Or, a cloud-style profile might directly
offer its own API for provisioning virtual machines.
For the time being, allocations for persistent profiles on Apt are handled
by directly @seclink["getting-help"]{contacting the Apt staff}.
......@@ -86,12 +90,12 @@ An experiment uses resources, @seclink["virtual-machines"]{virtual} or
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 means strong performance
isolation from all other Apt users. In the case of
@seclink["physical-machines"]{physical machines}, this also means strong
performance isolation from all other Apt users. In the case of
@seclink["virtual-machines"]{virtual machines}, there is still isolation from a
security and accounting standpoint, but weaker performance isolation. (The
exceptions to this rule are @seclink["persistent-profiles"]{persistent
profiles}, which may offer resources to .)
profiles}, which may offer resources to many users.)
Running experiments on Apt consume @bold{real resources}, which are
@bold{limited}. We ask that you be careful about not holding on to experiments
......@@ -105,7 +109,7 @@ The contents of local disk on nodes in an experiment are considered
@italic{ephemeral}---that is, when the experiment ends (either by being
explicitly terminated by the user or expiring), the contents of the disk are
lost. So, you should copy important data off before the experiment ends. A
simple way to do this is through @code{scp} or @code{sftp}. You may also
simple way to do this is through @tt{scp} or @tt{sftp}. You may also
@seclink["creating-profiles"]{create a profile}, which captures the contents of
the disk in a @seclink["disk-images"]{disk image}.
......@@ -120,10 +124,6 @@ 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.
@TODO{Section on SCP and SFTP}
@TODO{Different time periods for virtual and physical resources.}
@section[#:tag "projects"]{Projects}
Users are grouped into @italic{projects}. A project is, roughly speaking, a
......@@ -141,8 +141,6 @@ leader. Some project leaders run a lot of experiments themselves, while some
choose to approve accounts for others in the project, who run most of the
experiments. Either style works just fine in Apt.
@TODO{Create/join project using an existing account}
Permissions for some operations / objects depend on the project that they
belong to. Currently, the only such permission is the ability to make a profile
visible onto to the owning project. We expect to introduce more
......@@ -150,7 +148,26 @@ project-specific permissions features in the future.
@section[#:tag "virtual-machines"]{Virtual Machines}
@(under-construction)
The default node type in Apt is a @italic{virtual machine}, or VM. VMs in Apt
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 Apt 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. Apt 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. Apt @italic{does
not} provide performance isolation for disks, so I/O performance may also vary
depending on use. Finally, Apt @italic{does not} oversubscribe bandwidth on
network links attached to VMs, though variance in performance due to
fine-grained timing effects is still possible.
@section[#:tag "physical-machines"]{Physical Machines}
......
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