Accelerated coding for virtual machine synchronization

Abstract

The present disclosure includes a virtual machine (VM) memory synchronization process for improved fault tolerance. The process includes writing, by an intelligent memory controller (IMC), current snapshot data to a first series of contiguous memory addresses, wherein the current snapshot data is received by the IMC from a memory of an active VM via a direct memory access (DMA) transfer operation. The IMC executes a concurrent thread associated with a respective span of contiguous memory addresses, where the concurrent thread controls a compression process of a respective portion of the current snapshot data, resulting in a corresponding portion of processed current snapshot data, wherein the concurrent threads include threads bound to a hardware accelerator that performs compression processing of a portion of the current snapshot data. The process then communicates the processed current snapshot data as a current synchronized snapshot of the active VM to the backup VM.

Description

Background Art

[0001] The present invention generally relates to methods, systems and computer program products for virtual machine and computer cluster management. More specifically, the present invention relates to methods, systems and computer programs for accelerated encoding of virtual machine synchronization.

[0002] A virtual machine (VM) is a software-defined computer and client OS that runs on a host system that operates its own host OS. A VM includes virtualized representations of various components of a data processing system. Typically, a VM provides a software execution environment and may have a virtual processor, virtual main memory, virtual disk storage devices, and possibly various other virtual devices. A VM represents a form of system virtualization implemented through some management functions (usually hypervisor technology).

[0003] A host system is a data processing system such as a server. A host system may have any number of VMs configured on it, depending on the available system resources of the host and the needs of the VMs. For example, in a large-scale data processing environment such as a data center, hundreds or thousands of VMs may be operating on a host at any given time, and hundreds or thousands of such hosts may be operating in a data center at any given time. Large-scale virtualized data processing environments such as these are able to provide computing resources to many different clients as needed. Summary of the invention

[0004] An illustrative embodiment provides accelerated coding for virtual machine synchronization. One embodiment includes writing current snapshot data to a first series of continuous memory addresses by an intelligent memory controller (IMC), wherein the current snapshot data is received by the IMC from the memory of an active virtual machine (VM) via a first direct memory access (DMA) transfer operation. The embodiment also includes executing a concurrent thread associated with a corresponding span of the continuous memory addresses by the IMC, wherein the concurrent thread controls compression processing of a corresponding portion of the current snapshot data, thereby generating a corresponding portion of the processed current snapshot data, wherein the concurrent thread includes a first thread bound to a hardware accelerator, and the hardware accelerator performs compression processing of a first portion of the current snapshot data. The embodiment also includes transmitting the processed current snapshot data to a standby VM as a current synchronization snapshot of the active VM. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the embodiment.

[0005] Embodiments include a computer usable program product. The computer usable program product includes a computer readable storage medium and program instructions stored on the storage medium.

[0006] An embodiment includes a computer system. The computer system includes a processor, a computer-readable memory, a computer-readable storage medium, and program instructions stored on the storage medium for execution by the processor via the memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The novel features which are believed to be characteristic of the invention are set forth in the appended claims. However, the invention itself, together with its preferred mode of use, further objects and advantages will be best understood by reference to the following detailed description of illustrative embodiments taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 Depicting a cloud computing environment according to an embodiment of the present invention;

[0009] Figure 2 An abstract model layer according to an embodiment of the present invention is shown;

[0010] Figure 3 depicts a block diagram of an example cloud computing environment in accordance with an illustrative embodiment;

[0011] Figure 4 A block diagram of an example VM environment is depicted in accordance with an exemplary embodiment;

[0012] Figure 5 A block diagram of a VM environment according to an exemplary embodiment is depicted;

[0013] Figure 6 A block diagram of an example VM environment is depicted in accordance with an exemplary embodiment;

[0014] Figure 7 A block diagram of a VM environment according to an exemplary embodiment is depicted;

[0015] Figure 8 A block diagram of a VM environment according to an exemplary embodiment is depicted;

[0016] Fig. 9 A block diagram of a VM environment according to an exemplary embodiment is depicted;

[0017] Fig.10 A block diagram of a VM environment according to an exemplary embodiment is depicted;

[0018] Fig.11 A flowchart depicting an example process for an encoding process according to an illustrative embodiment; and

[0019] Fig.12 A flow chart of an example process for a decoding process is described in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0020] The active-standby scheme is an example of a high availability architecture for VMs where the standby VM periodically synchronizes with the active VM in use. The periodic synchronization typically involves updating the main memory (e.g., DRAM) and CPU state of the standby VM to match that of the active VM. This synchronization can be achieved by using page tables and software to identify the "dirty" memory pages of the active VM and then copying them to the standby VM.

[0021] Maintaining a periodically synchronized standby VM reduces the amount of data that needs to be transferred during a VM failover, thereby reducing the period that the VM is suspended during the migration. However, this technique has problems that negatively impact the functionality of the VM due to inefficiencies in the synchronization process. For example, these types of active-standby techniques use a synchronization process that involves a large amount of page table traversal and data copy overhead, resulting in considerable VM downtime. The main reason for this overhead is that many applications using this approach incur data copy amplification due to copying more data than necessary; this arises from the design of the processor's virtual memory system, where memory pages are 4KiB or larger. For example, a single byte written to a page causes a full 4KiB (or larger) page to be copied during the next synchronization.

[0022] Aspects of the present disclosure address the above-mentioned deficiencies by providing mechanisms (e.g., systems, methods, machine-readable media, etc.) that perform high-frequency memory synchronization more quickly and efficiently than the prior art. The present disclosure recognizes that existing page protection can be used to reduce the number of pages that are compressed (i.e., only pages marked as dirty are processed) for synchronization. The present disclosure also recognizes that a host-to-device DMA engine can be used to pack (aggregate) sparse dirty pages of the active VM main memory so that they are consistent with intensive data calculations that a hardware accelerator (e.g., a GPU or FPGA) is suitable for processing. This in turn allows the compression workload to be divided into blocks of packed data to support data parallelism. The output segment buffer can then be used to collect the encoded (compressed) data into continuous memory for transmission to the standby VM. The present disclosure also recognizes that once the memory data has been copied to the hardware accelerator for compression, the active VM can continue to assume that the period is greater than the total time it takes for the hardware accelerator to encode the data and the data to be transferred to the standby VM.

[0023] Based on these observations, the mechanisms of the present disclosure provide synchronization techniques that significantly reduce the amount of time involved in generating synchronized snapshots of VM main memory and CPU states. The mechanisms of the present disclosure also provide synchronization techniques that significantly reduce the amount of data transmitted to a standby VM for synchronization. These mechanisms of the present disclosure result in a synchronization method that reduces the downtime caused by synchronizing a standby VM with an active VM, and allows the use of the disclosed synchronization techniques to deploy active-standby solutions on networks with more limited bandwidth (e.g., across data centers), which is not feasible when using previous synchronization techniques.

[0024] Where a computer or data processing system is described as a virtual machine, virtual device, or virtual component, the virtual machine, virtual device, or virtual component operates in the manner of the data processing system using virtualized representations of some or all of the components of the data processing system. For example, in the virtual machine, virtual device, or virtual component, a processing unit is represented as a virtualized instance of all or some number of hardware processing units available in the host data processing system, main memory is represented as a virtualized instance of all or some portion of main memory available in the host data processing system, and disk storage devices are represented as virtualized instances of all or some portion of disk storage devices available in the host data processing system.

[0025] In an illustrative embodiment, the active-standby synchronization process includes once per epoch, the active host suspends the running active VM and identifies pages of VM memory that have changed during the current epoch (i.e., dirty pages). In some embodiments, after the active VM has been suspended, the VM cache is flushed and the hypervisor iterates through a dirty page bitmap (a collection of bits representing the clean / dirty state of each page in the guest VM memory). Next, the synchronization process uses the dirty page bitmap to construct a segment list, which is an array of non-contiguous dirty spans, where each element of the array includes a corresponding segment offset, length pair corresponding to an identified contiguous dirty span in VM memory (i.e., two adjacent dirty pages are grouped into the region defined by the element of the array).

[0026] In an illustrative embodiment, the synchronization process includes a DMA controller that performs DMA transactions to transfer non-contiguous dirty spans of VM memory to a series of contiguous memory addresses of a guest current memory buffer of an intelligent memory controller (IMC). In some embodiments, a segment list is used to copy the contents of the non-contiguous dirty spans in a packed form (i.e., at contiguous addresses) to the guest current memory buffer of the IMC via the DMA transactions. In addition, the segment list is then used to copy the contents of the non-contiguous dirty spans to the guest current memory of the active host.

[0027] In an illustrative embodiment, the IMC includes a processor, preferably a hardware accelerator such as a GPU or FPGA, which performs multi-threaded parallel encoding processing of dirty pages received from an active host. The data in the current memory buffer of the VM client and the previous memory buffer of the client are all packed so as to occupy a continuous span of memory addresses in each buffer. The packed data is logically divided into "blocks" that can be encoded by separate threads. In some embodiments, the block information buffer stores information about each block, such as multiple segment offsets and length pairs corresponding to the corresponding block. The size of the block must be sufficient to provide the granularity required for parallelization across N worker threads, where N is the limitation of the underlying hardware (for example, nominally 2048 threads for a GPU). For example, in some embodiments, each individual thread performs encoding on one or more blocks and creates a block-level result in a pre-transmitted encoded delta buffer. In some embodiments, the encoding includes XOR-RLE encoding. Although the illustrative embodiment is described herein as using XOR-RLE encoding, other types of encoding can be used in alternative embodiments. For example, an alternative embodiment uses LZ4 or DEFLATE encoding with or without XOR.

[0028] The number of worker threads N can vary significantly for different target devices, as small as 8-16 for typical FPGAs, limited by the concurrent memory accesses the device can support. In this case, we can use sub-threads (sub-kernels) to pipeline memory accesses within a thread, thereby achieving a much higher number of logical threads.

[0029] In an illustrative embodiment, the synchronization process proceeds based on the comparison of the size of the XOR+RLE compressed block with the original block size. If the compressed version is larger, for example due to high entropy modification, the original contents of the block (in the client current memory buffer) are copied to the pre-send encoded delta buffer on the IMC. Otherwise, the compressed version is copied to the pre-send encoded delta buffer. This comparison is performed for each block individually until they have all been processed and stored in the pre-send encoded delta buffer.

[0030] In an illustrative embodiment, the synchronization process transfers the contents of the pre-sent encoded delta buffer back to the encoded delta result buffer on the active host. The process then transfers the results of the encoding process as a memory snapshot to the standby host to decode and update the VM memory of the standby VM.

[0031] In an illustrative embodiment, a standby host receives a memory snapshot from an active host. The standby host then iterates through each segment of the snapshot's blocks. For each segment, the process is performed based on whether the current evaluation segment is XOR-RLE encoded or plaintext data. If it is encoded, the standby host performs a decoding process on the data segment, such as by performing an RLE expansion on each block marked as compressed. Next, the decoder performs an XOR operation on each block marked as compressed. In some embodiments, the XOR operation is performed directly in the standby guest VM main memory at a location indicated by the segment information offset in the segment information transmitted by the active VM with the memory snapshot. Conversely, if the segment is plaintext data, the plaintext value of the data is extracted from the segment and copied to the memory area obtained by parsing the original segment list. Iteration of the process continues until all synchronization data has been processed and updates are applied to the standby VM's memory.

[0032] For the sake of clarity of description, and without implying any limitation thereto, some example configurations are used to describe the illustrative embodiments. Based on this disclosure, those skilled in the art will be able to conceive of many changes, adaptations and modifications of the configurations for achieving the described purposes, and these are considered to be within the scope of the exemplary embodiments.

[0033] In addition, simplified diagrams of data processing environments are used in the drawings and illustrative embodiments. In an actual computing environment, there may be additional structures or components not shown or described here, or structures or components that are different from the structures or components shown but are used for functions similar to those described here, without departing from the scope of the illustrative embodiments.

[0034] In addition, the illustrative embodiments are described only as examples with respect to specific actual or hypothetical components. Any particular manifestation of these and other similar artifacts is not intended to limit the present invention. Any appropriate manifestation of these and other similar artifacts may be selected within the scope of the exemplary embodiments.

[0035] The examples in this disclosure are only for clear description and are not intended to limit the illustrative embodiments. Any advantages listed herein are only examples and are not intended to limit the illustrative embodiments. Additional or different advantages can be achieved through specific illustrative embodiments. In addition, specific illustrative embodiments may have some, all, or none of the advantages listed above.

[0036] Furthermore, the illustrative embodiments may be implemented for any type of data, data source, or access to a data source over a data network. Any type of data storage device may provide data to embodiments of the present invention locally at a data processing system or over a data network within the scope of the present invention. Where embodiments are described using a mobile device, any type of data storage device suitable for use with the mobile device may provide data to such embodiments locally at the mobile device or over a data network within the scope of the illustrative embodiments.

[0037] Illustrative embodiments are described using specific codes, computer-readable storage media, high-level features, designs, architectures, protocols, layouts, schematics, and tools, which are examples only, rather than limitations on the illustrative embodiments. In addition, for clarity of description, specific software, tools, and data processing environments are used in some instances to describe the illustrative embodiments only as examples. The illustrative embodiments can be used in conjunction with other comparable or similar purpose structures, systems, applications, or architectures. For example, within the scope of the present invention, other comparable mobile devices, structures, systems, applications, or their architectures can be used in conjunction with such embodiments of the present invention. The illustrative embodiments can be implemented in hardware, software, or a combination thereof.

[0038] The examples in this disclosure are only for clear description and are not limited to the illustrative embodiments. Additional data, operations, actions, tasks, activities and manipulations can be imagined from this disclosure and can be envisioned within the scope of the illustrative embodiments.

[0039] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings set forth herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0040] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the provider of the service. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0041] Features are as follows:

[0042] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed without requiring manual interaction with the service provider.

[0043] Wide-area network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0044] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. There is location independence in the sense that consumers typically do not control or know the exact location of the provided resources, but are able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0045] Rapid elasticity: The ability to scale out quickly and scale in quickly can be provisioned quickly and elastically, in some cases automatically. To the consumer, the capacity available for provisioning often appears to be unlimited and can be purchased in any quantity at any time.

[0046] Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0047] The service model is as follows:

[0048] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on the cloud infrastructure. The applications are accessible from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0049] Platform as a Service (PaaS): The capability provided to consumers is to deploy consumer-created or acquired applications onto cloud infrastructure, where the applications are created using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possible configuration of the application hosting environment.

[0050] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0051] The deployment model is as follows:

[0052] Private cloud: The cloud infrastructure is operated only for the organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0053] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0054] Public cloud: Cloud infrastructure is available to the general public or large industrial groups and is owned by an organization that sells cloud services.

[0055] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0056] The cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure consisting of a network of interconnected nodes.

[0057] refer to Figure 1 , which shows a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be grouped physically or virtually in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above (not shown). This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 1The types of computing devices 54A-N shown in are intended for illustration only, and computing node 10 and cloud computing environment 50 may communicate with any type of computing device over any type of network and / or network addressable connection (eg, using a web browser).

[0058] refer to Figure 2 , which depicts a cloud computing environment 50 ( Figure 1 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 2 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0059] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include host 61; server 62 based on RISC (Reduced Instruction Set Computer) architecture; server 63; blade server 64; storage device 65; and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0060] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0061] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized in a cloud computing environment, as well as billing or invoicing for consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management so that the required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-scheduling and procurement of cloud computing resources, where future demand is anticipated based on the SLA.

[0062] The workload layer 90 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; In the context of the illustrated embodiments of the present disclosure, various workloads and functions 96 for virtual machine management processing are described, including processing for synchronizing two separate memory spaces and facilitating high availability (HA) of running VMs. In addition, workloads and functions 96, as described herein, may include operations such as data encoding / decoding and memory management. In some embodiments, workloads and functions 96 also work in conjunction with other parts of various abstraction layers, such as those in hardware and software 60, virtualization 70, and management 80, to achieve the various purposes of the disclosed embodiments.

[0063] refer to Figure 3 , which depicts a block diagram of an example cloud computing environment 300 according to an illustrative embodiment. In the illustrated embodiment, the cloud computing environment 300 includes a service infrastructure 302, which includes an intelligent memory controller (IMC) 306 that provides high-frequency memory synchronization between an active virtual machine 304A and a standby virtual machine 304B according to an exemplary embodiment. In some embodiments, the IMC 306 is deployed in Figure 2 In the workload layer 90, as an example, in some embodiments, the IMC 306 uses Figure 2 The virtual machine management process 96 is implemented.

[0064] In the illustrated embodiment, the service infrastructure 302 provides services and service instances to user devices 314. The user devices 314 communicate with the service infrastructure 302 via the API gateway 310. In various embodiments, the service infrastructure 302 and its associated virtual machines 304A serve multiple users and multiple tenants. A tenant is a group of users (e.g., a company) that share common access to a software instance with specific privileges. The service infrastructure 302 ensures that tenant-specific data is isolated from other tenants.

[0065] In the illustrated embodiment, service infrastructure 302 includes service registry 312. In some embodiments, service registry 312 looks up a service instance of virtual machine 304A in response to a service lookup request, such as a service lookup request from API gateway 310 in response to a service request from user device 314. For example, in some embodiments, service registry 312 looks up a service instance of virtual machine 304A in response to a request from user device 314 related to experience packaging processing.

[0066] In some embodiments, the service infrastructure 302 includes a memory 308, which includes a computer-readable storage medium. In some embodiments, the service infrastructure 302 includes one or more instances of a virtual machine, including an active virtual machine 304A and a standby virtual machine 304B. In some such embodiments, each of the multiple instances of the virtual machine runs independently on multiple computing systems. In some such embodiments, the active virtual machine 304A and the standby virtual machine 304B and other service instances of the virtual machine are registered in the service registry 312.

[0067] In some embodiments, the service registry 312 maintains information about the state or health of each service instance, including performance information associated with each service instance. In some such embodiments, such information may include various types of performance characteristics (e.g., cache metrics, etc.) and updated records for a given service instance.

[0068] In some embodiments, the user device 314 is connected to the API gateway 310 via any suitable network or combination of networks such as the Internet, and uses any suitable communication protocol such as Wi-Fi, Bluetooth, etc. The API gateway 310 provides access to client applications such as active virtual machines 304A and standby virtual machines 304B. The API gateway 310 receives a service request issued by a client application and creates a service search request based on the service request. As a non-limiting example, in an embodiment, the user device 314 executes a routine to initiate interaction with the active virtual machine 304A. For example, in some embodiments, the user directly accesses the active virtual machine 304A using a command line or a GUI. In addition, in some embodiments, the user indirectly accesses the active virtual machine 304A by using a web application that interacts with the active virtual machine 304A via the API gateway 310.

[0069] refer to Figure 4 , which depicts a block diagram of an example VM environment 400 according to an exemplary embodiment. The exemplary embodiment includes an IMC 416A that provides high frequency memory synchronization between an active host 402 and a standby host 406 according to an illustrative embodiment. In a particular embodiment, the IMC 416A is Figure 3 An example of an IMC 306, active host 402 is Figure 3 An example of an active virtual machine 304A, a standby host 406 is Figure 3 An example of a standby virtual machine 304B.

[0070] In the illustrated embodiment, VM environment 400 generally includes an active host 402 and a standby host 406. Active host 402 and standby host 406 may include computers or computing systems, such as servers, and may be referred to simply as "servers." Active host 402 and standby host 406 may be implemented as Figure 1 The cloud computing node 10. In some embodiments, the active host 402 and the standby host 406 are separate hardware devices. In some embodiments, the active host 402 and the standby host 406 are included on a single hardware device having two or more processors or processor cores.

[0071] In the illustrated embodiment, active host 402 and standby host 406 communicate via network 404. In some embodiments, network 404 includes the Internet and / or the above-mentioned Figure 1 Aspects of the cloud computing environment 50.

[0072] Active host 402 includes CPU 408A, main memory 410A, and disk storage device 412A; standby host 406 includes CPU 408B, main memory 410B, and disk storage device 412B. CPU 408A / 408B may include one or more processors and may be implemented using one or more heterogeneous processor systems. CPU 408A / 408B may be a multi-core processor. Main memory 410A and / or 410B and disk storage device 412A and / or 412B are some examples of computer-readable storage media. Main memory 410A and / or 410B are typically in the form of electronic volatile memory, such as DRAM. Disk storage device 412A and / or 412B are typically a form of non-volatile memory, such as a hard disk drive or solid-state drive. Instructions for the operating system, object-oriented programming system, and applications or programs are located on storage devices, such as disk storage device 412A and / or file storage 412B, and can be loaded into main memory 410A and / or 410B for execution by the corresponding CPU 408A or CPU 408B. The processes of the illustrative embodiments can be performed by CPU 408A and / or CPU 408B using computer-implemented instructions, which can be located in a memory, such as main memory 410A and / or main memory 410B. Main memory 410A / 410B and disk storage file storage 412A / 412B can be any suitable form of computer-readable storage media.

[0073] In an embodiment, active host 402 executes active virtual machine 414A. A virtual machine is a software implementation of a "machine" (e.g., a computing system) that executes an application or program similar to a physical computing system or machine. The memory image and disk writes of virtual machine 414A (which may correspond to a memory session and a "file system" associated with the virtual machine) are synchronized, mirrored, or copied to standby host 406 of a "backup" or "standby" virtual machine 414B, which does not execute when virtual machine 414A executes on active host 402. In the event that active host 402 fails or can no longer execute active virtual machine 414A, active virtual machine 414A "fails over" to standby host 406, which can assume execution of standby virtual machine 414B. In this way, the combination of active host 402 and standby host 406 provides high availability for active virtual machine 414A.

[0074] In some embodiments, the synchronization of two independent memory spaces is performed to promote the high availability of running VMs such as active virtual machines 414A. In some embodiments, synchronization allows failover in a stateful manner, whereby CPU, memory, network, and disk storage are all snapshotted in a consistent manner. In some embodiments, high-frequency snapshots of the states of CPU, memory, network, and disk storage are collected from active virtual machines 414A and sent to standby virtual machines 414B as a "continuous stream" of updates. Increasing the frequency of collecting and sending such high-frequency snapshots reduces potential data loss in failover events. The period between snapshots is referred to as an era. In some embodiments, the period period can vary from one era to the next. For example, the period period can be driven by the time required for an application running in a VM to complete one or more transactions, such as a database that commits a transaction.

[0075] In some embodiments, when the synchronization process is initiated at the end of the period, the operation of the active virtual machine 414A is temporarily suspended to allow the CPU registers and caches to be refreshed so that the accurate state of the active virtual machine 414A can be captured and copied on the standby virtual machine 414B. The IMC 416A is used to accelerate the synchronization process to minimize the amount of time that the active virtual machine 414A is suspended. Moreover, the synchronization data that needs to be updated in the standby virtual machine 414B is transferred to the IMC 416A using high-speed data transmission technology, such as direct memory access (DMA), to minimize the amount of time that the active virtual machine 414A is suspended.

[0076] In some embodiments, IMC 416A performs a data compression process that includes a modified XOR-RLE scheme optimized for existing accelerator devices (e.g., GPUs and FPGAs). In some such embodiments, the compression process is implemented using data parallelism so that many (e.g., thousands) of threads perform the XOR-RLE process together.

[0077] The data stream can be divided into Figure 4 The active side (encoding) associated with the active host 402 in Figure 4 The standby side (decoding) associated with the standby host 406 in the active host 402 is used. Both sides can be made more efficient by using hardware-based concurrency, such as GPU or CPU threads, or parallel circuits inherent in FPGAs. In the illustrated embodiment, IMC 416A uses a hardware accelerator, such as a GPU or FPGA, to encode data on the active side of the active host 402, and CPU 408A performs decoding of the synchronous snapshot data on the decoding side of the standby host 406. In some embodiments, the decoding side may include an optional IMC 416B, which includes a hardware accelerator to perform decoding. However, in some embodiments, there is less urgency to quickly decode the synchronization data than to encode the synchronization data, because the active virtual machine 414A does not need to wait for the data to be decoded on the standby side before resuming operation. For example, in some embodiments, the active virtual machine 414A is initially suspended so that the synchronization data can be detected and sent to the IMC 416A, which encodes the data and sends it back to the active host 402 to send to the standby host 406. Once the data has been sent to the standby host 406, the active virtual machine 414A can resume operation. This means that the backup host 406 does not complete decoding until the end of the next epoch.

[0078] refer to Figure 5 , which depicts a block diagram of a VM environment 500 according to an exemplary embodiment. The exemplary embodiment includes an active host 502 and an IMC 520. In a particular embodiment, the active host 502 is Figure 4 An example of an active host 402, IMC 520 is Figure 4 An example of IMC 416A.

[0079] In the illustrated embodiment, the active host 502 includes a CPU 504, a DMA controller 510, and an active VM 511 loaded into a main memory 505 by the CPU 504 executing a hypervisor 513. The main memory 505 also includes a client current memory 512, a client previous memory 514, an encoded incremental result buffer 518, and a segment list 516. The active VM 511 includes a VM cache 507 and a VM memory 509. The IMC 520 includes a client current memory buffer 522, a client previous memory buffer 524, a block information buffer 526, a pre-send encoded incremental buffer 528, a processor 530, a memory 532, and a file storage device 534. In an alternative embodiment, the active host 502 and / or the IMC 520 may include some or all of the functions described herein, but are grouped differently into one or more modules. In some embodiments, the functions described herein are distributed in multiple systems, which may include a combination of software and / or hardware-based systems, such as application specific integrated circuits (ASICs), computer programs, or smart phone applications.

[0080] In the illustrated embodiment, the processor 530 of the IMC 520 and the CPU 504 of the active host 502 perform various computing and data processing tasks, among other functions. In some embodiments, the processor 530 includes a hardware accelerator, such as a GPU or FPGA. The processor 530 communicates with the memory 532 and the file storage device 534. The CPU 504 communicates with the main memory 505. In some embodiments, the memory 532, the file storage device 534, and the main memory 505 include one or more computer-readable storage media, wherein program instructions are stored together on the one or more computer-readable storage media, wherein the program instructions in the memory 532 or the file storage device 534 can be executed by the processor 530 to cause the processor 530 to perform the operations described herein, and wherein the program instructions in the main memory 505 can be executed by the CPU 504 to cause the CPU 504 to perform the operations described herein.

[0081] In the illustrated embodiment, the IMC 520 manages synchronization of the VM memory 509 of the active VM 511 with the VM memory of the standby VM (e.g., the standby virtual machine 414B). The IMC 520 synchronizes the VM memory 509 in a manner that allows the standby host to execute a standby VM that is equivalent to the active VM 511. In some embodiments, the IMC 520 synchronizes the active VM 511 multiple times per second using an epoch-based system, where the execution of the active VM 511 is limited by short pauses in execution during which changes to the VM memory 509 of the active VM 511 are captured and transferred to the standby VM.

[0082] In some embodiments, the synchronization process includes once per epoch, the CPU 504 of the active host 502 suspending the running active VM 511 and identifying pages of the VM memory 509 of the active VM 511 that have changed during the current epoch (i.e., dirty pages). In some embodiments, after the active VM 511 has been suspended, the VM cache 507 is flushed and the hypervisor 513 iterates through the dirty page bitmap (a collection of bits representing the clean / dirty state of each page in the client VM memory). The dirty page bitmap is used to construct a segment list 516, which is an array of non-contiguous dirty spans, where each element of the array includes a corresponding segment offset, length pair corresponding to the identified contiguous dirty span in the VM memory 509 (i.e., two adjacent dirty pages are grouped into the region defined by the element of the array).

[0083] In some embodiments, the synchronization process includes the DMA controller 510 performing DMA transactions to transfer non-contiguous dirty spans of VM memory 509 to a series of contiguous memory addresses of the guest current memory buffer 522 of the IMC 520. In some embodiments, the segment list 516 is used to copy the contents of the non-contiguous dirty spans to the guest current memory 512 of the active host 502 and to the guest current memory buffer 522 of the IMC 520 via the DMA transaction in packed form (i.e., at contiguous addresses). In some embodiments, the segment list 516 is also used to unpack the modified memory spans to their original locations at the standby VM.

[0084] In the illustrated embodiment, the active host 502 also includes a client previous memory 514 that stores the state of the VM memory 509 before the current epoch. The IMC 520 includes a client previous memory buffer 524 that also stores the state of the VM memory 509 before the current epoch. In some embodiments, when the IMC 520 is dedicated to the active VM 511, the IMC 520 maintains the client previous memory buffer 524 between synchronization processes (i.e., during epochs). In some such embodiments, after the processor 530 has completed encoding processing of dirty spans in the client current memory buffer 522, the processor 530 copies the contents of the client current memory buffer 522 to the client previous memory buffer 524 in preparation for the next epoch.

[0085] In some embodiments, IMC 520 manages synchronization of multiple VMs, such as by being time multiplexed to manage synchronization of two or more VMs such that the timing of their routines are offset in time from each other by a sufficient time to complete the synchronization process of one VM before the synchronization of the next VM begins. In such embodiments, client previous memory 514 is transferred to client previous memory buffer 524 via DMA transactions immediately before or after a dirty span of VM memory 509 is transferred to client current memory buffer 522 of IMC 520 via DMA transactions.

[0086] In some embodiments, the synchronization process includes the processor 530 performing multi-threaded parallel encoding processing on dirty pages received from the active host 502. The data in the client current memory buffer 522 and the client previous memory buffer 524 are all packed so as to occupy the memory addresses of consecutive spans in each buffer. The packed data is logically divided into "blocks" that can be encoded by separate threads. In some embodiments, the block information buffer 526 stores information about each block, for example, multiple segment offsets and length pairs corresponding to each block. The size of the block must be sufficient to provide the granularity required for parallelization across N worker threads, where N is the limitation of the underlying hardware (for example, nominally 2048 threads for a GPU). For example, in some embodiments, each individual thread performs XOR and RLE encoding on one or more blocks and creates block-level results in the pre-sent encoded delta buffer 528. The number of worker threads N can vary significantly for different target devices, as small as 8-16 for typical FPGAs, limited by the concurrent memory accesses that the device can support. In this case, we can use sub-threads (sub-kernels) to pipeline memory accesses within the thread, thereby achieving much higher logical threads.

[0087] The process of performing XOR-RLE encoding may be provided, for example, using Algorithm 1 provided below in pseudocode:

[0088] Algorithm 1: XOR-RLE processing:

[0089] / *RLE encoding - int32 granularity* /

[0090] for(unsigned int i=0;i <ints_per_chunk;){

[0091] / *Write XOR value* /

[0092] p_result[0]=p_a[i]^p_b[i];

[0093] unsigned int count = 1;

[0094] while(((p_a[i+count]^p_b[i+count])==p_result[0])&&

[0095] (count+i <ints_per_chunk)){

[0096] count++;

[0097] }

[0098] / *Write run-length* /

[0099] p_result[1] = count;

[0100] i+=count;

[0101] p_result+=2;

[0102] }

[0103] In some embodiments, a typical block size is 128 pages (512 KiB), however, other block sizes may be used without departing from the present disclosure. When blocks are encoded, their length is typically less than the size of the original block. The block position and length information is copied to the block information buffer 526. In some embodiments, the XOR+RLE encoded block is constructed as shown in Table 1:

[0104] Table 1

[0105]

[0106]

[0107] in:

[0108]

[0109] If the XOR+RLE compressed block is larger than the original block size, e.g., due to high entropy modification, the original contents of the block (in the client current memory buffer 522) are copied to the pre-send encoded delta buffer 528, where the block is constructed as shown in Table 2:

[0110] Table 2

[0111] Offset length coding Plaintext data

[0112] Note that in Tables 1 and 2, in some embodiments, the encoding type is included to distinguish between XOR+RLE and plaintext data. In some embodiments, where there are only two encoding types, one bit is required in both options.

[0113] Once the blocks are processed, the contents of the pre-send encoded delta buffer 528 may be transferred back to the encoded delta result buffer 518 on the active host 502. To achieve packed results, the block information buffer 526 is first copied back to the active host 502. This block information {block offset, block length} is used to ensure that the compressed blocks are efficiently copied back to a packed form on the active host 502, which is suitable for transmission to the standby host. In addition, the encoded delta result buffer 518 includes an original segment list 516 that maps the blocks to their original locations in memory.

[0114] In some embodiments, the synchronization process includes transmitting the results of the encoding process to the standby host for decoding and updating the VM memory of the standby VM. In some embodiments, once the results of the encoding process have been sent to the standby host, the active VM 511 is unpaused and resumed, which represents a transition to a new epoch.

[0115] refer to Figure 6 , which depicts a block diagram of an example VM environment 600 according to an exemplary embodiment. Example embodiments are similar to Figure 4 6, except that in VM environment 600 IMC 616A includes NIC 618A that allows IMC 616A to communicate with standby host 606 over network 604. In VM environment 400, IMC 416A sends synchronization data to active host 402, which then sends it to standby host 406. In VM environment 600, IMC 616A sends synchronization data (memory snapshots) to standby host 606 using NIC 618A without first sending it to active host 602. Figure 4 The description of active host 402 also applies to active host 602, and Figure 4 The description of backup host 406 also applies to backup host 606. Also, in some embodiments, backup host 606 uses optional IMC 616B including NIC 618B to receive and decode synchronization data from IMC 616A.

[0116] refer to Figure 7 , which depicts a block diagram of a VM environment 700 according to an exemplary embodiment. Figure 5500, except that in VM environment 700 IMC 720 includes NIC 736 that allows IMC 720 to communicate with the standby host over the network. In VM environment 500, IMC 520 sends synchronization data to active host 502, which then sends it to the standby host. In VM environment 700, IMC 720 uses NIC 736 to send synchronization data (memory snapshots) to the standby host without first sending it to the active host 702. In addition, the active host 702 does not need a result buffer, e.g. Figure 5 The encoded incremental result buffer 518 is outside the Figure 5 The description of active host 502 also applies to active host 702, because IMC 720 is sending result data directly to the standby host. In addition to IMC 720 including NIC 736, Figure 5 The description of the IMC520 applies equally to the IMC720.

[0117] refer to Figure 8 , which depicts a block diagram of a VM environment 800 according to an illustrative embodiment. The exemplary embodiment includes an active host 802 and an IMC 804. The view of the active host 802 and the IMC 804 is simplified to allow for a clear illustration of the embodiment of the DMA transaction. In some embodiments, the active host 802 is Figure 4 Active host 402, Figure 5 Active host 502, Figure 6 Active host 602 or Figure 7 In some embodiments, the IMC 804 is an example of an active host 702. Figure 3 IMC 306 Figure 4 IMC 416A, Figure 5 IMC 520 Figure 6 IMC 616A or Figure 7 Example of the IMC 720.

[0118] In some embodiments, the synchronization process includes once per epoch, the active host 802 suspends the running active VM and identifies pages of VM memory that have changed during the current epoch (i.e., dirty pages). In some embodiments, after the active VM has been suspended, the VM cache is cleared and the hypervisor iterates through a dirty page bitmap (a collection of bits representing the clean / dirty state of each page in the client VM memory). The dirty page bitmap is used to construct a segment list 810, which is an array of non-contiguous dirty spans, where each element of the array includes a corresponding segment offset, length pair corresponding to an identified contiguous dirty span in the VM memory (i.e., two adjacent dirty pages are grouped into the region defined by the element of the array).

[0119] In some embodiments, the synchronization process includes the DMA controller performing DMA transactions to transfer non-contiguous dirty spans of VM memory, which are shown as non-contiguous spans A', B', C', and D' of the client current memory 806. The synchronization process also includes the DMA controller performing DMA transactions to transfer the same spans of a previous version of the memory, shown as spans A, B, C, and D of the guest previous memory 808. In some embodiments, the previous version is the most recent previous version of the memory synchronized with the standby VM. In some embodiments, the segment offset and length of each of the spans A, B, C, and D match the segment offset and length of each of the spans A', B', C', and D'.

[0120] In the illustrated embodiment, non-contiguous spans A', B', C' and D' are copied to a series of continuous memory addresses of the client current memory buffer 812 of the IMC 804 via DMA transactions. Also in the illustrated embodiment, non-contiguous spans A, B, C and D are copied to a series of continuous memory addresses of the client previous memory buffer 814 of the IMC 804 via DMA transactions. In the illustrated embodiment, non-contiguous spans A', B', C' and D' are copied to a series of continuous memory addresses of the client current memory buffer 812 of the IMC 804 via DMA transactions. The packing of data in the client current memory buffer 812 and the client previous memory buffer 814 allows data to be aligned with dense data calculations that hardware accelerators such as GPUs or FPGAs are very suitable for processing. This in turn allows the compression workload to be divided into blocks of packed data to support data parallelism. Then, the encoded (compressed) data can be collected into continuous memory using the output segment buffer for transmission to the standby VM.

[0121] refer to Fig. 9 , which depicts a block diagram of a VM environment 900 according to an exemplary embodiment. The exemplary embodiment includes an active host 902 and an IMC 904. The view of the active host 902 and the IMC 904 is simplified to clearly illustrate an embodiment of multi-threaded XOR-RLE processing according to an illustrative embodiment. In some embodiments, the active host 902 is Figure 4 Active host 402, Figure 5 Active host 502, Figure 6 Active host 602 or Figure 7 In some embodiments, the IMC 904 is an example of an active host 702. Figure 3 IMC 306 Figure 4 IMC 416A, Figure 5 IMC 520 Figure 6 IMC 616A or Figure 7 Example of the IMC 720.

[0122] In some embodiments, the synchronization process includes a hardware accelerator performing multi-threaded parallel encoding processing of dirty pages received from the active host 902. Data spans A', B', C', and D' in the client's current memory buffer and data spans A, B, C, D in the client's previous memory buffer are packed so as to occupy consecutive spans of memory addresses in each buffer. The packed data is logically divided into "chunks" that can be encoded by separate threads. The size of the chunk must be sufficient to provide the granularity required for parallelization across N worker threads, where N is a limit of the underlying hardware (e.g., nominally 2048 threads for a GPU). To simplify, Fig. 9 Five worker threads are shown. A practical implementation may include hundreds or thousands of threads.

[0123] In some embodiments, each individual thread performs XOR and RLE encoding on one or more blocks in the compression module 910 and creates corresponding block-level results dA, dB, dC, and dD in the result buffer 912. Once the blocks are processed, the contents of the result buffer 912 can be transferred back to the XOR-RLE result buffer 906 on the active host 902. In order to achieve packed results, the block information buffer is first copied back to the active host 902. This block information {block offset, block length} is used to ensure that the compressed blocks are efficiently copied back to a packed form on the active host 902, which is suitable for transmission to the standby host. In addition, the XOR-RLE result buffer 906 should include the original segment list that maps the blocks to their original locations in memory.

[0124] In some embodiments, the synchronization process includes transmitting the results of the encoding process to the standby host for decoding and updating the VM memory of the standby VM. In some embodiments, once the results of the encoding process have been sent to the XOR-RLE result buffer 906, the active host 902 unpauses the active VM and resumes execution, which indicates a transition to a new epoch.

[0125] refer to Fig.10 , which depicts a block diagram of a VM environment 1000 according to an exemplary embodiment. The exemplary embodiment includes a backup host 1002. The view of the backup host 1002 is simplified to clearly illustrate an embodiment of a multi-threaded XOR-RLE decoding process according to an illustrative embodiment. In some embodiments, the backup host 1002 is Figure 4 The alternate host 406 or Figure 6 An example of a backup host 606.

[0126] In the illustrated embodiment, the standby host 1002 receives the memory snapshot from the active VM as synchronization data, along with segment information (e.g., Fig. 9The standby host 1002 performs a decoding process on the received synchronization data. In some embodiments, the expansion (decoding) module 1004 detects the encoding type (XOR-RLE encoding or plaintext data) of each block, and then decodes (for example, performs RLE expansion on it) each block marked as compressed (as opposed to plaintext data copying). The XOR decoding module 1006 then performs an XOR operation on each block output from the expansion module 1004. In some embodiments, the XOR operation is performed directly in the standby client VM main memory 1008 at the location indicated by the segment information offset in the segment information transmitted from the active VM with the memory snapshot. The main embodiment of the decoder is to use a stream abstraction to "assign" encoded values ​​(as 32-bit integers), which can be applied (XOR) or assigned (plaintext copying) to the memory area obtained by parsing the original segment list.

[0127] refer to Fig.11 , which depicts a flow diagram of an example process 1100 for an encoding process in accordance with an illustrative embodiment. In a particular embodiment, the IMC 306, IMC 416A, IMC 520, IMC 616A, IMC 720, IMC 804, or IMC 904 performs the process 1100.

[0128] In one embodiment, at block 1102, the synchronization process includes once per epoch, the active host suspends the running active VM and identifies pages of VM memory that have changed during the current epoch (i.e., dirty pages). In some embodiments, after the active VM has been suspended, the VM cache is cleared and the hypervisor iterates through a dirty page bitmap (a collection of bits representing the clean / dirty state of each page in the client VM memory). Next, at block 1104, the synchronization process uses the dirty page bitmap to construct a segment list, which is an array of non-contiguous dirty spans, where each element of the array includes a corresponding segment offset, length pair corresponding to an identified contiguous dirty span in the VM memory (i.e., two adjacent dirty pages are grouped into the region defined by the element of the array).

[0129] Next, at block 1106, the synchronization process includes the DMA controller performing a DMA transaction to transfer the non-contiguous dirty span of VM memory to a series of contiguous memory addresses of the client current memory buffer of the IMC. In some embodiments, the segment list is used to copy the contents of the non-contiguous dirty span to the client current memory buffer of the IMC via the DMA transaction in a packed form (i.e., at contiguous addresses). Additionally, at block 1108, the segment list is used to copy the contents of the non-contiguous dirty span to the client current memory of the active host.

[0130] In blocks 1110 and 1112, the synchronization process includes a processor, preferably a hardware accelerator such as a GPU or FPGA, performing multi-threaded parallel encoding processing of dirty pages received from the active host. The data in the client current memory buffer and the client previous memory buffer are packed so as to occupy a continuous span of memory addresses in each buffer. The packed data is logically divided into "blocks" that can be encoded by separate threads. In some embodiments, the block information buffer stores information about each block, such as a plurality of segment offsets and length pairs corresponding to the corresponding block. The size of the block must be sufficient to provide the granularity required for parallelization across N worker threads, where N is the limitation of the underlying hardware (e.g., nominally 2048 threads for a GPU). For example, in some embodiments, each separate thread performs XOR (block 1110) and RLE (block 1112) encoding on one or more blocks and creates block-level results in a pre-sent encoded delta buffer. The number of worker threads N can vary significantly for different target devices, as small as 8-16 for a typical FPGA, limited by the concurrent memory accesses that the device can support. In this case, we can use sub-threads (sub-kernels) to pipeline memory accesses within a thread, thereby achieving a much higher number of logical threads.

[0131] Next, the synchronization process continues based on the comparison of the size of the XOR+RLE compressed block to the original block size at blocks 1114 and (optionally, if the IMC lacks a NIC) 1116. If the compressed version is larger, e.g., due to high entropy modification, the original contents of the block (in the client's current memory buffer) are copied to the pre-send encoded delta buffer at block 1114. Otherwise, the compressed version is copied to the pre-transmit encoded delta buffer at block 1116. This comparison is performed for each block individually until they have all been processed and stored in the pre-transmit encoded delta buffer.

[0132] Next, the synchronization process transfers the contents of the pre-send encoded delta buffer back to the encoded delta result buffer on the active host at block 1118. The process then transfers the results of the encoding process to the standby host for decoding and updating the VM memory of the standby VM.

[0133] refer to Fig.12 , which depicts a flow diagram of an example process 1200 for a decode process in accordance with an illustrative embodiment. In certain embodiments, backup host 406, backup host 606, or backup host 1002 performs process 1100.

[0134] In one embodiment, at blocks 1202 and 1204, the process initiates a recursive loop to iterate through each entry of each segment list. At block 1206, processing continues based on whether the segment currently being evaluated is XOR-RLE encoded data or plaintext data. If encoded, at block 1212, the standby host performs a decoding process on the data segment, for example, by performing an RLE expansion on each block marked as compressed. Next, at block 1214, the XOR module performs an XOR operation on each block marked as compressed. In some embodiments, the XOR operation is performed directly in the standby guest VM main memory at a location indicated by a segment information offset in the segment information transferred from the active VM with the memory snapshot.

[0135] If at block 1206 the segment is plaintext data, then at block 1208 the plaintext value of the data is extracted from the segment. Next, at block 1210 the data is copied to the memory area obtained by parsing the original segment list. This process continues iteratively until all synchronization data has been processed and incorporated into the memory of the standby VM.

[0136] The following definitions and abbreviations are used to interpret the claims and specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," "containing," or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0137] Additionally, the term "illustrative" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "illustrative" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" should be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "plurality" should be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connected" may include both indirect "connected" and direct "connected."

[0138] References in the specification to "one embodiment," "example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may or may not include the particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0139] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with the measurement of a particular quantity based on the equipment available at the time this application was filed. For example, "about" may include a range of ±8% or 5% or 2% of a given value.

[0140] The description of various embodiments of the present invention has been given for the purpose of illustration, but it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements existing in the market, or to enable other persons of ordinary skill in the art to understand the embodiments described herein.

[0141] The description of various embodiments of the present invention has been given for the purpose of illustration, but it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements existing in the market, or to enable other persons of ordinary skill in the art to understand the embodiments described herein.

[0142] Thus, in illustrative embodiments, a computer-implemented method, system or apparatus, and computer program product are provided for managing participation in an online community and other related features, functions, or operations. Where embodiments or portions thereof are described with respect to one type of device, the computer-implemented method, system or apparatus, computer program product, or portions thereof, is adapted or configured for use with appropriate and comparable representations of that type of device.

[0143] Where embodiments are described as being implemented in an application, delivery of the application in a software as a service (SaaS) model may be envisioned within the scope of the illustrative embodiments. In the SaaS model, the ability to implement the application of the embodiments is provided to the user by executing the application in a cloud infrastructure. The user may access the application using a variety of client devices through a thin client interface such as a web browser (e.g., web-based email) or other lightweight client applications. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage of the cloud infrastructure. In some cases, the user may not even manage or control the capabilities of the SaaS application. In some other cases, a SaaS implementation of the application may allow limited possible exceptions to user-specific application configuration settings.

[0144] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, and the computer-readable program instructions are used to cause a processor to perform various aspects of the present invention.

[0145] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or a flash memory, a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0146] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0147] The computer-readable program instructions for performing the operation of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider via the Internet). In some embodiments, in order to perform various aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute a computer-readable program instruction by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit.

[0148] Various aspects of the present invention are described herein with reference to the flow chart and / or block diagram of the method, device (system) and computer program product according to embodiments of the present invention. It will be understood that each frame of the flow chart and / or block diagram and the combination of frames in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

[0149] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can guide the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0150] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0151] Flowchart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in the flow chart or block diagram can represent the module, segment or part of instruction, which includes one or more executable instructions for realizing the specified logical function.In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure.For example, two frames shown continuously can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of the block diagram and / or flow chart illustration and the block diagram and / or flow chart illustration can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0152] Embodiments of the present invention may also be delivered as part of a service engagement with a client company, non-profit organization, government entity, internal organizational structure, etc. Aspects of these embodiments may include configuring a computer system to perform, and deploying software, hardware, and web services that implement some or all of the methods described herein. Aspects of these embodiments may also include analyzing the operations of a client, creating recommendations in response to the analysis, building a system that implements parts of the recommendations, integrating the system into existing processes and infrastructure, metering use of the system, allocating fees to users of the system, and billing for the use of the system. Although each of the above-mentioned embodiments of the present invention has been described by stating their respective advantages separately, the present invention is not limited to a specific combination thereof. On the contrary, according to the intended deployment of the present invention, these embodiments may also be combined in any manner and quantity without losing their beneficial effects.

Claims

1. A computer-implemented method comprising: Writing, by an intelligent memory controller IMC, current snapshot data to a first series of consecutive memory addresses, wherein the current snapshot data is received by the IMC from a memory of an active virtual machine VM via a first direct memory access DMA transfer operation; executing, by the IMC, concurrent threads associated with the corresponding span of the continuous memory addresses, wherein the concurrent threads control compression processing of the corresponding portion of the current snapshot data to produce a corresponding portion of processed current snapshot data, wherein the concurrent threads include a first thread bound to a hardware accelerator that performs the compression processing of the first portion of the current snapshot data; and The processed current snapshot data is sent to the standby VM as a current synchronized snapshot of the active VM.

2. The computer-implemented method of claim 1 , wherein: The current snapshot data is received by the IMC from a plurality of non-contiguous spans of memory of the active VM.

3. The computer-implemented method of claim 1 , wherein: The current snapshot data includes pages of memory designated as having changed since a previously synchronized snapshot of the active VM, The previous synchronization snapshot is represented as previous snapshot data.

4. The computer-implemented method of claim 3, further comprising: The previous snapshot data is written, by the IMC, to a second series of consecutive memory addresses, wherein the previous snapshot data is received by the IMC from the memory of the active VM via a second DMA transfer operation.

5. The computer-implemented method of claim 3, wherein: The compression processing of the first part of the current snapshot data includes: performing, by the hardware accelerator, an exclusive-OR operation between an original data version of the first portion of the current snapshot data and a corresponding original data version of the first portion of the previous snapshot data, wherein the XOR operation produces an incrementally encoded version of the first portion of the current snapshot data, and The incrementally encoded version represents a memory change of the first portion of the current snapshot data compared to a corresponding first portion of the previous snapshot data.

6. The computer-implemented method of claim 5, wherein: The compression processing of the first part of the current snapshot data includes: performing, by the hardware accelerator, a run-length encoding (RLE) operation on the delta-encoded version of the first portion of the current snapshot data, Therein, the RLE operation produces an RLE-encoded version of the first portion of the current snapshot data.

7. The computer-implemented method of claim 6, wherein: The compression processing of the first part of the current snapshot data includes: The smaller of the original data version and the RLE-encoded version of the first portion of the current snapshot data is output as the first portion of the processed current snapshot data.

8. The computer-implemented method of claim 7, further comprising: The previous snapshot data is replaced by the IMC with the current snapshot data so that the current snapshot data is used as the previous snapshot data when generating a subsequent synchronized snapshot of the active VM.

9. The computer-implemented method of claim 1 , wherein: The hardware accelerator includes a graphics processing unit (GPU).

10. The computer-implemented method of claim 1, wherein: The hardware accelerator includes a field programmable gate array FPGA.

11. A computer program product, comprising one or more computer-readable storage media and program instructions stored together on the one or more computer-readable storage media, the program instructions being executable by a processor to cause the processor to perform operations, the operations comprising: Writing, by an intelligent memory controller IMC, current snapshot data to a first series of consecutive memory addresses, wherein the current snapshot data is received by the IMC from a memory of an active virtual machine VM via a first direct memory access DMA transfer operation; executing, by the IMC, concurrent threads associated with the corresponding span of the continuous memory addresses, wherein the concurrent threads control compression processing of the corresponding portion of the current snapshot data to produce a corresponding portion of processed current snapshot data, wherein the concurrent threads include a first thread bound to a hardware accelerator that performs the compression processing of the first portion of the current snapshot data; and The processed current snapshot data is sent to the standby VM as a current synchronized snapshot of the active VM.

12. The computer program product according to claim 11, wherein: The stored program instructions are stored in a computer readable storage device in the data processing system and wherein the stored program instructions are transmitted from a remote data processing system over a network.

13. The computer program product of claim 11, wherein: The stored program instructions are stored in a computer readable storage device in a server data processing system, and wherein the stored program instructions are downloaded to a remote data processing system over a network in response to a request for use in a computer readable storage device associated with the remote data processing system, the computer program product further comprising: program instructions to meter usage of the program instructions associated with the request; and Program instructions for generating invoices based on metered usage.

14. The computer program product of claim 11, wherein: The current snapshot data is received by the IMC from a plurality of non-contiguous memory spans of the memory of the active VM.

15. The computer program product of claim 11, wherein: The current snapshot data includes pages of memory designated as having changed since a previously synchronized snapshot of the active VM, The previous synchronization snapshot is represented as previous snapshot data.

16. The computer program product of claim 15, further comprising: The previous snapshot data is written, by the IMC, to a second series of consecutive memory addresses, wherein the previous snapshot data is received by the IMC from the memory of the active VM via a second DMA transfer operation.

17. A computer system comprising a processor and one or more computer-readable storage media, and program instructions stored together on the one or more computer-readable storage media, the program instructions being executable by the processor to cause the processor to perform operations, the operations comprising: Writing, by an intelligent memory controller IMC, current snapshot data to a first series of consecutive memory addresses, wherein the current snapshot data is received by the IMC from a memory of an active virtual machine VM via a first direct memory access DMA transfer operation; executing, by the IMC, concurrent threads associated with the corresponding span of the continuous memory addresses, wherein the concurrent threads control compression processing of the corresponding portion of the current snapshot data to produce a corresponding portion of processed current snapshot data, wherein the concurrent threads include a first thread bound to a hardware accelerator that performs the compression processing of the first portion of the current snapshot data; and The processed current snapshot data is sent to the standby VM as a current synchronized snapshot of the active VM.

18. The computer system of claim 17, wherein: The current snapshot data is received by the IMC from a plurality of non-contiguous spans of memory of the active VM.

19. The computer system of claim 17, wherein: The current snapshot data includes pages of memory designated as having changed since a previously synchronized snapshot of the active VM, The previous synchronization snapshot is represented as previous snapshot data.

20. The computer system of claim 19, further comprising: The previous snapshot data is written, by the IMC, to a second series of consecutive memory addresses, wherein the previous snapshot data is received by the IMC from the memory of the active VM via a second DMA transfer operation.

Images