Components
Origo OS orchestrates hardware ressources and other infrastructure components. The terms we use for these components are introduced below.
Engines and Nodes
An Engine is a general term we use for the hardware environment that runs an Origo OS software installation. An engine consists of an administration node and a collection of compute nodes. The administration node runs the UI and the API, manages networking and orchestrates VM’s and storage . The compute nodes are stateless PXE-booted hardware nodes, which make their ressources available to the administration node for orchestration. In the default configuration the administration node also functions as a compute node – this allows for single node setups for development and testing. The administration node makes local storage available to the compute nodes over NFS. The compute nodes typically use fast, local storage for child images, where as the corresponding master images are kept on shared storage.
Stacks
A stack is a convenient way of packaging complex services with one or several servers. Stacks are installed in Origo OS (using the UI, the API of the CLI) with a single click or command. An installed stack uses physical ressources such as CPU, storage and networking ressources. The ressources a stack requires is described in a small text file. A stack’s OS and application data is contained in one or more virtual images called master images. Each time a stack is installed, this data is duplicated by “cloning” the master images to “child” images. This is done by using the features of the qcow2 image format.
If you check “download stacks” in the Origo OS Web client, basic stacks are downloaded from the Origo Registry. If you also link your installation with the registry, additional stacks are downladed.
To allow your services to present a simple configuration UI in a secure way, Origo OS makes a http->https proxy available to stacks. The web client has built-in logic to present the UI’s from stacks within the web client UI or in a separate tab. To get an idea of how this works, you may start e.g. the standard Ubuntu Bionic stack. You can also take a look at how stacks are built. A stack is built by a small utility called “stackbuilder”, from a simple recipe file in a format called a “stack recipe”, along with all the supplemental files that should be included in the stack. Once built, the stack can optionally be published to the registry for easy distribution and installation.
Servers
Servers are the VM’s or “virtual servers” running on the hypervisor on the hardware available in your engines. A VM consumes memory, storage and CPU resssources, all of which is shared with other VM’s. These ressources are made available through the hypervisor. Typically the hypervisor is KVM and the hardware is based on the x86 architecture. There is however nothing in Origo OS that prevents using e.g. VirtualBox as hypervisor or ARM hardware. A server runs a complete operating system, which can be any OS supported on the hardware.
Images
Images are physical files in qcow2 or another supported format. The hypervisor makes images available to the running operating systems as storage. To the OS, an image is seen as a raw storage device, which may be partitioned and formatted using any available patitioning scheme and file system format.
Storage and backup
Images used by servers may be located on two different kinds of storage: Local storage, typically one or more SSD’s on the node the server is running on, and shared storage provided via NFS by the administration node. The administration node may share several different file systems over NFS as shared storage. These are called storage pools, and are numbered incrementally, starting with 0, which is the default shared storage pool. The default file system in Origo OS for storage pools, local and shared, is ZFS. Origo OS may optionally format and configure storage devices for use as storage pools. This can be done via the web client or the API.
Storage pools that are formatted with ZFS are automatically backed up via ZFS snapshots of the entire file system daily and on demand (using the web client or the API). On demand backup of individual images is also supported, using the web client or the API. Individual image backup is done with rsync and is very ressource intensive, and primarily made available in order to have some kind of backup facility on non-ZFS file systems. Images that are backed up, either with ZFS or rsync, may be restored using the web client or the API.
Connections
Connections are network connections, which handle traffic to and from your servers. There are several kind of connections available. Connections of type “internal IP” only route traffic to other servers using internal IP addresses in the 10.0.0.0 network segment. Connections of type “external IP” route traffic directly to and from the Internet, i.e. your server is allocated an external IP address directly on its network interface. Connections of type “IP mapping” route traffic from an internal IP address to an external IP address, i.e. your server is allocated an internal IP address in the 10.0.0.0 network segment, but is presented to the Internet through an external IP address.
Users
Users are the user accounts belonging to the users of your Origo OS installation. If you link your installation with the Origo Registry, your user acccounts are synced with the registry. Only users with a valid email address as username and usernames who are not already registered in the registry are synced.
