## 6 Experiment
### LSTM-Based Scheduling
The \"requests\" and  
Figure 10: Architecture used in the LSTM-based scheduling experiment. \"limits\" represent the CPU usage request and maximum limit, respectively. By adjusting these values and running them, the CPU-utilization rates of each cluster can be manipulated. In the example, the \"requests\" and \"limits\" were set to 200 m to achieve 5% utilization of the total 4 vCPU of the cluster. Figure 12 shows the flowchart of the LSTM-based scheduling experiment. In the figure, green represents the systems we added, orange represents Velero, and blue represents components of Rancher. Solid arrows represent the flow of backup file data, while dashed arrows indicate communication, commands, and similar actions. Velero, connected to the AWS S3 bucket, is installed in all clusters. In step 1, Cluster 6 uses Velero to create a backup file of the application running in it in the S3 bucket. In step 2, if Cluster 6 loses functionality due to a disaster, Rancher detects this. In step 3, the detected status of Cluster 6 changes to disconnected, triggering the auto-recovery system. In step 4, the auto-recovery system uses Velero to look up the latest backup file of Cluster 6. In step 5, the restore command, including the name of this backup file, is transmitted to the target cluster selected through LSTM-based scheduling. In the figure, it is transmitted to Cluster 1, which has the lowest predicted CPU usage. In step 6, the target cluster executes the received command, using the backup file in the S3 bucket to restore the application that was running in Cluster 6 to the target cluster. Figure 11: Dummy application YAML. Figure 12: Flowchart of the LSTM-based scheduling experiment. The procedure of the LSTM-based scheduling experiment is as follows. First, a dummy application is run on Cluster 6. This running application is backed up to the AWS S3 bucket by using the Velero backup command. Then, the master node of Cluster 6 is stopped to disconnect it from the Rancher cluster. After the Rancher cluster detects the disconnection, our automatic recovery system is initiated for the cluster. As Cluster 6 contains a total of 4 vCPU, and Clusters 1, 2, 3, 4, and 5 each have 4 vCPU allocated, they are all potential restoration targets. In this experimental environment, multiple target clusters are available for restoration, and thus scheduling is conducted. The current CPU-utilization rates of the clusters are used as input values for the LSTM-based CPU prediction. The cluster with the lowest predicted CPU-utilization rate is selected as the target cluster. Then, Velero in the Rancher cluster queries the latest backup file of the dummy application in the S3 bucket and sends the restoration command, including the name of the backup file, to the target cluster. The target cluster executes the received command, restoring the dummy application running on Cluster 6 by using the backup file in the S3 bucket. In our study, this experiment was conducted \(10\) times, measuring the CPU-utilization rates of the clusters each time. Additionally, an experiment in which the target cluster was randomly selected instead of using LSTM-based scheduling was conducted \(10\) times in the same manner. These two experiments are compared and analyzed in Section 7.