Skip to content

Concepts#

As mentioned in the About section, the SCL is an IaaS system that makes it possible to manage cloud resources in isolated environments.

The SCL offers HTTP APIs that operators and end-users use to configure required "building blocks" for achieving said purpose: This encompasses (de)registering compute nodes, managing Separation Contexts, Volumes, Routers, and Virtual Machines, which are referred to as SCL Objects.

The following subsections briefly describe what each SCL Object is about. Refer to the SCL architecture documentation for more details.

SCL Objects relevant for end-users#

Separation Context#

A Separation Context (SC) represents a tenant environment (e.g., that of a specific end-user) that is isolated from other tenant environments. Volume, Router, and Virtual Machine objects are managed by end-users inside SCs.

Volume#

A Volume represents block storage that can be used by a VM for example as a boot medium. End-users can create Volumes from image templates via URLs.

Virtual Machine#

End-users can create Virtual Machines (VMs) to spawn VMs. VMs inside the same SC can communicate with each other.

Router#

By default, VMs inside an SC cannot communicate with other networks outside the SC. Routers currently make it possible to enable outgoing traffic via an external IP. Optionally, user specified ports associated with the same external IP can be forwarded to user specified endpoints inside the SC. This makes it possible to expose SC internal services to the world outside.

A single SC can have multiple Routers.

SCL Objects relevant for operators#

Node#

A Node (short for compute node) represents a machine that can securely host VMs regardless of their SCs. A scheduling component of the SCL is responsible for assigning VMs to Nodes, taking the required resources of the VM and the available resources of the Node into account.

Controllers#

Controllers are internal processes, typically tailored to a specific responsibility such as VM scheduling, that drive the system toward its desired state. They register themselves with the API to enable task partition, which is required for scaling out.

Desired specification vs. status differentiation#

SCL Objects have fields to indicate specification and status information:

  • Specification (in short "spec") information expresses the desired state that the user of the SCL wants to achieve, e.g. a VM with certain configuration and a (default) Running state. As a rule of thumb and unless noted otherwise, most spec fields become read-only after an SCL Object has been created. Some fields however, for example whether a VM should be Running or Stopped, can be changed later via updates.
  • Status information is in contrast modified only by the SCL. Most SCL Objects follow a lifecycle with an explicit state machine. For example, a VM has to be scheduled first before it can be booted. The status fields make it possible to express current transition states. Controllers leverage it to advance the state machine, (e.g., marking a VM as Scheduled and noting the AssignedNode) or to report back errors. As a rule of thumb, the number of states is closely linked to the number of distinct controllers that are involved in creating the desired state.

Metadata#

All SCL Objects are associated with metadata, which provides the following information:

  • The user-provided unique name of an SCL Object, used to tell it apart from other SCL Objects of the same kind (within an SC).
  • The resource version of the SCL Object, which is used for optimistic concurrency control. When reading an SCL Object, the SCL API includes a resource version with a certain value. Clients must include the same value in update requests to the same SCL Object. The described mechanism helps to prevent "lost update" anomalies.
  • Deletion mark and Finalizers: Similar to Kubernetes, deletion of objects is achieved via Finalizers. They represent a sequence of clean-up tasks that have to be tackled by controllers in the right order to guarantee a safe deletion. This means for instance that in order to delete an SC, all child elements (e.g. all related VMs, Routers, Volumes) and all possible side effects on the Nodes have to deleted first. Whenever the SCL receives a deletion request for an SCL Object for the first time, the SCL API will mark it for deletion by initializing the sequence of finalizers. After that, only updates to the finalizers are permitted and all other fields of an SCL Object become read-only.