TNO – MIRTO Agent and Deployer: entry point and coordination of the cognitive engine
| ID: R27 | Licence: To be defined |
Owner: TNO |
Contacts: bart.driessen@tno.nl |
| Short Description | The MIRTO Agent is the core service of the MIRTO cognitive engine: it coordinates all the managers and is the access point to start, update and stop applications on the MYRTUS computing continuum, using a TOSCA-compatible interface. The Deployer turns the resulting allocation into deployments on the Kubernetes clusters federated by Liqo, independently of the layer (cloud, fog or edge). | |
| MIRTO Agent | Deployer | |
|---|---|---|
| Key features | – Intake and validation of TOSCA service specifications (CSAR packages, e.g. exported with the Modelio TOSCA Designer), translated into a service chain – Coordination of the Workload Manager (swarm-based, DCOP-based or DRL-based), Network Manager and Privacy and Security Manager – Closed control loop: continuous check of the system status and reallocation when needed – Modular architecture with well-defined REST interfaces and a common information model – Centralized, layer-centric or redundant deployment of the agents | – Deployment of the allocation map on Liqo-federated Kubernetes clusters – Same interface for cloud, fog and edge resources – Placement on a specific node of a remote cluster, with the Liqo Node Binding Module – Resource information shared through the Distributed Knowledge Base |
| Require | A Deployer, Distributed Knowledge Base and Resource Registry service points, and at least one Workload Manager. | Kubernetes clusters federated through Liqo; Distributed Knowledge Base. |
| Provide | An interface to start, update, stop and monitor applications on the continuum. | Deployment of the software components on the selected compute nodes. |
| Input | TOSCA model of the application (CSAR file): service chain components, their alternative software implementations and requirements; current system status. | Allocation map from the MIRTO Agent. |
| Output | Allocation map passed to the Deployer; status of the deployed application. | Kubernetes deployments of the software components on the target nodes. |
| User | Software specialists who install, monitor and troubleshoot applications on the MYRTUS continuum. | MIRTO Agent. |
| Benefits for the user | The user focuses on the service chain and its requirements, while the exact deployment details are optimized automatically. | Deployment independent of where the compute resources are: cloud, fog or edge. |
| Download | Please contact the developers listed above. | Please contact the developers listed above. |
| Role in MYRTUS | Core service of the MIRTO cognitive engine: entry point and coordination of the orchestration. | Standard interface between MIRTO and the federated MYRTUS infrastructure. |
| TRL@M0 | To be defined | |
| TRL@M36 | To be defined | |
General description
MIRTO Agent
When an application is deployed on a MYRTUS-compliant continuum, the operator focuses on the service chain and its requirements, while the deployment details are optimized automatically. The MIRTO Agent is where this process starts: an authorized user submits the application as a TOSCA model, prepared for example with the DPE, through a standardized interface. The agent parses and validates the specification, turns it into a MIRTO model of the service chain and, together with a snapshot of the current system status, sends it to the Workload Manager (swarm-based, DCOP-based or DRL-based), which returns an allocation map. The Network Manager and the Privacy and Security Manager contribute to this decision. In the TOSCA model, compute nodes are described as placeholders: the agent instantiates them with concrete hardware according to the placement of the software components.
The agent then passes the allocation to the Deployer, and keeps checking the status of the system, collected by the monitors and stored in the Distributed Knowledge Base and exposed by the Resource Registry. If the application no longer behaves as intended, for example because a compute node runs out of resources, it uses the Workload Manager and the Deployer again to update the allocation.
Deployer
The Deployer ensures that the software components are correctly deployed on the MYRTUS infrastructure. It receives the allocation map from the MIRTO Agent and generates the corresponding Kubernetes manifests. Thanks to Liqo, resources of the cloud, fog and edge layers appear as virtual Kubernetes nodes, so the Deployer acts as a standard interface to deploy components independently of where they run.
Since a virtual node represents a whole remote cluster, placement is performed in two steps: node affinity selects the virtual node, and the Liqo Node Binding Module binds the workload to the actual target node in the remote cluster, for example an FPGA-based edge node, where the Node Manager takes over local optimization.
MYRTUS Extension/Contribution
MIRTO Agent
Within MYRTUS, the architecture of the MIRTO Agent and its interfaces with the managers and with the reference infrastructure have been finalized. The common information model, inspired by the OASIS TOSCA standard, describes service chains, service chain components with their alternative software implementations and requirements, compute nodes and networks, their status, and the resulting allocation map. All components communicate through REST interfaces, exchanging JSON data.
The complete flow has been demonstrated with the integrated components and the DCOP-based Workload Manager: a TOSCA specification is uploaded to the agent, the Workload Manager computes the allocation, the Deployer deploys the components, and after a change in the workload of one component a new allocation gives it more resources. On the design side, the CSAR packages exported by the Modelio TOSCA Designer of the DPE have been validated against the deployment interface of the MIRTO Agent; this exercise also clarified which compute-node placeholders the agent needs at deployment time.
Deployer
The Deployer has been integrated with the Liqo-based federation of the MYRTUS reference infrastructure: it stores resource information in the Distributed Knowledge Base, where the Resource Registry makes it available to the agent, and it can target local resources and resources of remote clusters with the same orchestration workflow.
Deployment configurations
The MIRTO Agent can be deployed in different configurations, depending on operational needs:
- Centralized: a single agent orchestrates all the resources of the continuum through one Deployer, offering one simple entry point.
- Layer-centric: each layer has its own agent, managing a subset of the resources; agents can request each other’s resources through their Workload Managers.
- Redundant: several independent agents share the same Deployer and resources, improving availability and resilience; this is the natural setting for the swarm-based Workload Manager.
In all cases, the agents rely on one Distributed Knowledge Base, reached through service points that can be placed at any layer.
Technology Benefits and Innovations
The MIRTO Agent is not a monolithic orchestrator: it delegates each responsibility to a separate service with a well-defined interface. This makes the behaviour of the cognitive engine transparent, and allows individual components, such as the Workload Manager, to be replaced or updated without affecting the rest of the system. Like intent-driven orchestration approaches, it lets users express what an application needs rather than how to deploy it, and then relies on Kubernetes and Liqo for the low-level deployment; in addition, it brings energy, network, and privacy and security requirements into the same closed control loop.
Users
Operators of computing continuum infrastructures and developers of distributed applications who want requirement-driven, automated deployment across cloud, fog and edge resources, based on standard TOSCA descriptions and Kubernetes. The modular architecture is also relevant for integrators of orchestration platforms that need to combine different optimization strategies behind a common interface.
Application Domains
Applications operating in dynamic environments, where conditions such as network quality and workload change quickly and resources span from edge devices to the cloud, for example smart mobility, telemedicine and autonomous systems.
