| 6 | | |
| 7 | | == Background == |
| 8 | | |
| 9 | | High availability (HA) refers to a system and associated service implementation that is continuously operational for a long period of time. With respect to the clients, an ideal system never stops working, which also means the system will always respond to the clients’ requests. Trying to achieve high availability is therefore one of the key concerns in modern cluster computing and failover systems. Whole-system replication is a conventional way to increase the system availability—once the primary machine fails, the running applications will be taken over by its replicas (backup machines). However, there are several limitations that make this method unattractive for deployment: it needs specialized hardware and software, which are usually expensive. The final system also requires complex customized configurations, which makes it hard to manage efficiently. |
| 10 | | |
| 11 | | As virtualization becomes more and more prevalent, we can overcome these limitations by introducing the virtual machine (VM). In the virtual world, all the applications are running in the VM, so now it’s possible to implement the whole-system replication in an easy and efficient way — by saving the copy of the whole VM running on the system. As VMs are totally hardware-independent, the cost is much lower compared to the the hardware expenses in traditional HA solutions. Besides, virtualization technology can facilitate the management of multiple VMs on a single physical machine.With virtual machine monitors (VMM), the service applications are separated from physical machines, thus provides increased flexibility and improved performance. |
| 12 | | |
| 13 | | Remus, built on top of the well-known Xen hypervisor, provides transparent, comprehensive high availability by using a checkpointing method under the Primary-Backup model (Figure 1). It checkpoints the runningVMon the primary host, and transfers the latest checkpoint to the backup host as whole-system migration. Once the primary host fails, the backup host will take over the service based on the latest checkpoint. Remus proves that it is possible to create a general, fully transparent, high-availability solution entirely in software. However, checkpointing at high frequency will introduce significant overhead, since significant CPU and memory resources are consumed by the migration. Therefore, clients endure a long network delay. Jiang et. al. proposed an integrated live migration mechanism, called LLM, which integrates both whole-system checkpointing and input replay to reduce the network delay in Remus. The basic idea is that the primary host migrates the guest VM image (including CPU/memory status updates and new writes to the file system) to the backup host at low frequency. In the meanwhile, the service requests from network clients are migrated at high frequency, and because of this, LLM significantly outperforms Remus in terms of network delay by more than 90%. |
| 21 | | Therefore, in order to achieve HA in these virtualized systems, especially to address the downtime problem under memory-intensive workloads, we propose a memory synchronization technique for tracking memory updates, called Fine-Grained Block Identification (or FGBI). Our main contributions includes: FGBI tracks and transfers the memory updates efficiently, by reducing the total number of dirty bytes which need to be transferred from primary to backup host. Besides, we integrate memory block sharing support with FGBI to reduce the newly-introduced memory overheads. In addition, we also support a hybrid compression mechanism among the memory dirty blocks to further reduce the migration traffic in the transfer period. Our experimental results reveal that FGBI reduces the type I downtime over LLM and Remus by as much as 77% and 45% respectively, and reduces the type II downtime by more than 90% and 70% |
| 22 | | compared with LLM and Remus, respectively. |
| | 13 | Therefore, in order to achieve HA in these virtualized systems, especially to address the downtime problem under memory-intensive workloads, we propose a memory synchronization technique for tracking memory updates, called Fine-Grained Block Identification (or FGBI). Our main contributions includes: FGBI tracks and transfers the memory updates efficiently, by reducing the total number of dirty bytes which need to be transferred from primary to backup host. Besides, we integrate memory block sharing support with FGBI to reduce the newly-introduced memory overheads. In addition, we also support a hybrid compression mechanism among the memory dirty blocks to further reduce the migration traffic in the transfer period. Our experimental results reveal that FGBI reduces the type I downtime over LLM and Remus by as much as 77% and 45% respectively, and reduces the type II downtime by more than 90% and 70% compared with LLM and Remus, respectively. |
| | 14 | |
| | 15 | == FGBI Design == |
| | 16 | Remus and LLM track memory updates by keeping evidence of the dirty pages |
| | 17 | at each migration epoch. Remus uses the same page size as Xen (for x86, this is |
| | 18 | 4KB), which is also the granularity for detecting memory changes. However, this |
| | 19 | mechanism is not ecient. For instance, no matter what changes an application |
| | 20 | makes to a memory page, even just modify a boolean variable, the whole page |
| | 21 | will still be marked dirty. Thus, instead of one byte, the whole page needs to be |
| | 22 | transferred at the end of each epoch. Therefore, it is logical to consider tracking |
| | 23 | the memory update at a ner granularity, like dividing the memory into smaller |
| | 24 | blocks. |
