Article Preview
TopIntroduction
In the realm of cloud computing (CC) architectural design, virtualization serves as a fundamental principle, facilitating the transition from on-premise infrastructure to a scalable model of remotely connected services. The isolation of machines and applications is crucial to ensuring the delivery of computing resources through an on-demand network infrastructure. Traditionally, a hypervisor is responsible for creating and managing virtual machines (VMs) that host applications and handle client requests. This approach is primarily suitable for conventional monolithic architecture-based applications, where all software components are designed, built, deployed, and managed as a single unit codebase (Guo & Yao, 2018). However, a recent paradigm shift has occurred with the introduction of container-based microservices. This approach allows applications to be allocated on multiple lightweight containers, distributed across a large number of nodes (Thongthavorn & Rattanatamrong, 2019). Regardless of whether deployment is VM-based or container-based, cloud services providers (CSP) are expected to ensure system availability and throughput for different customers under a contracted service level agreement (SLA) acceptance criterion. Load balancing (LB) algorithms play a vital role in guaranteeing quality of service (QoS) metrics and maximum availability of the cloud platform. The primary objective is to prevent any server from becoming overloaded or underloaded. LB algorithms aim to distribute tasks as evenly as possible across a set of nodes or computing resources (Sahana & Mukherjee, 2020), thereby enhancing business efficiency and reducing the overall makespan of the CC system. During the process, priority of each incoming task and its characteristics are taken in consideration (Thongthavorn & Rattanatamrong, 2019). When considering LB techniques, it is essential to address two key steps: (1) resource allocation and (2) VM/container live migration. Resource allocation involves the fair distribution of jobs in the queue to servers, VMs, or containers based on the system's current state and the hardware capability of the hosts. This step ensures that jobs to resources are allocated efficiently and effectively. The task scheduling process is considered NP-hard problem where state-of-the-art applied strategies need to be improved (Aliyu et al., 2020). On the other hand, VM/container live migration enables the real-time transfer of application execution contexts, either from one physical host to another or within the same host, without disrupting the user experience. Several LB algorithms have been proposed in the literature for the same purposes, addressing both use cases of (VM) and container-based cloud systems.
Our Contribution
In this paper, our focus is on the container-based approach. We introduced a novel load balancing algorithm called Resource-Aware Least Busy (RALB), which aims to efficiently allocate and distribute container workloads among servers in the load balancing process. The “Resource Aware” keyword incorporates real-time monitoring of server’s resource usage (CPU, memory, and bandwidth) before proceeding to any load balancing decision. The term “least busy” highlights the algorithm's core principle of allocating containers to servers with the lowest workload from a resource perspective. By considering server resources and allocating containers to the least busy server capable of meeting the container's requirements (CPU, memory, and bandwidth), RALB optimizes resource utilization and achieves effective load balancing. This approach sets it apart from the “least connection” algorithm, which predominantly considers the number of active connections. The rest of paper is organized as follows: Firstly, we will underline the container solution compared to standard virtualization with highlight to related LB works in containerization, then follow with a section describing the system model of the proposed algorithm. Subsequently, we will present the experimental results for the RALB alongside with comparison charts. Finally, we conclude our work and provide directions for improvements in the last section.