5 Basic Concepts
This chapter covers the basic concepts that you’ll need to understand in order to use Apt.
5.1 Profiles
A profile encapsulates everything needed to run an 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.
The resource specification is in the RSpec format. The RSpec describes an entire topology: this includes the nodes (hosts) that the software will run on, the storage that they are attached to, and the network that connects them. The nodes may be virtual machines or physical servers. The RSpec can specify the properties of these nodes, such as how much RAM they should have, how many cores, etc., or can directly reference a specific class of hardware available in one of Apt’s clusters. The network topology can include 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
disk images. A disk image (often just called an
“image”) is a block-level snapshot of the contents of a real or virtual
disk—
Profiles come from two sources: some are provided by Apt itself; these tend 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.
5.1.1 On-demand Profiles
Profiles in Apt may be 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 experiment, so everyone using the profile is doing so independently on their own set of resources.
5.1.2 Persistent Profiles
Apt also supports persistent profiles, which are longer-lived (weeks
or months) and are set up to be shared by multiple users. A persistent profile
can be thought of as a “testbed within a testbed”—
An instance of a cloud software stack, providing VMs to a large community
A cluster set up with a specific software stack for a class
A persistent instance of a database or other resource used by a large research community
Machines set up for a contest, giving all participants access to the same hardware
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 Apt. 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 Apt website.
For the time being, allocations for persistent profiles on Apt are handled by directly contacting the Apt staff.
5.2 Experiments
See the chapter on repeatability for more information on repeatable experimentation in Apt.
An experiment is an instantiation of a profile. An experiment uses resources, virtual or physical, on one or more of the clusters that Apt has access to. In most cases, the 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 physical machines, this also means strong performance isolation from all other Apt users. In the case of virtual machines, there is still isolation from a security and accounting standpoint, but weaker performance isolation. (The exceptions to this rule are persistent profiles, which may offer resources to many users.)
Running experiments on Apt consume real resources, which are limited. We ask that you be careful about not holding on to experiments when you are not actively using them. If you are are holding on to experiments because getting your working environment set up takes time, consider creating a profile.
The contents of local disk on nodes in an experiment are considered
ephemeral—
All experiments have an 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 Apt staff. Guest users are not permitted to hold experiments for very long; if you are using Apt as a guest, and find yourself running out of time frequently, we recommend 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.
5.2.1 Extending Experiments
If you need more time to run an experiment, you may use the “Extend” button on the experiment’s page. You will be presented with a dialog that allows you to select how much longer you need the experiment. Longer time periods require more extensive appoval processes. Short extensions are auto-approved, while longer ones require the intervention of Apt staff or, in the case of indefinite extensions, the steering commitee.
5.3 Projects
Users are grouped into projects. A project is, roughly speaking, a group of people working together on a common research or educational goal. This may be people in a particular research lab, a distributed set of collaborators, instructors and students in a class, etc.
A project is headed by a project leader. We require that project leaders be faculty, senior research staff, or others in an authoritative position. This is because we trust the project leader to approve other members into the project, ultimately making them responsible for the conduct of the users they approve. If Apt staff have questions about a project’s activities, its use of resources, etc., these questions will be directed to the project 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.
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 project-specific permissions features in the future.
5.4 Physical Machines
Users of Apt may get exclusive, root-level control over physical machines. When allocated this way, no layers of virtualization or indirection get in the way of the way of performance, and users can be sure that no other users have access to the machines at the same time. This is an ideal situation for repeatable research.
Physical machines are re-imaged between users, so you 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 Apt’s clusters in the hardware chapter.
Physical machines are relatively scarce, and getting access to large numbers of them, or holding them for a long time, may require contacting Apt staff.
5.5 Virtual Machines and Containers
The default node type in Apt is a virtual machine, or VM. VMs in Apt are currently implemented on Xen 4.6 using paravirtualization. Users have full root access with their VMs via 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 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 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 does not provide performance isolation for disks, so I/O performance may also vary depending on use. Finally, Apt does not oversubscribe bandwidth on network links attached to VMs, though variance in performance due to fine-grained timing effects is still possible.