The Edge storage component has the goal of providing an edge storage framework that can support the QoE needs of the users, optimizing resource usage in the edge devices and networks. We have two possible base technologies for this; the MinIO [2] and OpenStack [3] platforms that enable us to create highly distributed, lightweight and scalable storage clusters, using Kubernetes as an orchestrator. The final choice of the tool will be made after running a number of experiments, testing their effectiveness and optimizing their configuration for scenarios close to the real use cases that the ACCORDION will be called to handle.
After the choice of the appropriate technology and configuration, a middleware layer will be added between the VIM and storage components in order to expose specific, role-based APIs that ensure security of the data, integrity of the system, optimized QoE for the users, fault proofing, fault tolerance, intelligent caching and other relevant functionalities.
The component will use the Kubernetes ecosystem by using the Kubernetes master as the storage controller, storage UI access point and Prometheus master for the specific cluster. Each node that is connected to the Kubernetes cluster has the potential of becoming a storage worker for this cluster or/and for the ACCORDION ecosystem. This is enabled by defining a custom label for the node, enrolling it as a storage worker. As a node, we define a Kubernetes node, which can be a PC, laptop, IoT device or any other compatible device. In order to be eligible for the role of storage worker, a node must have sufficient hard disk space available. The amount of space is highly dependent on the use case, so it is not pre-configured. In the next figure (Figure 1), we can see a high-level architecture of the module with the interconnections between the sub-modules.
Figure 1 Edge Storage component architecture
We have isolated four actors that are using the services of the Storage module; the VIM, the Prometheus Aggregator, the Mini-cloud Administrator and the ACCORDION Administrator. VIM will be using the APIs exposed by the component in order to perform automated or semi-automated processes or even expose the functionalities in other interfaces or components. A draft of the APIs that will be exposed by the component is included in Table 1 at the end of this chapter. The Prometheus Aggregator will access the endpoint provided by the cluster Prometheus master in order to scrape the data and collect them in an aggregated database that collects information from all the ACCORDION mini-cloud clusters. The Mini-cloud Administrator will be using the storage UI in order to manage the storage cluster and the data in it for administrative purposes.
The ACCORDION Administrator will also be using the storage UI in order to manage and monitor the data and the cluster in accordance with the general ACCORDION needs. In the following UML (Figure 2), we can see a visual representation of these relations.
Figure 2 Edge storage use cases and actors