System Management, Recovery and Security in Laboratory Environment

System Management, Recovery and Security in Laboratory Environment

Author: Ratnadeep Rajendra Kharade

Introduction and Problem Statement

Digitalization is rapidly changing the functioning of businesses and industries. All major sectors including education sector are affected due to digitalization. Digital laboratories are a milestone in achieving digitalization in education.

Unlike traditional software systems, laboratory systems are complex in nature. They are based on different IoT devices, sensors, and robots. They include various computing devices such as mobile devices, higher configuration servers and low-end computing devices like Raspberry Pi. These devices communicate with each other via network. Laboratory systems needs to be always available. Softwares in such systems are based on different programming languages.

Due to the complex structure, it is often complicated to manage applications, system resources and system communication in laboratory environment. System can fail due to code errors, insufficient resources, and other reasons. In this case software recovery is important as these systems needs to be highly available. Also, large number devices, applications and programming languages may introduce security issues in laboratory systems.

Software Systems in laboratory environment

Two major system architecture are used for software systems 1. Monolithic 2. Microservices. As laboratory systems include distributed independent softwares, microservice architecture is more suitable.

In terms of software environment, there are many approaches available such as traditional deployment, virtualization, and containerization. Traditional approach includes deployment of applications directly on Operating System (OS) which can create platform dependence and reduce portability of applications. Virtualization enables creation of Virtual Machines (VMs). VMs isolate the software inside guest OS with dedicated resources. Virtualization again has drawbacks such high resource requirements which is not efficient in laboratory environment which include devices with lower resources. Using containerization, platform independent microservices can be created. A container engine manages resources for containers which makes containerized deployments lightweight. So, containerization is best suited in laboratory environment.

Docker is a popular container engine which has features for building images, running containers. Docker also provides image registry where built application images are stored. But Docker has some limitations when it comes to building applications which support multiple architectures e.g AMD and ARM (Raspberry PI). To overcome this, Docker provides a special plugin ‘buildx’ which enables creation of multi-arch images.

Containerization also has some limitations. Managing the large number of applications becomes difficult in distributed systems. Accessibility and communication between the applications is not straightforward. There are various ways to overcome these limitations such as Docker compose which can deploy multiple application using single file and Container Orchestration which is most suitable in laboratory environment for distributed systems.

Container Orchestration has many benefits such as automated application deployments, scaling of applications, networking and communication, resource management. Various container orchestration tools are available such as Kubernetes (K8S), Docker Swarm, Apache Mesos. These tools are compared based on different use cases such as resource management, application scheduling and service management. Kubernetes was selected as it has more features as compared to others and huge community support. Most of the cloud providers use Kubernetes for container orchestration e.g. Amazon Elastic Kubernetes Service (EKS).

Kubernetes provides features such as self-healing of applications, application scaling, application rollout and rollbacks and application security. There are many Kubernetes tools available such as Kubeadm, K3S, Kind, Minikube, Microk8s. These tools support different use case for example Kubeadm supports production grade cluster whereas Minikube and Kind are suitable for development environment. Microk8s was selected as it is lightweight and supports multiple architectures AMD and ARM which is an important use case in laboratory environment.

Software management, recovery, and security

Kubernetes can be used to create a multimode distributed cluster for deploying applications. Applications can be deployed, scaled, and updated efficiently using Kubernetes. Kubernetes dashboard provides an overview of the complete system in terms of applications and resource utilization.

Application recovery and failure prevention: Kubernetes monitors the state of containers and it automatically restarts failed containers. Also, microk8s automatically creates highly available cluster when there are more than 2 nodes in cluster. Whenever a node fails, all the application running on that server are rescheduled on available servers. Failure prevention can be done by adding multiple replicas and enabling automatic scaling of application.

Kubernetes creates services for accessing applications. By default, applications can only be accessed by other applications in same cluster and not from outside. This provides security to applications. Kubernetes also provides option to store information securely via ‘Secrets’.

Implementation and results

Microk8s was used to create a Kubernetes cluster. Three Raspberry Pi devices are used as nodes. Applications with different programming environment were used mainly java, and JavaScript. Results were recorded for different number of applications. It was found that, the 3 node Kubernetes cluster was able to host around maximum 60 applications (40 NodeJS, 20 Spring Boot) successfully in 200 seconds. The recovery results were noted based on failure use cases (application process failure, container deletion). The lowest time to recover NodeJS application was 7 seconds and highest time was 21 seconds. Which was around 50 seconds for Spring Boot application. Also, it was found that resource utilization for Spring Boot application was significantly higher than that of NodeJS application.

About Author:  Ratnadeep Rajendra Kharade is a master thesis student at Digilab4U project in HFT, Stuttgart. The thesis is submitted in fulfilment of the degree of Master of Science in Software Technology. Author has around 6 years of experience in Software Development.

Leave a Reply