This repository aims to be the single source of truth about the architecture and the behavior of the FLUIDOS ecosystem. It will also be an indexing point for all the artifacts and repositories involved.
This is not inted as a project deliverable, but as a guidance for FLUDOS partners to address the several activities to be carried out throughout the development.
FLUIDOS architecture is made up of two main objects, very different from eachother still greatly coupled in several workflows: the Node and the Catalog. While the first is mantatory, as it's the base element of the ecosystem, the latter is optional, and jumps in whenever there's the need to go cross-domain or let the general public access the ecosystem through a user interface.
D2.1 Definition
A FLUIDOS Node is a unique computing environment, under the control of a single administrative entity (although different Nodes can be under the control of different administrative entities), composed of one or more machines and modeled with a common, extensible set of primitives that hide the underlying details (e.g., the physical topology), while maintaining the possibility to export the most significant distinctive features (e.g., the availability of specific services; peculiar HW capabilities).
Overall, A FLUIDOS node is orchestrated by a single Kubernetes control plane, and it can be composed of either a single device or a set of devices (e.g., a datacenter). Device homogeneity is desired in order to simplify the management (physical servers can be considered all equals, since they feature a similar amount of hardware resources), but it is not requested within a FLUIDOS node. In other words, a FLUIDOS node corresponds to a Kubernetes cluster.
A FLUIDOS node includes a set of resources (e.g., computing, storage, networking, accelerators), software services (e.g., ready-to-go applications) that can be either leveraged locally or shared with other nodes. Furthermore, a FLUIDOS node features autonomous orchestration capabilities, i.e., (1) it accepts workload requests, (2) it runs the requested jobs on the administered resources (e.g., the participating servers), if application requirements and system security policies are satisfied, and (3) it features a homogeneous set of policies when interacting with other nodes.
A Node is a set of software components that live on a Kubernete cluster, whatever their kind (eg. Pod, DaemonSet, Service, Job etc.). Each Node embeds all the components, regardless of the role it takes on, while its behavior is role based. The components interact with eachother exploiting several transmission systems according to the number of interactions and the messages to be exchanged: as a rule of thumb, local interactions are mediated by Kubernetes Controllers, while external interactions are managed through RESTful APIs.
D2.1 Definition
A FLUIDOS Supernode is a FLUIDOS node that acts as a “master” for an entire FLUIDOS domain, becoming the entity that can establish peering relationships on behalf of all nodes of a FLUIDOS domain toward a third-party Node, and acting as “aggregator” of resources and services for all the entire FLUIDOS Domain.
A Supernode acts as a gateway for domain's nodes that do not have access to the Internet or they don't know other domains. Its behavior is mostly similar to the node's one, with the main difference being the knowledge of other domains or catalogs with wich it can interact. The interactions exploit the same protocols and are managed by the same components, but the sources and destinations of the informations differ.
Besides acting as a gateway, a Supernode is another aggregation point in the distribution chain of informations. The specific tasks are deepened in the descriptive document of each component, while the interactions are shown in the workflows involving multiple domains.
The implementation of each component is responsibility of a single Work Package. The WPs assignements are highlighted inside the descriptive document of each component, and summerized in the per-WP index.
The Node/Supernode components are the following:
- Service Handler
- Node Orchestrator
- Local Resource Manager
- Local Telemetry Service
- Remote Telemetry Service
- Ratings and Metrics
- Available Resources
- REAR Manager
- Discovery Manager
- Peering Candidates
- Contract Manager
- Resource Importer
- Resource Exporter
- Virtual Fabric Manager
- Privacy and Security Manager
- Trust and Security Agent
Definition
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
The Catalog components are the following:
Definition
A FLUIDOS Flavour is the description of an available resources or services configuration.
Lorem ipsum dolor sit amet
Definition
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
Definition
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
The interactions among Nodes, Nodes and Supernodes, Supernodes and Catalogs, and all software components belonging to these objects, can be grouped in five phases:
This phase is carried out by the Service Handler. It consists in the translation and the reduction to lowest terms of a received intent so that the Node Orchestrator can trigger the primitive functions of the Node to fulfill that intent.
This phase consists in the discovery, both solicited or advertised, of flavours provided by other Nodes. It is mainly carried out by the Discovery Manager with the scope of filling the Peering Candidates table and provide suitable flavours to the REAR Manager. It relies on first couple of messages of the REAR protocol.
This phase involves many components, since it consists in the contract signing step, managed by the Contract Managers of both Nodes, and the actual resources reservation step, that consists in updating of the Available Resources tables. The phase is syncronously coordinated by the REAR Managers of both Nodes.
The Peering phase is carried out by the Resource Importer of the Consumer Node, the Resource Exporter of the Provider Node and the Virtual Fabric Managers of both Nodes: it basically relies on the primitives provided by LIQO to establish the peering between the two nodes and extend the continuum.
This phase is managed by the Node Orchestrator of the Consumer Node and consists in the actual deployment of the workload on the Kubernetes Virtual Nodes created as output of the Peering phase, so that the real workload is automatically moved to the Provider Node for execution.
This is the phase where the two Telemetry Services are working actively to monitor both the Local and Remote performances to populate the Ratings and Metrics table.
This is the phase where the process is sunsetted, the peering is teared down, and the resources are freed and made available again for future processes. Its triggered by the Node Orchestrator and involves all the components that previously have cooperated to take the whole process up.
The phases described make use of a set of inter-process communication methods and protocols.
Lorem ipsum dolor sit amet
Lorem ipsum dolor sit amet
The FLUIDOS project is under the Apache 2.0 license. Please see details here.