Accelerated Encoding 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 consecutive memory addresses, where 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 IMC executes concurrent threads associated with each span of consecutive memory addresses, where the concurrent threads control compression of each portion of the current snapshot data to result in a corresponding portion of processed current snapshot data, the concurrent threads having a hardware accelerator-bound thread that performs the compression of the portion of the current snapshot data. The process then sends the processed current snapshot data to a standby VM as a current synchronized snapshot of the active VM.

Description

[Background technology]

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

[0002] A virtual machine (VM) is a software-defined computer and guest operating system that runs on a host system running its own host operating system. A VM contains virtualized representations of various components of a data processing system. Generally, a VM provides a software execution environment and may have a virtual processor, virtual main memory, virtual disk storage, and possibly various other virtual devices. A VM represents a form of system virtualization that is implemented with some management functionality, typically through 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 thereon, depending on the host's available system resources and the demands of the VMs. For example, in a large data processing environment, such as a data center, hundreds or thousands of VMs may be running on a single host at any given time, and hundreds or thousands of such hosts may be operational in the data center at any given time. Such large-scale virtualized data processing environments can provide computing resources to many different clients as needed. Summary of the Invention

[0004] An exemplary embodiment provides accelerated encoding for virtual machine synchronization. One embodiment includes writing, by an intelligent memory controller (IMC), current snapshot data to a first series of consecutive memory addresses, where 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. An embodiment also includes executing, by the IMC, concurrent threads associated with each span of consecutive memory addresses, where the concurrent threads control compression of each portion of the current snapshot data to result in a corresponding portion of processed current snapshot data, the concurrent threads having a first thread bound to a hardware accelerator that performs the compression of the first portion of the current snapshot data. An embodiment also includes transmitting the processed current snapshot data to a standby VM as a current synchronized snapshot of the active VM. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of an embodiment.

[0005] One embodiment includes a computer usable program product that includes a computer readable storage medium and program instructions stored on the storage medium.

[0006] One embodiment includes a computer system including a processor, a computer-readable memory, and a computer-readable storage medium, including program instructions stored on the storage medium that are executed by the processor via the memory. [Brief explanation of the drawings]

[0007] The novel features believed characteristic of this invention are set forth in the appended claims, but the invention itself, as well as its preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of illustrative embodiments when read in connection with the accompanying drawings.

[0008] [Figure 1] 1 illustrates a cloud computing environment, according to one embodiment of the present invention.

[0009] [Figure 2] 1 illustrates an abstraction model layer according to one embodiment of the present invention.

[0010] [Figure 3] 1 illustrates a block diagram of an example cloud computing environment, in accordance with an illustrative embodiment.

[0011] [Figure 4] 1 illustrates a block diagram of an example VM environment, according to an example embodiment.

[0012] [Figure 5] 1 illustrates a block diagram of a VM environment in accordance with an example embodiment.

[0013] [Figure 6] 1 illustrates a block diagram of an example VM environment, according to an example embodiment.

[0014] [Figure 7] 1 illustrates a block diagram of a VM environment in accordance with an example embodiment.

[0015] [Figure 8] 1 illustrates a block diagram of a VM environment in accordance with an example embodiment.

[0016] [Figure 9] 1 illustrates a block diagram of a VM environment in accordance with an example embodiment.

[0017] [Figure 10] 1 illustrates a block diagram of a VM environment in accordance with an example embodiment.

[0018] [Figure 11] 1 illustrates a flowchart of an example process for encoding, according to an exemplary embodiment.

[0019] [Figure 12] 1 illustrates a flowchart of an example process for decoding, according to an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0020] The active-standby approach is an example of a high-availability architecture for VMs in which a standby VM is periodically synchronized with the active VM. The periodic synchronization typically requires updating the standby VM's main memory (e.g., DRAM) and CPU state to match that of the active VM. This synchronization can be achieved by using page tables and software to identify "dirty" memory pages in 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 VM failover, thereby reducing the duration of VM interruption during migration. However, such techniques present issues that adversely affect VM functionality due to inefficiencies in the synchronization process. For example, these types of active-standby techniques use a synchronization process that involves significant page table traversal and data copying overhead, resulting in significant VM downtime. A major contributor to this overhead is that many applications that use this technique copy more data than necessary, resulting in data copy amplification; this occurs due to the design of processor virtual memory systems, where memory pages are 4 KiB or larger. For example, one byte written to one page results in the copying of the entire 4 KiB (or larger) page during the next synchronization.

[0022] Aspects of the present disclosure address the aforementioned shortcomings by providing a mechanism (e.g., a system, a method, a machine-readable medium, etc.) that performs frequent memory synchronization more quickly and efficiently than prior art. The present disclosure recognizes that existing page protection can be leveraged to reduce the number of compressed pages for synchronization (i.e., processing only pages marked dirty). The present disclosure also recognizes that a host-to-device DMA engine can be used to pack (collect) sparse dirty pages in the active VM's main memory so that they are aligned with dense data computations that are well suited for processing by a hardware accelerator such as a GPU or FPGA. This further enables the compression workload to be divided into packed chunks of data to support data parallelism. An output segment buffer can then be utilized to collect the encoded (compressed) data in contiguous memory and send it to the standby VM. The present disclosure further recognizes that as soon as memory data is copied to the hardware accelerator for compression, the active VM may continue to assume that an epoch is longer than the total time it takes for the hardware accelerator to encode the data and send it to the standby VM.

[0023] Based on these findings, the mechanisms of the present disclosure provide synchronization techniques that significantly reduce the amount of time required to generate synchronized snapshots of VM main memory and CPU state. The mechanisms of the present disclosure also provide synchronization techniques that significantly reduce the volume of data sent to a standby VM for synchronization. These mechanisms of the present disclosure result in a synchronization approach that reduces downtime caused by synchronizing a standby VM with an active VM and allows active-standby systems using the disclosed synchronization techniques to be deployed across more limited bandwidth networks (e.g., across data centers) that would not be feasible using conventional synchronization techniques.

[0024] When 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 a manner that causes the data processing system to use a virtualized manifestation of some or all of the components of the data processing system. For example, in a virtual machine, virtual device, or virtual component, processing units are manifested as virtualized instances of all or some number of hardware processing units that may be available to the host data processing system, main memory is manifested as a virtualized instance of all or some portion of main memory that may be available to the host data processing system, and disk memory is manifested as a virtualized instance of all or some portion of disk memory that may be available to the host data processing system.

[0025] In an exemplary embodiment, the active-standby synchronization process involves the active host suspending a running active VM once per epoch and identifying pages of VM memory that have been modified during the current epoch (i.e., dirty pages). In some embodiments, after the active VM is suspended, the VM cache is flushed and the hypervisor iterates through a dirty page bitmap (a collection of bits representing the clean / dirty status of each page in the guest VM memory). The synchronization process then 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 contains a respective segment offset, length pair corresponding to the identified contiguous dirty spans in the VM memory (i.e., two adjacent dirty pages embedded in the region defined by the element of the array).

[0026] In an exemplary 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's 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 packed form (i.e., at contiguous addresses) into the guest's current memory buffer of the IMC via DMA transactions. The segment list is then used to copy the contents of the non-contiguous dirty spans into the guest's current memory of the active host.

[0027] In an exemplary embodiment, the IMC includes a processor, preferably a hardware accelerator such as a GPU or FPGA, that performs multi-threaded, parallelized encoding of dirty pages received from the active host. Data in the VM guest's current memory buffer and the guest's previous memory buffer are all packed to occupy a contiguous span of memory addresses in the respective buffers. The packed data is logically partitioned into "chunks" that can be encoded by separate threads. In some embodiments, a chunk information buffer stores information about each chunk, such as multiple segment offset and length pairs corresponding to each chunk. The chunk size must be sufficient to provide the necessary granularity for parallelization across N worker threads, where N is a constraint of the underlying hardware (e.g., nominally 2048 threads for a GPU). For example, in some embodiments, each separate thread performs encoding on one or more chunks and produces chunk-level results in an encoding delta buffer before transmission. In some embodiments, the encoding includes XOR-RLE encoding. Although exemplary embodiments are described herein as using XOR-RLE encoding, alternative embodiments may use other types of encoding, for example, LZ4 or DEFLATE encoding with or without XOR.

[0028] The number of worker threads, N, can vary significantly for different target devices, constrained by the simultaneous memory accesses that the device can support, with a typical FPGA having only 8-16. In such cases, a much larger number of logical threads can be achieved by using sub-threads (sub-kernels) to pipelining memory accesses within a thread.

[0029] In an exemplary embodiment, the synchronization process proceeds based on the results of comparing the size of the XOR+RLE compressed chunk with the original chunk size. For example, if the compressed version is larger due to a large amount of entropy modification, the original contents of the chunk (in the guest's 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 chunk individually until all chunks have been processed and stored in the pre-send encoded delta buffer.

[0030] In an exemplary embodiment, the synchronization process transfers the contents of the pre-transmission encoding delta buffer back to the encoding delta result buffer on the active host, and then sends the results of the encoding process as a memory snapshot to the standby host for decoding and updating the VM memory of the standby VM.

[0031] In an exemplary embodiment, the standby host receives a memory snapshot from the active host. The standby host then iterates through each segment or chunk of the snapshot. For each segment, the process proceeds based on whether the current segment being evaluated is XOR-RLE encoded or plain data. If it is encoded, the standby host performs a decoding process on the segment of data, for example, by performing RLE expansion on each chunk marked as compressed. The decoder then performs an XOR operation on each chunk marked as compressed. In some embodiments, the XOR operation is performed directly in the standby guest VM's main memory at the location indicated by the segment information offset in the segment information sent from the active VM along with the memory snapshot. Alternatively, if the segment is plain data, the plain value of the data is extracted from the segment and copied to a region of memory derived by parsing the original segment list. This iterative process continues until all of the synchronized data has been processed and updates have been applied to the standby VM's memory.

[0032] For clarity of explanation, and without implying any limitations, the exemplary embodiments are described using several exemplary configurations. From this disclosure, one skilled in the art will recognize numerous variations, adaptations, and modifications of the described configurations to achieve the described objectives, which are contemplated within the scope of the exemplary embodiments.

[0033] Furthermore, simplified diagrams of data processing environments are used in the figures and exemplary embodiments. In an actual computing environment, additional structures or components not shown or described herein, or structures or components different from those shown other than those with similar functionality as described herein, may be present without departing from the scope of the exemplary embodiments.

[0034] Furthermore, exemplary embodiments are described with reference to particular actual or hypothetical components, by way of example only. Any particular manifestation of these and other similar artifacts is not intended to limit the invention. Any suitable manifestation of these and other similar artifacts may be selected within the scope of exemplary embodiments.

[0035] The examples in this disclosure are used only for clarity of explanation and are not limited to exemplary embodiments. Any advantages listed herein are examples only and are not intended to limit the exemplary embodiments. Additional or different advantages may be realized by certain exemplary embodiments. Furthermore, certain exemplary embodiments may include some, all, or none of the above-listed advantages.

[0036] Furthermore, exemplary embodiments may be implemented with respect to any type of data, data source, or access to a data source via a data network. Any type of data storage device may provide data to an embodiment of the invention, either locally at a data processing system or through a data network, within the scope of the invention. When an embodiment is described using a mobile device, any type of data storage device suitable for use with a mobile device may provide data to such an embodiment, either locally at the mobile device or through a data network, within the scope of exemplary embodiments.

[0037] Exemplary embodiments are described using particular code, computer-readable storage media, high-level features, designs, architectures, protocols, layouts, diagrams, and tools merely as examples and are not limited to exemplary embodiments. Moreover, for clarity of explanation, exemplary embodiments are described in some cases using particular software, tools, and data processing environments merely as examples. The exemplary embodiments may be used in conjunction with other equivalent or similar purpose structures, systems, applications, or architectures. For example, other equivalent mobile devices, structures, systems, applications, or architectures thereof may be used in conjunction with such embodiments of the invention within the scope of the invention. The exemplary embodiments may be implemented in hardware, software, or a combination thereof.

[0038] The examples in this disclosure are used for clarity of explanation only and are not intended to be limiting of the exemplary embodiments. Additional data, operations, actions, tasks, activities, and operations are recognized from this disclosure and are contemplated within the scope of the exemplary embodiments.

[0039] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that the implementations described herein are not limited to cloud computing environments. Rather, 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 rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0041] The characteristics are as follows:

[0042] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed without requiring human interaction with the provider of the service.

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

[0044] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated on demand. Consumers generally have no control or knowledge over the exact location of the resources provided, although there is some location independence in that it may be possible to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0045] Rapid Elasticity: Capacity can be quickly and elastically provisioned, in some cases automatically, to quickly scale out, and quickly released to quickly scale in. To the consumer, the capacity available for provisioning is often presented as unlimited, and can be purchased in any quantity at any time.

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

[0047] The service model is as follows:

[0048] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including networks, 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 ability offered to consumers is to deploy consumer-created or retrieving applications, written using programming languages ​​and tools supported by the provider, on cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the configuration of the application-hosting environment.

[0050] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other underlying computing resources. Consumers can deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating systems, storage, deployed applications, and in some cases, limited control over selected network components (e.g., host firewalls).

[0051] The deployment model is as follows:

[0052] Private Cloud: Cloud infrastructure is run exclusively for an organization. It may be managed by the organization or a third party and may reside on-premise or off-premise.

[0053] Community Cloud: Cloud infrastructure is shared by multiple organizations to support a specific community of shared interests (e.g., mission, security requirements, policies, and compliance considerations). Community clouds may be managed by those organizations or by a third party and may exist on-premises or off-premises.

[0054] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0055] Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain their own entities but are tied together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting to balance load between clouds).

[0056] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0057] Referring to FIG. 1, this diagram illustrates a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., personal digital assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, and / or automobile computer systems 54N) can communicate. The nodes 10 may also communicate with each other. They may be physically or virtually grouped (not shown) into one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof, as described hereinabove. This enables the cloud computing environment 50 to provide infrastructure, platforms, and / or software as a service for which cloud consumers are not required to maintain resources on their local computing devices. It is understood that the types of computing devices 54A-N illustrated in FIG. 1 are for illustrative purposes only, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device through any type of network, or network-addressable connection, or combination thereof (e.g., using a web browser).

[0058] Referring to Figure 2, this figure illustrates a set of functional abstraction layers provided by cloud computing environment 50 (Figure 1). It should be understood in advance that the components, layers, and functions illustrated in Figure 2 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0059] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based server 62, 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] The virtualization layer 70 provides an abstraction layer from which the following example virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

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

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

[0063] Referring to FIG. 3, this figure shows a block diagram of an example cloud computing environment 300, according to an example embodiment. In the illustrated embodiment, the cloud computing environment 300 includes a service infrastructure 302 that 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 example embodiment. In some embodiments, the IMC 306 is deployed in the workload tier 90 of FIG. 2. By way of example, in some embodiments, the IMC 306 is implemented using the virtual machine management process 96 of FIG. 2.

[0064] In the illustrated embodiment, service infrastructure 302 provides services and service instances to user devices 314. User devices 314 communicate with service infrastructure 302 through API gateway 310. In various embodiments, 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 with unique privileges to a software instance. Service infrastructure 302 ensures that data specific to a tenant 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 one sent 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 for an experience encapsulation process.

[0066] In some embodiments, service infrastructure 302 includes memory 308, which comprises a computer-readable storage medium. In some embodiments, service infrastructure 302 includes one or more instances of virtual machines, including active virtual machine 304A and 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, active virtual machine 304A and standby virtual machine 304B, as well as other service instances of the virtual machines, are registered with service registry 312.

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

[0068] In some embodiments, user device 314 connects to API gateway 310 via any suitable network or combination of networks, such as the Internet, using any suitable communication protocol, such as Wi-Fi or Bluetooth. Service infrastructure 302 may be cloud-computing-based. API gateway 310 provides access to client applications, such as active virtual machine 304A and standby virtual machine 304B. API gateway 310 receives service requests issued by the client applications and creates service lookup requests based on the service requests. As a non-limiting example, in one embodiment, user device 314 executes a routine to initiate interaction with active virtual machine 304A. For example, in some embodiments, a user directly accesses active virtual machine 304A using a command line or a GUI. In other embodiments, a user indirectly accesses active virtual machine 304A by using a web application that interacts with active virtual machine 304A through API gateway 310.

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

[0070] In the illustrated embodiment, the VM environment 400 generally includes an active host 402 and a standby host 406. The active host 402 and the standby host 406 may include computers or computing systems, such as servers, and may be referred to simply as "servers." The active host 402 and the standby host 406 may be implemented as cloud computing nodes 10 of FIG. 1. 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 through network 404. In some embodiments, network 404 includes the Internet and / or aspects of cloud computing environment 50 of FIG. 1 described above.

[0072] The active host 402 includes a CPU 408A, a main memory 410A, and disk storage 412A, while the standby host 406 includes a CPU 408B, a main memory 410B, and disk storage 412B. The CPUs 408A / 408B may contain one or more processors and may be implemented using one or more heterogeneous processor systems. The CPUs 408A / 408B may be multi-core processors. The main memory 410A and / or 410B and the disk storage 412A and / or 412B are some examples of computer-readable storage media. The main memory 410A and / or 410B is typically a form of electronic volatile memory such as DRAM. The disk storage 412A and / or 412B is 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 may be located on storage devices such as disk storage 412A and / or file storage 412B and loaded into main memory 410A and / or 410B for execution by respective CPU 408A or CPU 408B. The processes of the illustrative embodiments may be performed by CPU 408A and / or CPU 408B using computer-implemented instructions, which may be located in a memory such as, for example, main memory 410A and / or main memory 410B. Main memory 410A / 410B and disk storage, file storage 412A / 412B may be any suitable form of computer-readable storage media.

[0073] In an embodiment, active host 402 runs active virtual machine 414A. A virtual machine is a software implementation of a “machine” (e.g., a computing system) that runs applications or programs like a physical computing system or machine. Memory images and disk writes (which may correspond to a memory session and “file system” associated with the virtual machine) of virtual machine 414A are synchronized, mirrored, or replicated to standby host 406, a “backup” or “standby” virtual machine 414B that does not execute while virtual machine 414A is executing on active host 402. If active host 402 fails or is no longer able to run active virtual machine 414A, active virtual machine 414A “fails over” to standby host 406, which can take over execution of standby virtual machine 414B. In this manner, the combination of active host 402 and standby host 406 provides high availability for active virtual machine 414A.

[0074] In some embodiments, synchronization of the two separate memory spaces is performed to promote high availability of a running VM, such as active virtual machine 414A. In some embodiments, the synchronization enables failover in a stateful manner, whereby the CPU, memory, network, and disk storage are all consistently snapshotted. In some embodiments, frequent snapshots of the CPU, memory, network, and disk storage state are collected from active virtual machine 414A and sent to standby virtual machine 414B as a “continuous flow” of updates. Increasing the frequency with which such frequent snapshots are collected and sent reduces potential data loss in the event of a failover. The period between snapshots is called an epoch. In some embodiments, the duration of an epoch may vary from epoch to epoch. For example, the duration of an epoch may be determined by the time it takes an application running in the VM, such as a transactional database, to complete one or more transactions.

[0075] In some embodiments, when the synchronization process is initiated at the end of an epoch, the operation of the active virtual machine 414A is temporarily suspended to allow the CPU registers and caches to be flushed so that the exact state of the active virtual machine 414A can be captured and replicated on the standby virtual machine 414B. The IMC 416A is used to accelerate the synchronization process to minimize the amount of time the active virtual machine 414A is suspended. Additionally, synchronization data that needs to be updated on the standby virtual machine 414B is sent to the IMC 416A using high-speed data transfer techniques, such as direct memory access (DMA), to minimize the amount of time the active virtual machine 414A is suspended.

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

[0077] The data flow can be divided into an active side (encoding) associated with the active host 402 in FIG. 4 and a standby side (decoding) associated with the standby host 406 in FIG. 4. Both sides can be made more efficient using hardware-based parallel processing, such as GPU or CPU threads, or the inherently parallel circuitry of an FPGA. In the illustrated embodiment, the IMC 416A uses a hardware accelerator, such as a GPU or FPGA, to encode data for the active side at the active host 402, and the CPU 408A performs decoding of synchronized snapshot data for the decode side at the standby host 406. In some embodiments, the decode side may include an optional IMC 416B that includes a hardware accelerator for performing decoding. However, in some embodiments, the active virtual machine 414A does not need to wait for data to be decoded on the standby side before resuming operation, so there is less urgency to quickly decode the synchronized data than there is to encode it. For example, in some embodiments, the active virtual machine 414A is first suspended so that 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 be sent to the standby host 406. Once the data is sent to the standby host 406, the active virtual machine 414A can resume operation, which means that the standby host 406 has until the end of the next epoch to complete the decoding.

[0078] Referring to Figure 5, this figure shows a block diagram of a VM environment 500 in accordance with an example embodiment. The example embodiment includes an active host 502 and an IMC 520. In a particular embodiment, the active host 502 is an example of the active host 402 in Figure 4, and the IMC 520 is an example of the IMC 416A in Figure 4.

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

[0080] In the illustrated embodiment, the processor 530 of the IMC 520 and the CPU 504 of the active host 502 perform various computational and data processing tasks and other functions. In some embodiments, the processor 530 includes a hardware accelerator such as a GPU or FPGA. The processor 530 is in communication with a memory 532 and a file storage 534. The CPU 504 is in communication with a main memory 505. In some embodiments, the memory 532, the file storage 534, and the main memory 505 comprise one or more computer-readable storage media that collectively store program instructions, the program instructions in the memory 532 or the file storage 534 being executable by the processor 530 to cause the processor 530 to perform the operations described herein, and the program instructions in the main memory 505 being executable 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 a standby VM (e.g., standby virtual machine 414B). The IMC 520 synchronizes the VM memory 509 so that the standby host can run a standby VM that is identical to the active VM 511. In some embodiments, the IMC 520 synchronizes the active VM 511 many times per second using an epoch-based system in which the execution of the active VM 511 is punctuated by short pauses in execution during which changes made to the VM memory 509 of the active VM 511 are captured and sent to the standby VM.

[0082] In some embodiments, the synchronization procedure involves the CPU 504 of the active host 502 suspending the running active VM 511 and identifying pages in the VM memory 509 of the active VM 511 that have been modified during the current epoch (i.e., dirty pages). In some embodiments, after the active VM 511 is 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 status of each page in the guest 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 contains a respective segment offset, length pair corresponding to the identified contiguous dirty spans in the VM memory 509 (i.e., two adjacent dirty pages embedded in the region defined by the element of the array).

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

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

[0085] In some embodiments, IMC 520 manages synchronization for multiple VMs, e.g., by being time multiplexed to manage synchronization for two or more VMs whose synchronization routine timings are offset in time from one another by a sufficient amount of time to allow synchronization processing for one VM to complete before synchronization processing for the next VM begins. In such embodiments, guest previous memory 514 is sent to guest previous memory buffer 524 via a DMA transaction either before or immediately after a dirty span of VM memory 509 is transferred via a DMA transaction to guest current memory buffer 522 of IMC 520.

[0086] In some embodiments, the synchronization procedure involves the processor 530 performing a multi-threaded, parallelized encoding process of dirty pages received from the active host 502. The data in the guest current memory buffer 522 and the guest previous memory buffer 524 are all packed to occupy a contiguous span of memory addresses in the respective buffers. The packed data is logically partitioned into “chunks” that can be encoded by separate threads. In some embodiments, the chunk information buffer 526 stores information about each chunk, such as multiple segment offset, length pairs corresponding to each chunk. The chunk size must be sufficient to provide the necessary granularity for parallelization across N worker threads, where N is a constraint of the underlying hardware (e.g., nominally 2048 threads for a GPU). For example, in some embodiments, each separate thread performs XOR and RLE encoding on one or more chunks, producing chunk-level results in the encoding delta buffer 528 before transmission. The number of worker threads, N, can vary significantly for different target devices, constrained by the simultaneous memory accesses that the device can support, with a typical FPGA having only 8-16. In such cases, a much larger number of logical threads can be achieved by using sub-threads (sub-kernels) to pipelining memory accesses within a thread.

[0087] A process for implementing XOR-RLE encoding may be provided, for example, using Algorithm 1 provided below in pseudocode. Algorithm 1: XOR-RLE processing / * RLE encode - int32 granularity * / for (unsigned int i=0; i <ints_per_chunk;) { / * write XOR value * / p_result[0] = p_a[i] ^ p_b[i]; unsigned int count = 1; while( ( (p_a[i+count] ^ p_b[i+count]) == p_result [0]) && (count+ i < ints_per_chunk)) { count++; } / * write run-length * / p_result[1]=count; i += count; p_result +=2; }

[0088] In some embodiments, a typical chunk size is 128 pages (512 KiB), although other chunk sizes are possible without departing from this disclosure. When chunks are encoded, they are typically shorter in length than the original chunk size. Chunk location and length information is copied to chunk information buffer 526. In some embodiments, XOR+RLE encoded chunks are structured as shown in Table 1. Table 1 [Table 1] where

number

[0089] If the XOR+RLE compressed chunk is larger than the original chunk size, e.g., due to a large amount of entropy modification, the original contents of the chunk (in the guest's current memory buffer 522) are copied to the encoding delta buffer 528 before transmission, where the chunk is structured as shown in Table 2. Table 2 [Table 2] Note that in some embodiments, the encoding type is included to distinguish between XOR+RLE and plain data in Tables 1 and 2. In some embodiments, when there are only two encoding types, one bit is needed in the binary way.

[0090] Once a chunk has been processed, the contents of the pre-transmission encoding delta buffer 528 can be transferred back to the encoding delta result buffer 518 on the active host 502. To achieve the packed result, the chunk information buffer 526 is first copied back to the active host 502. This chunk information {chunk offset, chunk length} is used to ensure efficient copying of the compressed chunk back to packed form on the active host 502 suitable for transmission to the standby host. The encoding delta result buffer 518 also contains an original segment list 516 that maps the chunks to their original locations in memory.

[0091] In some embodiments, the synchronization procedure includes sending 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 are sent to the standby host, the active VM 511 is unpaused and resumes execution, which represents a transition to a new epoch.

[0092] Referring to FIG. 6, this figure shows a block diagram of an example VM environment 600, in accordance with an exemplary embodiment. The exemplary embodiment is similar to the VM environment 400 of FIG. 4, except that in the VM environment 600, the IMC 616A includes a NIC 618A that enables the IMC 616A to communicate with a standby host 606 over a network 604. In the VM environment 400, the IMC 416A sends synchronized data to the active host 402, which then sends it to the standby host 406. In the VM environment 600, the IMC 616A uses the NIC 618A to send synchronized data (memory snapshots) to the standby host 606, without having to first send it to the active host 602. The description of the active host 402 in FIG. 4 applies equally to the active host 602, and the description of the standby host 406 in FIG. 4 applies equally to the standby host 606. Additionally, in some embodiments, the standby host 606 uses an optional IMC 616B that includes a NIC 618B for receiving and decoding synchronized data from the IMC 616A.

[0093] Referring to FIG. 7, this figure shows a block diagram of a VM environment 700 in accordance with an exemplary embodiment. The exemplary embodiment is similar to the VM environment 500 of FIG. 5, except that in the VM environment 700, the IMC 720 includes a NIC 736 that enables the IMC 720 to communicate with a standby host over a network. In the VM environment 500, the IMC 520 sends the synchronization data to the active host 502, which then sends it to the standby host. In the VM environment 700, the IMC 720 uses the NIC 736 to send the synchronization data (memory snapshot) to the standby host, eliminating the need to first send it to the active host 702. The description of the active host 502 of FIG. 5 applies equally to the active host 702, except that the active host 702 does not need a result buffer, such as the encoded delta result buffer 518 of FIG. 5, because the IMC 720 sends the result data directly to the standby host. The description of IMC 520 in FIG. 5 applies equally to IMC 720, except that IMC 720 includes NIC 736.

[0094] Referring to FIG. 8, this figure shows a block diagram of a VM environment 800 in accordance with an example embodiment. The example embodiment includes an active host 802 and an IMC 804. The illustration of the active host 802 and IMC 804 has been simplified to clearly illustrate one embodiment of a DMA transaction. In some embodiments, the active host 802 is an example of the active host 402 of FIG. 4, the active host 502 of FIG. 5, the active host 602 of FIG. 6, or the active host 702 of FIG. 7. In some embodiments, the IMC 804 is an example of the IMC 306 of FIG. 3, the IMC 416A of FIG. 4, the IMC 520 of FIG. 5, the IMC 616A of FIG. 6, or the IMC 720 of FIG. 7.

[0095] In some embodiments, the synchronization procedure involves the active host 802 suspending running active VMs and identifying pages of VM memory that have been modified during the current epoch (i.e., dirty pages). In some embodiments, after the active VMs are suspended, the VM cache is flushed and the hypervisor iterates through the dirty page bitmap (a collection of bits representing the clean / dirty status of each page in the guest 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 contains a respective segment offset, length pair corresponding to the identified contiguous dirty spans in VM memory (i.e., two adjacent dirty pages embedded in the region defined by the array element).

[0096] In some embodiments, the synchronization procedure includes the DMA controller performing DMA transactions to transfer non-contiguous dirty spans of VM memory, denoted as non-contiguous spans A', B', C', and D', in the guest's current memory 806. The synchronization procedure also includes the DMA controller performing DMA transactions to transfer the same spans of previous versions of memory, denoted as spans A, B, C, and D, in the guest's previous memory 808. In some embodiments, the previous versions are the most recent previous versions of memory synchronized with the standby VM. In some embodiments, the segment offsets and lengths of each of spans A, B, C, and D match the segment offsets and lengths of each of spans A', B', C', and D'.

[0097] In the illustrated embodiment, non-contiguous spans A', B', C', and D' are copied via DMA transactions to a series of contiguous memory addresses in guest current memory buffer 812 of IMC 804. Also, in the illustrated embodiment, non-contiguous spans A, B, C, and D are copied via DMA transactions to a series of contiguous memory addresses in guest previous memory buffer 814 of IMC 804. In the illustrated embodiment, non-contiguous spans A', B', C', and D' are copied via DMA transactions to a series of contiguous memory addresses in guest current memory buffer 812 of IMC 804. Packing the data in guest current memory buffer 812 and guest previous memory buffer 814 enables data alignment into dense data computations well suited for processing by hardware accelerators such as GPUs or FPGAs. This further enables compression workloads to be divided into chunks of packed data to support data parallelism. An output segment buffer can then be utilized to collect the encoded (compressed) data in contiguous memory for transmission to the standby VM.

[0098] Referring to FIG. 9, this figure illustrates a block diagram of a VM environment 900 in accordance with an exemplary embodiment. The exemplary embodiment includes an active host 902 and an IMC 904. The illustration of the active host 902 and IMC 904 is simplified to clearly illustrate one embodiment of a multi-threaded XOR-RLE process in accordance with an exemplary embodiment. In some embodiments, the active host 902 is an example of the active host 402 of FIG. 4, the active host 502 of FIG. 5, the active host 602 of FIG. 6, or the active host 702 of FIG. 7. In some embodiments, the IMC 904 is an example of the IMC 306 of FIG. 3, the IMC 416A of FIG. 4, the IMC 520 of FIG. 5, the IMC 616A of FIG. 6, or the IMC 720 of FIG. 7.

[0099] In some embodiments, the synchronization procedure involves the hardware accelerator performing a multi-threaded, parallelized encoding process of dirty pages received from the active host 902. Data spans A', B', C', and D' in the guest's current memory buffer and data spans A, B, C, and D in the guest's previous memory buffer are all packed to occupy contiguous spans of memory addresses in their respective buffers. The packed data is logically partitioned into "chunks" that can be encoded by separate threads. The size of the chunks must be sufficient to provide the necessary granularity for parallelization across N worker threads, where N is a constraint of the underlying hardware (e.g., nominally 2048 threads for a GPU). Figure 9 shows five worker threads for simplicity; an actual implementation may include hundreds or thousands of threads.

[0100] In some embodiments, each separate thread performs XOR and RLE encoding on one or more chunks in the compression module 910, producing respective chunk-level results dA, dA, dB, dC, and dD in the result buffer 912. Once the chunks 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. To achieve the packed results, a chunk information buffer is first copied back to the active host 902. This chunk information {chunk offset, chunk length} is used to ensure efficient copying of the compressed chunks back to packed form on the active host 902 suitable for transmission to the standby host. The XOR-RLE result buffer 906 also contains an original segment list that maps the chunks to their original locations in memory.

[0101] In some embodiments, the synchronization procedure includes sending 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 are sent to the XOR-RLE result buffer 906, the active host 902 unpauses the active VM and execution resumes, which represents a transition to a new epoch.

[0102] 10, which illustrates a block diagram of a VM environment 1000 in accordance with an exemplary embodiment. The exemplary embodiment includes a standby host 1002. The illustration of the standby host 1002 is simplified to clearly illustrate one embodiment of a multi-threaded XOR-RLE decryption process in accordance with an exemplary embodiment. In some embodiments, the standby host 1002 is an example of the standby host 406 of FIG. 4 or the standby host 606 of FIG. 6.

[0103] In the illustrated embodiment, the standby host 1002 receives a memory snapshot as synchronization data from the active VM along with segment information (e.g., segment information 908 in FIG. 9 ). The standby host 1002 performs a decoding process on the received synchronization data. In some embodiments, an expansion (decoding) module 1004 detects the encoding type (XOR-RLE encoding or plain data) for each chunk and then decodes (e.g., performs RLE expansion) each chunk marked as compressed (rather than plain data copy). The XOR decoding module 1006 then performs an XOR operation on each chunk output from the expansion module 1004. In some embodiments, the XOR operation is performed directly in the standby guest VM's main memory 1008 at a location indicated by the segment information offset in the segment information sent from the active VM along with the memory snapshot. The decoder's primary implementation uses a streaming abstraction to "distribute" encoded values ​​(as 32-bit integers) that can be applied (XORed) or assigned (plain copied) to regions of memory derived by parsing the original segment list.

[0104] 11, a flowchart of an example process 1100 for encoding processing according to an exemplary embodiment is shown. In a particular embodiment, an IMC306, an IMC416A, an IMC520, an IMC616A, an IMC720, an IMC804, or an IMC904 performs the process 1100.

[0105] In one embodiment, at block 1102, the synchronization process includes the active host suspending running active VMs and identifying pages of VM memory that have been modified during the current epoch (i.e., dirty pages). In some embodiments, after the active VMs are suspended, the VM cache is flushed and the hypervisor iterates through the dirty page bitmap (a collection of bits representing the clean / dirty status of each page in the guest 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 contains a respective segment offset, length pair corresponding to the identified contiguous dirty spans in the VM memory (i.e., two adjacent dirty pages incorporated into the region defined by the element of the array).

[0106] Next, in block 1106, the synchronization process includes the DMA controller performing DMA transactions to transfer the non-contiguous dirty spans of the VM memory to a series of contiguous memory addresses of the guest's current memory buffer of the IMC. In some embodiments, a segment list is used to copy the contents of the non-contiguous dirty spans in packed form (i.e., at contiguous addresses) into the guest's current memory buffer of the IMC via DMA transactions. Also, in block 1108, the segment list is used to copy the contents of the non-contiguous dirty spans into the guest's current memory of the active host.

[0107] In blocks 1110 and 1112, the synchronization process involves a processor, preferably a hardware accelerator such as a GPU or FPGA, performing multi-threaded, parallelized encoding of dirty pages received from the active host. Data in the guest's current memory buffer and the guest's previous memory buffer are all packed to occupy a contiguous span of memory addresses in the respective buffers. The packed data is logically partitioned into "chunks" that can be encoded by separate threads. In some embodiments, a chunk information buffer stores information about each chunk, such as multiple segment offset, length pairs corresponding to each chunk. The chunk size must be sufficient to provide the necessary granularity for parallelization across N worker threads, where N is a constraint 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 chunks, producing chunk-level results in an encoding delta buffer before transmission. The number of worker threads, N, can vary significantly for different target devices, constrained by the simultaneous memory accesses that the device can support, with a typical FPGA having only 8-16. In such cases, a much larger number of logical threads can be achieved by using sub-threads (sub-kernels) to pipelining memory accesses within a thread.

[0108] Next, in block 1114 and optionally in case the IMC does not have a NIC, 1116, the synchronization process proceeds based on the results of comparing the size of the XOR+RLE compressed chunk with the original chunk size. If the compressed version is larger, for example due to a large amount of entropy correction, then in block 1114 the original contents of the chunk (in the guest's current memory buffer) are copied to the pre-send encoded delta buffer. Otherwise, in block 1116 the compressed version is copied to the pre-send encoded delta buffer. This comparison is performed for each chunk individually until all chunks have been processed and stored in the pre-send encoded delta buffer.

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

[0110] 12, a flowchart of an example process 1200 of decryption processing according to an example embodiment is shown. In a particular embodiment, the standby host 406, the standby host 606, or the standby host 1002 performs the process 1100.

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

[0112] If the segment is plain data at block 1206, then the plain value of the data is extracted from the segment at block 1208. The data is then copied to an area of ​​memory derived from parsing the original segment list at block 1210. This iterative process continues until all of the synchronized data has been processed and incorporated into the standby VM's memory.

[0113] The following definitions and abbreviations are used in interpreting the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," or "containing," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device 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 device.

[0114] Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include any integer greater than or equal to 1, i.e., 1, 2, 3, 4, etc. The term "plurality" is understood to include any integer greater than or equal to 2, i.e., 2, 3, 4, 5, etc. The term "connected" can include indirect and direct "connections."

[0115] References in the specification to "one embodiment," "embodiment," "exemplary embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but all embodiments may or may not include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with one embodiment, it is believed to be within the knowledge of one of ordinary skill in the art that such feature, structure, or characteristic also applies in connection with other embodiments, whether or not explicitly described.

[0116] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with a particular quantitative indication based on equipment available at the time of filing. For example, "about" can include a range of ±8%, or 5%, or 2% of a given value.

[0117] The description of various embodiments of the present invention has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable others skilled in the art to understand the embodiments described herein.

[0118] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable others skilled in the art to understand the embodiments described herein.

[0119] Thus, computer-implemented methods, systems, or apparatus, and computer program products are provided in exemplary embodiments for managing participation in online communities and other related features, functions, or operations. Where an embodiment, or portions thereof, are described with respect to a type of device, the computer-implemented method, system, or apparatus, computer program product, or portions thereof, is adapted or configured for use with suitable and equivalent manifestations of that type of device.

[0120] When an embodiment is described as being implemented in an application, delivery as an application in a Software-as-a-Service (SaaS) model is considered within the scope of the exemplary embodiment. In the SaaS model, the capabilities of an application implementing an embodiment are provided to users by running the application in a cloud infrastructure. Users 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 application. Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage of the cloud infrastructure. In some cases, users may not even manage or control the capabilities of the SaaS application. In some other cases, a SaaS implementation of an application may allow for the possible exception of limited user-specific application configuration settings.

[0121] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to implement aspects of the present invention.

[0122] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0123] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or both. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A 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 for storage in a computer-readable storage medium in the respective computing / processing device.

[0124] Computer-readable program instructions for carrying out operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source 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 the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, 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 the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions to personalize the electronic circuitry by utilizing state information of the computer-readable program instructions to implement aspects of the present invention.

[0125] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0126] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine whereby the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, whereby the computer-readable storage medium having instructions stored therein has an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0127] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and a series of operational steps performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in the block(s) of the flowcharts and / or block diagrams.

[0128] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or a combination of special-purpose hardware and computer instructions.

[0129] Embodiments of the present invention may also be delivered as part of a service engagement with a client company, a nonprofit organization, a government agency, an internal organizational structure, or the like. 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 client behavior, making recommendations in response to the analysis, building a system that implements some of the recommendations, integrating the system into existing processes and infrastructure, metering system usage, allocating expenditures to users of the system, and billing for system usage. While the above embodiments of the present invention have each been described by describing their respective individual advantages, the present invention is not limited to any particular combination thereof. Conversely, such embodiments may also be combined in any manner and number in accordance with the intended deployment of the present invention without losing their advantageous effects.

Claims

1. 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 each span of consecutive memory addresses, wherein the concurrent threads control a compression operation of each portion of the current snapshot data to result in a corresponding portion of processed current snapshot data, the concurrent threads having a first thread bound to a hardware accelerator that performs the compression operation of a first portion of the current snapshot data; and transmitting the processed current snapshot data to a standby VM as a current synchronized snapshot of the active VM. A computer-implemented method comprising:

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

3. 2. The computer-implemented method of claim 1, wherein the current snapshot data includes pages of memory that have been designated as having changed since a previous synchronized snapshot of the active VM, the previous synchronized snapshot being referred to as previous snapshot data.

4. writing, by the IMC, the previous snapshot data 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; The computer-implemented method of claim 3 further comprising:

5. The compressing of the first portion of the current snapshot data comprises: performing, by the hardware accelerator, an exclusive-or operation between a raw data version of the first portion of the current snapshot data and a corresponding raw data version of the first portion of the previous snapshot data; wherein the exclusive-or operation results in a delta-encoded version of the first portion of the current snapshot data; The computer-implemented method of claim 3 , wherein the delta-encoded version represents memory changes in the first portion of the current snapshot compared to the corresponding first portion of the previous snapshot data.

6. The compressing of the first portion of the current snapshot data comprises: performing, by the hardware accelerator, a run-time length encoding (RLE) operation on the delta-encoded version of the first portion of the current snapshot data; The computer-implemented method of claim 5 , wherein the RLE operation results in an RLE encoded version of the first portion of the current snapshot data.

7. The compressing of the first portion of the current snapshot data comprises: outputting the smaller of the raw data version and the RLE encoded version of the first portion of the current snapshot data as the first portion of the processed current snapshot data. The computer-implemented method of claim 6 , comprising:

8. replacing the previous snapshot data with the current snapshot data, such that the current snapshot data is used as the previous snapshot data, while generating subsequent synchronized snapshots of the active VM, by the IMC; The computer-implemented method of claim 7 further comprising:

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

10. The computer-implemented method of claim 1 , wherein the hardware accelerator comprises a field programmable gate array (FPGA).

11. 1. A computer program product comprising one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions 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 each span of consecutive memory addresses, wherein the concurrent threads control compression of each portion of the current snapshot data to result in a corresponding portion of processed current snapshot data, the concurrent threads having a first thread bound to a hardware accelerator that performs the compression of a first portion of the current snapshot data; and sending the processed current snapshot data to a standby VM as a current synchronized snapshot of the active VM; Executable by a processor to cause the processor to perform operations including: Computer program products.

12. 12. The computer program product of claim 11, wherein the stored program instructions are stored on a computer-readable storage device within a data processing system, and wherein the stored program instructions are transferred over a network from a remote data processing system.

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

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

15. 12. The computer program product of claim 11, wherein the current snapshot data includes pages of memory that have been designated as having changed since a previous synchronized snapshot of the active VM, the previous synchronized snapshot being referred to as previous snapshot data.

16. writing, by the IMC, the previous snapshot data 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; 16. The computer program product of claim 15, further comprising:

17. 1. A computer system comprising a processor and one or more computer-readable storage media, and program instructions collectively stored on the one or more computer-readable storage media, the program instructions 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 each span of consecutive memory addresses, wherein the concurrent threads control compression of each portion of the current snapshot data to result in a corresponding portion of processed current snapshot data, the concurrent threads having a first thread bound to a hardware accelerator that performs the compression of a first portion of the current snapshot data; and sending the processed current snapshot data to a standby VM as a current synchronized snapshot of the active VM; Executable by the processor to cause the processor to perform operations including: Computer system.

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

19. 20. The computer system of claim 17, wherein the current snapshot data includes pages of memory that have been designated as having changed since a previous synchronized snapshot of the active VM, the previous synchronized snapshot being referred to as previous snapshot data.

20. writing, by the IMC, the previous snapshot data 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; 20. The computer system of claim 19, further comprising:

Images