VIFIB DESCENTRALIZED CLOUD COMPUTING

SlapOS is a decentralized Cloud Computing technology that can automate the deployment and configuration of applications in a heterogeneous environment.

SlapOS Production Deployment System Requirements

SlapOS Cloud Computer Provider System Overview

This design document the minimal setup and architecture for creating a production grade SlapOS system that can be used for cloud computing, edge computing or LTE/NR network management. This setup is split into two layers: parent ("administrative") layer and child ("administered") layer. The document will describe both the parent and child layer. It will describe the required hardware and software that needs to be installed along with links to their respective software dependencies.

For a more detailed overview of SlapOS itself, its concept and system design, please refer to the SlapOS architecture design document.

The installation is generic, automated and independent of how the cloud computing network will eventually be used. It requires at least two computers and at most one day to install and setup.

Table of Content

  • Parent Layer
  • Child Layer

The concept of layers relates to the recursive nature of SlapOS: a SlapOS system can deploy a SlapOS system which can deploy yet another SlapOS system, etc. A production deployment of SlapOS requires at least two layers: a parent layer and a child layer.

We need first to deploy a minimal bootstrap SlapOS system called the parent layer. We use this layer to create a SlapOS node that runs a single instance of a service called SlapOS Master. SlapOS Master thus plays the role of a SlapOS Node in the parent layer.

Once this is done, we can add additional SlapOS nodes that connect to the previously created instance called "SlapOS Master" and who together form the child layer. SlapOS Master plays the role of a SlapOS Master in the child layer. Each additional SlapOS node plays the role of a SlapOS Node in the child layer.

This bootstap approach of SlapOS is quite similar with the boostrap of reflexive object languages and with the concept of metaclass. An object is the instance of a class. A class, as an object, is the instance of a metaclass class. And the metaclass class object is very often an instance of the metaclass class. In our case, SlapOS parent layer plays the same role as the metaclass notion. SlapOS child layer plays the same role as class

In other words, since SlapOS is a general purpose system that can automate provisioning of any service and since SlapOS is itself implemented as a collection of services, there is no reason why SlapOS should not be deployed by SlapOS itself.

Parent Layer

SlapOS Cloud Computing Provider - Admin Layer

The parent layer in this document is used to describe the essential (minimal) services required to deploy and administrate any type of Cloud (Edge, Home, Distributed, Datacenter-based). It consists of a master node (COMP-ROOT) and a first slave node (COMP-0) which provides services to the master for managing and communicating with nodes on the network. At the very minimum these services are a Frontend (Apache) and a Re6st registry. Depending on the type of cloud computing system being created, additional servers can be used to provide Frontends (similar to a CDN) and/or additional services required (like user database for managing simcards).

Tutorials are available covering installation and configuration of a SlapOS Master as well as setting up and configuring a Slave node on the parent and child layer. Additional documentation is available on how to extend the SlapOS Master with custom services.

For creating and providing these custom services, the tutorial teaching creation a software release is a good starting point.

Parent Layer - COMP-ROOT - Hardware

SlapOS Cloud Computing Provider - Admin Layer/MASTER/Hardware

The COMP-ROOT will host SlapOS Master and requires at a minimum:

  • 4-8 CPU cores (8 vCores) - preferrably i7, XEON, AMD
  • 8-16 GB RAM
  • 200GB SSD harddisk (480GB preferred)

Installation is generic, fully automated, and will take ~20 min if installable from cache plus another 20-40 min for running the configurator. It will install SlapOS Proxy and provide 3 access points on ports 80, 443 and 5443.

Note, that this machine must have public IPv4 or private IPv4 reachable from COMP-0 (and users). The above server should be sufficient to run a network of 80-160 actual computers (slave nodes), which then use computer partitions to provide instances of software releases called "hosting subscriptions" to users - see the glossary for the full SlapOS nomenclature. Each hosting subscription (for example erp5 or LET eNodeB) is in turn run through several URL-based services (erp5: 5 services, LTE eNodeB: 5+ services).

Since some of the services on the COMP-ROOT require a Webrunner which in turn requires another Frontend (Apache) with IPv6 and thus Re6st to work, a second server COMP-0 is used to provide all of these services to COMP-ROOT as well as other nodes in the network. It is a special node

Parent Layer - COMP-ROOT - Software

SlapOS Cloud Computing Provider - Admin Layer/COMP-MASTEr/Software

Initially two different types of SlapOS Master are being used - SlapOS Master (ERP5-based) and SlapProxy (minimalistic). In order to manage the deployment of a SlapOS Master in the same way as managing any other kind of instance, a recursive approach is used so that a minimalistic Master (SlapProxy) can deploy another ERP5-based Master. For smaller use cases, like running only a single node, SlapProxy alone is sufficient (the Nexedi Webrunner is an example of a SlapProxy (IDE) being used to deploy a software instance on a single machine for a single user). However, in case of a larger network of nodes and using SlapOS for cloud orchestration and computing, SlapProxy is used only at startup and retired once the actual erp5-based SlapOS Master is up and running.

Two softwares will eventually be run on the SlapOS Master - ERP5 itself for user management, deployment of services, usage accounting and capacity management) and an Frontend (Apache) for accessing the Dashboard.

Parent Layer - COMP-0 - Hardware

SlapOS Cloud Computing Provider - Admin Layer/COMP-0/Hardware

COMP-0 will provide certain services to COMP-ROOT and other nodes in the network. Installation of a node is generic for all nodes in a network. Only the configuration or more specifically which services a nodes provides can differ from node to node.

COMP-0 will run at least two services: an Frontend (Apache) and the Re6st Registry meaning it will require having a valid SSL wildcard (!) certificate as well as IPv6. If both are available, deployment will require about an hour. The Frontend (Apache) will communicate over ports 80 and 443 and the registry on port 19201. The minimum requirements for this machine are:

  • 2-4 Cores
  • 4-8 GB RAM
  • 60-100 GB SSD harddisk (mostly needed for logs)

COMP-0 contacts the COMP-ROOT over port 5443 and also requires public IPv4 or private IPv4 reachable by COMP-ROOT and users.

With the above specifications about 8 computers which equates to about 800 services can be provided through URLs (services in SlapOS are all provided over https).

Parent Layer - COMP-0 - Software

SlapOS Cloud Computing Provider - Admin Layer/COMP-0/Software

The COMP-0 node is setup like any node in the network. However, during configuration a required set of services has to be installed on COMP-0 in order to provide these to COMP-ROOT and other nodes in the network (see the aforementioned requirement of COMP-0 needing at least IPv4 connectivity to the COMP-ROOT and users).

One required software is the re6st Registry, which is a service to inform nodes about other nodes in a network as well as between which nodes tunnels should be established. The registry can issue tokens which nodes can later use to register on a network. It requires IPv6 which is why XXX. Besides the registry a first network "root" node is also instantiated using re6st.

Besides re6st, another Frontend (Apache) is required to make a node accessible on the network as well as to connect with other services such as the monitor (XXX). Since all connections need to be secured and any number of nodes will result in issuance of a significant number of domains and URLs, a wildcard SSL certificate is necessary for the Frontend (Apache).

Depending on the cloud computing system being created additional services like a SimCardDB (LTE eNodeB User database) will have to be installed on the COMP-0 machine. This however is a case by case decision.

Child Layer

SlapOS Cloud Computing Provider - Admin Layer

The child layer only consists of nodes which are installed in the same way as COMP-0 but who are used for providing various kind of services depending on the overall cloud computing architecture. For example when using SlapOS to provide a network management system for a phone network provider, the nodes could be used to provide the Amarisoft LTE stack (eNodeB).

Child Layer - COMP-X - Hardware

Network nodes (labelled COMP-X) are installed in the same way as the COMP-0 node. Hardware requirements depend on the software instances being run on the nodes. For simple services, a machine similar to the one used for COMP-0 will be sufficient whereas more complex softwares running multiple services (such as ERP5 or LTE eNodeB) should look more towards the COMP-ROOT requirements as indicator of what will be necesary.

Child Layer - COMP-X - Software

SlapOS Cloud Computing Provider - Child Layer/COMP-XXXX/Software

During installation a node can (and should) also be registered on network (using the token obtained from the re6st registry). Afterwards it is up to the COMP-ROOT to decide which software will be installed and to whom it will be provided. XXX

Thank You

Image Nexedi Office
  • Nexedi GmbH
  • 147 Rue du Ballon
  • 59110 La Madeleine
  • France