The main purpose of a Service-Level Objective (SLO) is ensuring that the system remains in optimal (or near-optimal) condition for the duration of its desired duty cycle. In the case of the third RAINBOW use case, that is performing data acquisition, while network topology and the physical instances of several nodes are volatile.
One of the driving ideas behind the overall system design is to be able to relocate the drones as data acquisition progresses along the power line, without disturbing the compute-level objectives at the application layer.
This means that nodes will be shut down, moved towards the other end of the power line and redeployed. This means that there will be no central node where the Mission Guidance service can run.
The physical network topology is linear. Nodes will be deployed along the power line and daisy-chained with point-to-point network links. If the node hosting the Mission Guidance service gets deployed on one of the edge nodes, messages from the nodes at the other end will have to travel through all the nodes. A much better solution is to make RAINBOW keep this service deployed a node at the middle of the physical deployment.
This requirement for the solution of the above-mentioned issue can be achieved with the definition of SLOs that consider the network latency observed at the link with other nodes.
The exact settings will be prepared and applied when the physical demonstrator is ready, since in virtual demonstrators the nodes cannot be physically relocated.
However, for the current development state, we have laid down some considerations for the SLO’s to be applicable in the physical demonstrator:
For example, lets define an SLO requiring there to be one Instance per Node Type:
- The SLO target will be the Radio Gateway service.
- Required resources will include the radio modem.
- The considered elasticity strategy will be horizontal scaling
Additional service graph node configuration: set affinity to allow only one pod per node.
RAINBOW reduces the overhead associated with the abode-described process, as its policy editor has been updated and integrated with the rest of the platform so that policies and SLOs can be visually created and applied through it. Moreover, the analytics and SLO editors are extended and significantly improved, so that more complex SLOs can be supported and tested.
