Embedded Files
Use cases related to RQ1:
To answer RQ1, we consider six different search algorithms (i.e., RS, IBEA, Spread, Mono-Obj, NSGA-II and NSGA-III) and two case studies respectively representing low CPU/ high memory and high CPU/high memory as shown in Table 2 and Table 3. The number of containers we use varies from 25 to 100. We compute the mean and SD of IGD, HV, IC values, and CPU and memory usage per node for each search algorithm based on the presented data to evaluate thE effectiveness of our search algorithm compared to existing techniques. We report the execution time for each search algorithm for various numbers of containers and compare the scalability of our method to existing techniques based on the given findings.
Use cases related to RQ2:
To answer RQ2, we used an heterogeneous cluster made up of nodes (ECUs of cars provided by Ford) with varying resource limitations and more than 50 containers based different industry case studies provided by Ford. We looked at how the scheduler distributes the load among the cluster nodes in terms of CPU and memory use. Then, we compared the default Docker Swarm's scheduling outcomes to our approach. We applied ApacheBench as a stress testing tool and cAdvisor and node exporter as a monitoring tool to report the status and the performance of each working node as well as the CPU and memory usage of the cluster. Note that during the experiments, we disable the power mode to keep all containers in the candidate solution. To verify the load balancing capabilities of the scheduling, we increased the number of containers to 54 and 100. We run the experiments with three different nodes/ECUs and we compare the resource consumption by the default scheduler of the Docker Swarm to our approach for every node/ECU.
Scenario 1 : Dynamic Load and Resource balancing.
In this use case, we examine an homogeneous environment in which all nodes in the cluster have the same CPU and memory capacities. The power-saving option is turned off, and the load is not fairly spread throughout the cluster's nodes. In fact, containers in the manager consume more resources than containers on the other nodes. We execute our scheduler to examine how it would distribute containers across nodes to save CPU, memory, and power in the manager while also balancing the load in the cluster.
Scenario 2 : Fail Operational Use Case
This use case, a software upgrade or an operational failure has resulted to the isolation of the nodes out of the cluster. If the manager is the node which is isolated, another promoted ECU from the cluster must take over as the new leader. The isolation process works as follows: After all containers have been transferred from the isolated ECU and re-scheduling has been completed, the ECU is deactivated and removed from the cluster, where it will be repaired or updated. The ECU will return to the cluster once it has returned to normal.
In this case, the scheduler must notice the failure of the leader and proceed to automatically elect the new leader, which will be one of the remaining activated nodes. The scheduler then tries to distribute the containers while conforming to a few constraints. First, the old leader is eliminated from the cluster, and the container distribution is limited to the active nodes. Second, since the power mode is on, high priority containers and those with placement constraints that are run on nodes including the old leader must be maintained in the final distribution, while taking in to account the resource consumption limits.
Scenario 3 : Power Conservation
If the driver accepts the vehicle to switch to Power Conservation mode, then the scheduler chooses to put some ECUs in LPM (low power mode,i.e, decreasing their power consumption limits) and start the transfer of critical applications to the assigned ECUS and shutting down non-critical ones.
Page updated
Google Sites
Report abuse