Changes between Version 9 and Version 10 of FGBI


Ignore:
Timestamp:
09/27/11 23:46:36 (13 years ago)
Author:
lvpeng
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FGBI

    v9 v10  
    1111Regarding the type II downtime, there are several migration epochs between two checkpoints, and the newly updated memory data is copied to the backup host at each epoch. At the last epoch, the VM running on the primary host is suspended and the remaining memory states are transferred to the backup host. Thus, the type II downtime depends on the amount of memory that remains to be copied and transferred when pausing the VM on the primary host. If we reduce the dirty data which need to be transferred at the last epoch, then we can reduce the type II downtime. Moreover, if we reduce the dirty data which needs to be transferred at each epoch, trying to synchronize the memory state between primary and backup host all the time, then at the last epoch, there won’t be too much new memory update that need to be transferred, so we can reduce the type I downtime too.
    1212
    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 
    1513== FGBI Design ==
    16 Remus and LLM track memory updates by keeping evidence of the dirty pages
     14Therefore, 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). Remus and LLM track memory updates by keeping evidence of the dirty pages
    1715at each migration epoch. Remus uses the same page size as Xen (for x86, this is
    18164KB), which is also the granularity for detecting memory changes. However, this