# A Comparative Analysis of High Availability for Linux Container Infrastructures
## 5 Results  
Based on the analysis of the results of the experiments carried out, the results of the service recovery time were obtained in the first scenario; after repeating this test ten times for each of the installed services and configurations, it can be concluded that in general the Proxmax VE platform takes the longest time to recover a node. The likely reason for this slowdown is due to the method that the Proxmax platform uses to recover the service, the fencing method, which attempts to recover the dropped node first and then transfer it to another machine on that node. Overall, the fastest service recovery was in the Docker environment along with its high-availability manager Docker Swarm, see Figure 7. Kubernetes only achieved second place in service recovery speed, likely due to its higher overhead services and its use of the CRI-O intermediate. Using CRI-O as an intermediate layer may introduce additional communication and processing, which may affect the service recovery rate by default. Based on the analysis of the results from the experiments performed using the second scenario focusing on the total number of failed calls, it can be concluded that the Kubernetes  
Figure 6: Measurement result using ApacheBench. Figure 7: Measuring the service recovery rate. platform using a single node had the highest number of failed calls; the total number of failed calls increased linearly on this service. In contrast, the Docker platform with its high-availability manager, Docker Swarm, had the lowest number of failures, but using up to three nodes. When using only one node, the Docker platform ranked slightly worse than the Proxmax platform; Proxmax had an average overall failure rate in the middle of all platform measurements, see Figure 8.  
Another analysis based on the second scenario using ApacheBench was the data rate analysis. From the results of the given analysis, it can be stated that the Proxmax platform obtained the highest average data transfer rate, i.e., it was able to transfer the largest amount of data in a certain time. Overall, the Kubernetes platform obtained the worst result using a single node, which had the slowest average data transfer rate. However, the services, regardless of their total number of nodes, were relatively balanced. The results are interpreted in the table, which is divided into columns with an increasing number of concurrent calls and total calls for each platform. The last column represents the mean of the results from all columns in a row. Individual results are shown for data rates in kilobytes per second, see Table 1.  
The last analysis of the results from the second scenario experiments using ApacheBench was an analysis of the average call time to a given service. Based on the results of the analysis, it can be concluded that the Proxmax platform had the longest average call time just for the impact call of 5000 concurrent calls and 10,000 total calls. In general, the impact calls of 5000 concurrent calls and 10,000 total calls appeared to be the most challenging calls to process for all services. The presumed reason why the Proxmax platform had the worst \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Simultaneous Calls/Total Number of Calls** & **5/10** & **50/100** & **500/1000** & **5000/10,000** & **5000/50,000** & **Mean** \\ \hline Docker single node & 455.57 & 783.14 & 975.55 & 85.62 & 270.84 & 514.14 \\ Docker three nodes & 476.17 & 1337.50 & 694.94 & 132.23 & 350.11 & 598.19 \\ Proxmax & 33,724.90 & 45,999.03 & 47,790.24 & 1712.38 & 8137.98 & 27,472.90 \\ Kubernetes single node & 428.22 & 634.27 & 852.74 & 472.25 & 128.30 & 503.16 \\ Kubernetes three nodes & 455.29 & 827.31 & 610.27 & 572.13 & 214.12 & 535.82 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Measurement of transfer rate in kilobytes per second. Figure 8: Measurement of the average number of failed calls. average call time result is that it does not support native load balancing, i.e., all calls go directly to a given service and have no load balancing manager.