MYRTUS Cognitive Engine
To achieve flexibility and overcome the current silos-like management of services, we propose the MIRTO cognitive engine. MIRTO is meant to push runtime adaptivity between and across layers. Resources will be monitored, and runtime orchestration guaranteed to achieve high performance and energy efficiency, preserving security and trust. Extensive use of federated learning and distributed strategies will be done to successfully optimize loads and more effectively use the available continuum.
Figure 1. MYRTUS Pillar 2 overview
MIRTO cognitive engine is responsible for high-level continuum orchestration both at deployment time (when a computation request is issued) and at execution time (while tasks are already running). This dynamic orchestration entails four steps executed in loops:
- sensing of internal and external triggers for the orchestration;
- evaluation of aggregated local and global information;
- decision for resource allocation/configuration to improve KPIs;
- reconfiguration/reallocation.
Four primary drivers for optimization are there: optimal workload execution (e.g. improving throughput and/or latency), optimal network usage (e.g. reducing network congestion, while guaranteeing adequate computing power), optimal node configuration (e.g. trading-off QoS to minimize energy consumption in specific components), and privacy and security guarantees (e.g. changing the adopted set of components according to the requirements of a newly incoming task).
The preliminary architecture of a MIRTO Cognitive Engine agent is depicted in Figure 2. At all layers, the MIRTO agents communicate with each other to negotiate the usage of resources and interoperability of services over multiple layers.
Figure 2. MIRTO Agent.
At this stage, this is the initial architecture proposal:
MIRTO Agent – Creates a MIRTO Application Programming Interface (API) Daemon defining the MIRTO agent as a (web-)service with a specification for its API. This REST-like API establishes how users will request orchestration activities to the MIRTO agent using a TOSCA Object Model. It also provides a security module for user authentication (Authentication Module) and TOSCA description validation (TOSCA Validation Processor).
MIRTO Manager – Unifies the four optimization drivers into the MIRTO Manager (whose internal architecture is currently under definition) that is responsible for deciding on the allocation of resources managed by the agent and/or on the configuration of the specific target chosen for execution.
Proxies – Proposes interface points (proxies) to the KB and the deployment mechanism. This latter embodies the MYRTUS continuum life-cycle controlling strategy based on LIQO.
LIQO allows for clustering and resource virtualization. It constitutes the interface among MIRTO agents and Kubernetes-based orchestration achieving seamless virtualization of the underlying infrastructure. Such a seamless virtualization will stretch till edge nodes, including FPGA-based ones which are already been made compatible with the Kubernetes environment.
To foster interoperability and portability, the interfaces between the components in the MYRTUS infrastructure and the MIRTO agents are defined in an implementation-agnostic and target-independent manner.
