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 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 Art]]

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

[0002] A virtual machine (VM) is a software-defined computer and guest operating system that runs on a host system that operates its own host operating system. A VM includes 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 optionally various other virtual devices. A VM represents a form of system virtualization implemented by some management functions, typically hypervisor technology.

[0003] A host system is a data processing system such as a server. The host system may have any number of VMs configured therein depending on the available system resources of the host and the demands of the VMs. For example, in a large-scale data processing environment such as a data center, hundreds or even thousands of VMs may be running on one host at any time, and hundreds or thousands of such hosts may be operable in the data center at any time. Such large-scale virtualized data processing environments are capable of providing computing resources on demand to a number of different clients. [[Summary of the Invention]]

[0004] Exemplary embodiments provide accelerated coding for virtual machine synchronization. One embodiment includes the step of an intelligent memory controller (IMC) writing current snapshot data to a first set of contiguous 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 embodiment also includes the step of the IMC executing concurrent threads associated with each span of the contiguous memory addresses, where the concurrent threads control a compression process on each portion of the current snapshot data to yield a corresponding portion of the processed current snapshot data, and the concurrent threads have a first thread bound to a hardware accelerator that performs the compression process on the first portion of the current snapshot data. The embodiment also includes the step of sending the processed current snapshot data to a standby VM as the current synchronized 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] One embodiment includes a computer-readable program product. The computer-readable program product includes a computer-readable storage medium and program instructions stored on the storage medium.

[0006] One embodiment includes a computer system. The computer system includes a processor, computer-readable memory, and a computer-readable storage medium, and includes program instructions stored in the storage medium, which are executed by the processor via the memory. [Brief explanation of the drawing]

[0007] Novel characteristics considered characteristic of the present invention are described in the appended claims. However, the invention itself, as well as preferred modes of use, further its purposes and advantages, will be best understood by referring to the following detailed description of exemplary embodiments, when read in conjunction with the accompanying drawings.

[0008] [Figure 1] This document demonstrates a cloud computing environment using one embodiment of the present invention.

[0009] [Figure 2] An abstraction model layer according to one embodiment of the present invention is shown.

[0010] [Figure 3] A block diagram of an example cloud computing environment is shown, based on an exemplary embodiment.

[0011] [Figure 4] A block diagram of an example VM environment is shown, based on an exemplary embodiment.

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

[0013] [Figure 6] A block diagram of an example VM environment is shown, based on an exemplary embodiment.

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

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

[0016] [Figure 9] A block diagram of a VM environment according to an exemplary embodiment is shown.

[0017] [Figure 10] FIG. 1 is a block diagram of a VM environment according to an exemplary embodiment.

[0018] [Figure 11] FIG. 2 is a flowchart of an exemplary process for encoding processing according to an exemplary embodiment.

[0019] [Figure 12] FIG. 3 is a flowchart of an exemplary process for decoding processing according to an exemplary embodiment. DETAILED DESCRIPTION OF EMBODIMENTS

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

[0021] By maintaining a periodically synchronized standby VM, the amount of data that needs to be transferred during VM failover is reduced, thereby reducing the period during which the VM is interrupted during migration. However, such techniques have problems that adversely affect VM functionality due to inefficiencies in the synchronization process. For example, these types of active-standby techniques use synchronization processes involving substantial page table traversal and data copy overhead, resulting in significant VM downtime. The main contributor to this overhead is that many applications using this approach copy more data than necessary, resulting in data copy amplification; this arises due to the design of processor virtual memory systems where memory pages are 4KiB or larger. For example, one byte written to one page will result in copying of the entire 4KiB (or larger) page during the next synchronization.

[0022] Aspects of this disclosure address the aforementioned shortcomings by providing a mechanism (e.g., a system, method, machine-readable medium, etc.) for performing high-frequency memory synchronization faster and more efficiently than prior art. This disclosure recognizes that existing page protection can be leveraged to reduce the number of pages compressed for synchronization (i.e., only dirty and marked pages). This 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 to dense data computations better suited to processing by a hardware accelerator such as a GPU or FPGA. Furthermore, this makes it possible to divide the compressed workload into chunks of packed data to support data parallel processing. An output segment buffer can then be used to collect the encoded (compressed) data in contiguous memory and send it to the standby VM. This disclosure further recognizes that as soon as the memory data is copied to the hardware accelerator for compression, the active VM may continue to assume that the epoch is longer than the total time it takes for the hardware accelerator to encode the data and send that data to the standby VM.

[0023] Based on these findings, the mechanisms of this disclosure provide a synchronization technique that significantly reduces the amount of time required to generate synchronized snapshots of the VM main memory and CPU state. The mechanisms of this disclosure also provide a synchronization technique that significantly reduces the volume of data sent to the standby VM for synchronization. These mechanisms of this disclosure reduce the downtime caused by synchronizing the standby VM with the active VM and provide a synchronization method that enables active-standby schemes using the disclosed synchronization techniques to be deployed over more limited bandwidth networks (e.g., across data centers) where it would be impossible to do so using conventional synchronization techniques.

[0024] When a computer or data processing system is described as a virtual machine, virtual device, or virtual component, that virtual machine, virtual device, or virtual component operates in such a way that the data processing system uses a virtualized embodiment of some or all of the components of the data processing system. For example, in a virtual machine, virtual device, or virtual component, a processing unit is explicitly described as a virtualized instance of all or some of the hardware processing units that may be available in the host data processing system; main memory is explicitly described as a virtualized instance of all or some of the main memory that may be available in the host data processing system; and disk memory is explicitly described as a virtualized instance of all or some of the disk memory that may be available in the host data processing system.

[0025] In an exemplary embodiment, the active-standby synchronization process includes, once per epoch, the active host suspending the running active VM and identifying pages of VM memory that were 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 state of each page in 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 pair of segment offsets, lengths, corresponding to an identified contiguous dirty span in VM memory (i.e., two adjacent dirty pages incorporated into the region defined by the elements of the array).

[0026] In exemplary embodiments, the synchronization process includes a DMA controller that performs a DMA transaction to transfer a non-contiguous dirty span of VM memory to a set of contiguous memory addresses in the 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 span in a packed form (i.e., at contiguous addresses) to the guest's current memory buffer of the IMC via a DMA transaction. The segment list is then used to copy the contents of the non-contiguous dirty span to the guest's current memory on the active host.

[0027] In exemplary embodiments, the IMC includes a processor, preferably a hardware accelerator such as a GPU or FPGA, that performs multithreaded, 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 buffers are all packed so that they occupy a contiguous span of memory addresses in their 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 pairs of segment offsets and lengths corresponding to each chunk. The size of the chunks must be sufficient to provide the granularity required 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, producing chunk-level results in an encoding delta buffer before transmission. In some embodiments, the encoding includes XOR-RLE encoding. While exemplary embodiments are described herein using XOR-RLE coding, alternative embodiments may use other types of coding. For example, alternative embodiments may use LZ4 or DEFLATE coding with or without XOR.

[0028] The number of worker threads N can vary significantly across different target devices, and is limited by the number of simultaneous memory accesses the device can support, typically ranging from 8 to 16 in a typical FPGA. In such cases, many more logical threads can be implemented by using subthreads (subkernels) to pipeline memory access within threads.

[0029] In an exemplary embodiment, the synchronization process proceeds based on a comparison of the size of the chunk compressed by XOR+RLE with the original chunk size. For example, if the compressed version is larger due to many entropy corrections, the original content of the chunk (in the guest's current memory buffer) is copied to the pre-transmission coded delta buffer on the IMC. Otherwise, the compressed version is copied to the pre-transmission coded delta buffer. This comparison is performed individually for each chunk until all of them have been processed and stored in the pre-transmission coded delta buffer.

[0030] In an exemplary embodiment, the synchronization process transfers the contents of the pre-transmission encoded delta buffer back to the encoded delta result buffer on the active host. The process then sends the result of the encoding process to the standby host as a memory snapshot 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 decodes the segment of data, for example by performing RLE expansion on each of the compressed and marked chunks. The decoder then performs an XOR operation on each of the compressed and marked chunks. In some embodiments, the XOR operation is performed directly in the main memory of the standby guest VM at the location indicated by the segment information offset in the segment information sent from the active VM along with the memory snapshot. If, instead, the segment is plain data, the plain values ​​of the data are extracted from the segment and copied to a region of memory derived by parsing the original segment list. This iteration of the process continues until all the synchronization data has been processed and the updates have been applied to the standby VM's memory.

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

[0033] Furthermore, simplified diagrams of the data processing environment are used in the figures and exemplary embodiments. In actual computing environments, additional structures or components not shown or described herein, or structures or components different from those shown but with functions similar to those described herein, may exist without departing from the scope of the exemplary embodiments.

[0034] Furthermore, the exemplary embodiments are described merely as examples with respect to specific actual or hypothetical components. Any particular embodiment of these and other similar artifacts is not intended to limit the invention. Any preferred embodiment of these and other similar artifacts may be selected within the scope of the exemplary embodiments.

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

[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, within the scope of the invention, provide data to one embodiment of the invention, either locally in a data processing system or via a data network. When one embodiment is described using a mobile device, any type of data storage device suitable for use with a mobile device may, within the scope of the exemplary embodiment, provide data to such embodiment, either locally in the mobile device or via a data network.

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

[0038] The examples in this disclosure are for illustrative purposes only and are not limited to exemplary embodiments. Additional data, behaviors, actions, tasks, activities, and operations may be recognized in this disclosure and are conceivable within the scope of the exemplary embodiments.

[0039] While this disclosure includes a detailed description 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 that is currently known or may be developed in the future.

[0040] Cloud computing is a service delivery model that enables 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 administrative effort or interaction with service providers. This cloud model may 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 power, such as server time and network storage, automatically as needed, without requiring human interaction with the service provider.

[0043] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin client platforms 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, with different physical and virtual resources dynamically allocated and reallocated as needed. Consumers generally have no control or knowledge of the exact location of the resources provided, although they may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center), thus exhibiting a degree of location independence.

[0045] Rapid Scaleability: Capabilities can be provisioned quickly and flexibly, sometimes automatically, to scale out rapidly, and released quickly to scale in rapidly. For consumers, the available capacity for provisioning often appears unlimited and can be purchased in any quantity at any time.

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

[0047] The service model is as follows:

[0048] Software as a Service (SaaS): The capability offered to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible from various client devices via thin client interfaces, such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the exception of limited user-specific application configuration settings.

[0049] Platform as a Service (PaaS): The ability offered to consumers is the ability to deploy consumer-created or acquired applications, written using programming languages ​​and tools supported by the provider, on cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do control the configuration of the deployed applications and, in some cases, the application hosting environment.

[0050] Infrastructure as a Service (IaaS): The capability offered to consumers is the provisioning of processing, storage, networking, and other fundamental 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 system, storage, deployed applications, and, in some cases, have limited control over selected networking components (e.g., host firewalls).

[0051] The deployment model is as follows:

[0052] Private Cloud: A cloud infrastructure operates exclusively for a particular organization. It may be managed by the organization or a third party and may reside on-premises or off-premises.

[0053] Community Cloud: A cloud infrastructure is shared by multiple organizations to support a specific community that shares interests (e.g., mission, security requirements, policies, and compliance considerations). The community cloud may be managed by those organizations or a third party and may reside 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 an organization that sells cloud services.

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

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

[0057] Referring to Figure 1, this figure shows a cloud computing environment 50. As shown in the figure, the cloud computing environment 50 comprises one or more cloud computing nodes 10 to 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 automotive computer systems 54N, etc.) can communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped (not shown) into one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or a combination thereof, as described above in this specification. This enables the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services to cloud consumers, eliminating the need for them to maintain resources on their local computing devices. The types of computing devices 54A-N shown in Figure 1 are for illustrative purposes only, and it should be understood 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 connectivity, or a combination thereof (e.g., using a web browser).

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

[0059] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based servers 62, 63, blade servers 64, storage devices 65, and networks 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 may be provided: a virtual server 71, virtual storage 72, a virtual network 73 including a virtual private network, a virtual application and operating system 74, and a virtual client 75.

[0061] In one example, the management layer 80 may provide the functions described below: Resource provisioning 81 provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are used 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 consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to ensure that required service levels are met. Service level agreement (SLA) planning and execution 85 provides pre-organization and acquisition of cloud computing resources that are expected to be needed in the future in accordance with the SLA.

[0062] The workload layer 90 provides examples of functions that can be utilized in a cloud computing environment. 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 education delivery 93, data analysis processing 94, transaction processing 95, and, in the context of the embodiments illustrated in this disclosure, various workloads and functions 96 for virtual machine management processing, including processing to synchronize two separate memory spaces and facilitate high availability (HA) of running VMs. Furthermore, workloads and functions 96 may include operations such as data encoding / decoding and memory management as described herein. In some embodiments, workloads and functions 96 also work in conjunction with other parts of various abstraction layers, such as hardware and software 60, virtualization 70, and management 80, to achieve various objectives of the embodiments disclosed.

[0063] Referring to Figure 3, this figure shows a block diagram of an exemplary cloud computing environment 300 according to an exemplary embodiment. In the exemplary 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 the active virtual machine 304A and the standby virtual machine 304B according to the exemplary embodiment. In some embodiments, the IMC 306 is deployed in the workload layer 90 of Figure 2. For example, in some embodiments, the IMC 306 is implemented using the virtual machine management process 96 of Figure 2.

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

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

[0066] In some embodiments, the service infrastructure 302 includes memory 308 having 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, as well as other service instances of the virtual machine, are registered in a service registry 312.

[0067] In some embodiments, the service registry 312 maintains information about the status 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 of a given service instance (e.g., cache metrics) and update records.

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

[0069] Referring to Figure 4, this figure shows a block diagram of an example VM environment 400 according to an exemplary embodiment. The exemplary embodiment includes an IMC416A, which provides high-frequency memory synchronization between the active host 402 and the standby host 406 according to the exemplary embodiment. In a particular embodiment, the IMC416A is an example of the IMC306 in Figure 3, the active host 402 is an example of the active virtual machine 304A in Figure 3, and the standby host 406 is an example of the standby virtual machine 304B in Figure 3.

[0070] In the exemplary embodiments, 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 can simply be referred to as “servers”. The active host 402 and the standby host 406 may be implemented as the cloud computing node 10 in Figure 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 contained on a single hardware device having two or more processors or processor cores.

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

[0072] The active host 402 includes a CPU 408A, main memory 410A, and disk storage 412A, while the standby host 406 includes a CPU 408B, main memory 410B, and disk storage 412B. The CPU 408A / 408B may house one or more processors and may be implemented using one or more heterogeneous processor systems. The CPU 408A / 408B may be a multicore processor. 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 electronically 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 systems, and applications or programs may reside on storage devices such as disk storage 412A and / or file storage 412B and be loaded into main memory 410A and / or 410B to be executed by the respective CPUs 408A and 408B. Processes of exemplary embodiments may be executed by CPUs 408A and / or 408B using computer implementation instructions that may reside in memory, for example, main memory 410A and / or main memory 410B. Main memory 410A / 410B, and disk storage, file storage 412A / 412B can be any preferred form of computer-readable storage medium.

[0073] In this embodiment, the active host 402 runs the active virtual machine 414A. A virtual machine is a software implementation of a “machine” (e.g., a computing system) that runs an application or program like a physical computing system or machine. Memory images and disk writes of virtual machine 414A (which may correspond to memory sessions and “file systems” associated with the virtual machine) are synchronized, mirrored, or replicated to the standby host 406 of a “backup” or “standby” virtual machine 414B that does not run while virtual machine 414A is running on the active host 402. If the active host 402 fails or it becomes impossible to run the active virtual machine 414A, the active virtual machine 414A “fails over” to the standby host 406, which can then take over the execution of the standby virtual machine 414B. Thus, the combination of the active host 402 and the standby host 406 provides high availability for the active virtual machine 414A.

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

[0075] In some embodiments, if the synchronization process is initiated at the end of an epoch, the operation of the active virtual machine 414A may be temporarily suspended to flush the CPU registers and cache, allowing the exact state of the active virtual machine 414A to be captured and replicated on the standby virtual machine 414B. The IMC416A 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 IMC416A 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 IMC416A implements a data compression process that includes a modified XOR-RLE scheme optimized for existing accelerator devices, such as GPUs and FPGAs. In some such embodiments, the compression process is implemented using data parallelism so that a large number of threads (e.g., thousands) collectively perform the XOR-RLE operation.

[0077] The data flow can be divided into an active side (encoding) associated with the active host 402 in Figure 4, and a standby side (decoding) associated with the standby host 406 in Figure 4. Both sides can be made more efficient using hardware-based parallel processing, such as GPU or CPU threads, or the inherently parallel circuits of an FPGA. In the illustrated embodiment, IMC416A uses a hardware accelerator such as a GPU or FPGA to encode the active-side data on the active host 402, and CPU408A performs the decoding of the synchronous snapshot data on the decoding side on the standby host 406. In some embodiments, the decoding side may include an optional IMC416B which includes a hardware accelerator for performing the decoding. However, in some embodiments, the urgency to quickly decode the synchronous data is lower than the urgency to encode the synchronous data, as 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 synchronization data can be detected and sent to the IMC416A, which then encodes the data, sends it back to the active host 402, and sends it to the standby host 406. Once the data is sent to the standby host 406, the active virtual machine 414A can resume operation. This means that the standby host 406 has time 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 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 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, the active host 502 includes a CPU 504, a DMA controller 510, and an active VM 511 loaded into main memory 505 by the CPU 504 running a hypervisor 513. The main memory 505 also includes the guest's current memory 512, the guest's previous memory 514, an encoded delta result buffer 518, and a segment list 516. The active VM 511 includes a VM cache 507 and VM memory 509. The IMC 520 includes the guest's current memory buffer 522, the guest's previous memory buffer 524, a chunk information buffer 526, a pre-transmit encoded delta buffer 528, a processor 530, memory 532, and file storage 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 grouped into one or more modules in different ways. In some embodiments, the functions described herein are distributed across 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 exemplary embodiments, the processor 530 of the IMC520 and the CPU 504 of the active host 502 perform various computational and data processing tasks, as well as other functions. In some embodiments, the processor 530 includes a hardware accelerator such as a GPU or FPGA. The processor 530 communicates with memory 532 and file storage 534. The CPU 504 communicates with main memory 505. In some embodiments, memory 532, file storage 534, and main memory 505 comprise one or more computer-readable storage media, which collectively store program instructions, and program instructions in memory 532 or file storage 534 are executable by the processor 530, causing the processor 530 to perform the operations described herein, and program instructions in main memory 505 are executable by the CPU 504, causing the CPU 504 to perform the operations described herein.

[0081] In the illustrated embodiments, the IMC520 manages the synchronization of the VM memory 509 of the active VM 511 with the VM memory of the standby VM (e.g., standby virtual machine 414B). The IMC520 synchronizes the VM memory 509 so that the standby host can run a standby VM that is equal to the active VM 511. In some embodiments, the IMC520 synchronizes the active VM 511 many times per second using an epoch-based system, in which the execution of the active VM 511 is interrupted by short pauses during 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 includes, once per epoch, 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 a dirty page bitmap (a set of bits representing the clean / dirty state of each page in 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 pair of segment offsets, lengths, corresponding to an identified contiguous dirty span in VM memory 509 (i.e., two adjacent dirty pages incorporated into the region defined by the elements of the array).

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

[0084] In the illustrated embodiments, the active host 502 also includes guest prior memory 514, which stores the state of VM memory 509 prior to the current epoch. The IMC 520 also includes guest prior memory buffer 524, which stores the state of VM memory 509 prior to the current epoch. In some embodiments, if the IMC 520 is dedicated to the active VM 511, the IMC 520 maintains the guest prior memory buffer 524 between synchronization processes (i.e., during an epoch). In some such embodiments, after the processor 530 has completed the dirty span encoding process in the guest's current memory buffer 522, the processor 530 copies the contents of the guest's current memory buffer 522 to the guest's prior memory buffer 524 in preparation for the next epoch.

[0085] In some embodiments, the IMC520 manages synchronization for multiple VMs by being time-multiplexed to manage synchronization for two or more VMs having synchronization routine timings that are time-offset to each other, for example, enough time to complete the synchronization process for one VM before the synchronization process for the next VM begins. In such embodiments, immediately before or after the dirty span of the VM memory 509 is transferred to the guest's current memory buffer 522 of the IMC520 via a DMA transaction, the guest's previous memory 514 is sent to the guest's previous memory buffer 524 via a DMA transaction.

[0086] In some embodiments, the synchronization procedure includes the processor 530 performing multithreaded parallel encoding of dirty pages received from the active host 502. Data in the guest's current memory buffer 522 and the guest's previous memory buffer 524 are all packed so that they occupy a contiguous span of memory addresses in their respective buffers. The packed data is logically partitioned into “chunks” that can be encoded by separate threads. In some embodiments, a chunk information buffer 526 stores information about each chunk, such as pairs of segment offsets and lengths corresponding to each chunk. The size of the chunks must be sufficient to provide the granularity required 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 an encoding delta buffer 528 before transmission. The number of worker threads N can vary significantly across different target devices, and is limited by the number of simultaneous memory accesses the device can support, typically ranging from 8 to 16 in a typical FPGA. In such cases, many more logical threads can be implemented by using subthreads (subkernels) to pipeline memory access within threads.

[0087] The process for performing XOR-RLE coding 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, the typical chunk size is 128 pages (512 KiB), but other chunk sizes can be used without departing from this disclosure. Once chunks are encoded, they are typically shorter in length than the original chunk size. Chunk location and length information is copied to the chunk information buffer 526. In some embodiments, the chunks encoded by XOR+RLE are structured as shown in Table 1. Table 1 [Table 1] Here

number

[0089] If the chunk compressed by XOR+RLE is larger than the original chunk size, for example due to many entropy corrections, the original content of the chunk (in the guest's current memory buffer 522) is copied to the pre-transmission encoded delta buffer 528, where the chunk is structured as shown in Table 2. Table 2 [Table 2] In some embodiments, Tables 1 and 2 include encoding types to distinguish between XOR+RLE and plain data. In some embodiments, if there are only two encoding types, one bit is required in a binary scheme.

[0090] Once the chunks are processed, the contents of the pre-transmission encoded delta buffer 528 can be transferred back to the encoded 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 that the compressed chunks are efficiently copied back to the active host 502 in a packed form suitable for transmission to the standby host. The encoded delta result buffer 518 also contains the original segment list 516, which 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 unsuspended and execution resumes, which represents a transition to a new epoch.

[0092] Referring to Figure 6, this figure shows a block diagram of an exemplary VM environment 600 according to an exemplary embodiment. The exemplary embodiment is similar to VM environment 400 in Figure 4, except that in VM environment 600, the IMC616A includes a NIC618A that enables the IMC616A to communicate with the standby host 606 over network 604. In VM environment 400, the IMC416A sends synchronization data to the active host 402, which then sends it to the standby host 406. In VM environment 600, the IMC616A sends synchronization data (memory snapshots) to the standby host 606 using the NIC618A, and does not need to send it to the active host 602 first. The description of the active host 402 in Figure 4 applies equally to the active host 602, and the description of the standby host 406 in Figure 4 applies equally to the standby host 606. In some embodiments, the standby host 606 also uses an optional IMC616B, which includes a NIC618B for receiving and decoding synchronization data from the IMC616A.

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

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

[0095] In some embodiments, the synchronization procedure includes, once per epoch, the active host 802 suspending the running active VM and identifying pages of VM memory that were 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 state of each page in 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 pair of segment offsets, lengths, corresponding to an identified contiguous dirty span in VM memory (i.e., two adjacent dirty pages incorporated into the region defined by the elements of the array).

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

[0097] In the illustrated embodiment, non-contiguous spans A', B', C', and D' are copied via DMA transactions to a set of contiguous memory addresses in the guest's current memory buffer 812 of the IMC804. Also in the illustrated embodiment, non-contiguous spans A, B, C, and D are copied via DMA transactions to a set of contiguous memory addresses in the guest's previous memory buffer 814 of the IMC804. Packing the data in the guest's current memory buffer 812 and the guest's previous memory buffer 814 makes it possible to align the data into dense data computations well-suited for processing by hardware accelerators such as GPUs or FPGAs. Furthermore, this allows the compressed workload to be divided into chunks of packed data to support data parallel processing. The output segment buffer can then be used to collect the encoded (compressed) data into contiguous memory and send it to the standby VM.

[0098] Referring to Figure 9, this figure shows 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 figures of the active host 902 and IMC 904 are simplified to clearly illustrate one embodiment of a multithreaded XOR-RLE process according to the exemplary embodiment. In some embodiments, the active host 902 is an example of the active host 402 in Figure 4, the active host 502 in Figure 5, the active host 602 in Figure 6, or the active host 702 in Figure 7. In some embodiments, the IMC 904 is an example of the IMC 306 in Figure 3, the IMC 416A in Figure 4, the IMC 520 in Figure 5, the IMC 616A in Figure 6, or the IMC 720 in Figure 7.

[0099] In some embodiments, the synchronization procedure includes a hardware accelerator performing multithreaded, parallelized encoding 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 a contiguous span 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 granularity required 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 simplification. Actual implementations may include hundreds or thousands of threads.

[0100] In some embodiments, separate threads perform XOR and RLE encoding within the compression module 910 on one or more chunks, generating results dA, dA,dB, dC, and dD for each chunk level 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 result, the chunk information buffer is first copied back to the active host 902. This chunk information {chunk offset, chunk length} is used to ensure that the compressed chunks are efficiently copied back to the active host 902 in a packed form suitable for transmission to the standby host. The XOR-RLE result buffer 906 also contains a list of original segments that map 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 unsuspends the active VM and resumes execution, which represents a transition to a new epoch.

[0102] Referring to Figure 10, this figure shows a block diagram of a VM environment 1000 according to an exemplary embodiment. The exemplary embodiment includes a standby host 1002. The figure of the standby host 1002 is simplified to clearly illustrate one embodiment of the multithreaded XOR-RLE decoding process according to the exemplary embodiment. In some embodiments, the standby host 1002 is an example of the standby host 406 in Figure 4 or the standby host 606 in Figure 6.

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

[0104] Referring to Figure 11, this figure shows a flowchart of an example process 1100 for encoding processing according to an exemplary embodiment. In a particular embodiment, IMC306, IMC416A, IMC520, IMC616A, IMC720, IMC804, or IMC904 perform process 1100.

[0105] In one embodiment, in block 1102, the synchronization process includes, once per epoch, the active host suspending the running active VM and identifying pages of VM memory that were 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 set of bits representing the clean / dirty state of each page in guest VM memory). Next, in 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 pair of segment offsets, lengths, corresponding to an identified contiguous dirty span in VM memory (i.e., two adjacent dirty pages incorporated into the region defined by the elements of the array).

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

[0107] In blocks 1110 and 1112, the synchronization process includes a processor, preferably a hardware accelerator such as a GPU or FPGA, performing multithreaded parallel encoding of dirty pages received from the active host. All data in the guest's current memory buffer and the guest's previous memory buffer is packed so that it occupies a contiguous span of memory addresses in each buffer. 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 pairs of segment offsets and lengths corresponding to each chunk. The size of the chunks must be sufficient to provide the granularity required 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 encoded delta buffer before transmission. The number of worker threads N can vary significantly across different target devices, and is limited by the number of simultaneous memory accesses the device can support, typically ranging from 8 to 16 in a typical FPGA. In such cases, many more logical threads can be implemented by using subthreads (subkernels) to pipeline memory access within threads.

[0108] Next, in blocks 1114 and (optionally, 1116 if the IMC does not have a NIC), the synchronization process proceeds based on a comparison of the size of the chunk compressed by XOR+RLE with the original chunk size. For example, if the compressed version is larger due to many entropy corrections, in block 1114, the original content of the chunk (in the guest's current memory buffer) is copied to the pre-transmission coded delta buffer. Otherwise, in block 1116, the compressed version is copied to the pre-transmission coded delta buffer. This comparison is performed individually for each chunk until all of them have been processed and stored in the pre-transmission coded delta buffer.

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

[0110] Referring to Figure 12, this figure shows a flowchart of process 1200, an example of a decoding process according to an exemplary embodiment. In a particular embodiment, standby host 406, standby host 606, or standby host 1002 performs process 1100.

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

[0112] In block 1206, if the segment is plain data, the plain data value is extracted from the segment in block 1208. Next, in block 1210, the data is copied to the memory area derived from the analysis of the original segment list. This iterative process continues until all the synchronous data has been processed and incorporated into the standby VM's memory.

[0113] The following definitions and abbreviations are for use in interpreting the claims and specification. Where used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or any other variation thereof, are intended to encompass non-exclusive inclusion. For example, a component, mixture, process, method, article, or apparatus containing a list of elements is not necessarily limited to those elements alone, but may include other elements not expressly listed, or other elements specific to such component, mixture, process, method, article, or apparatus.

[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” should not necessarily be construed as being preferable or advantageous to 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 “multiple” is understood to include any integer greater than or equal to 2, i.e., 2, 3, 4, 5, etc. The term “connection” may include indirect “connection” and direct “connection.”

[0115] References in the specification such as “one embodiment,” “an embodiment,” and “an exemplary embodiment” indicate that the embodiments described may include certain features, structures, or characteristics, but all embodiments may or may not include certain features, structures, or characteristics. Furthermore, such language does not necessarily refer to the same embodiment. Moreover, if certain features, structures, or characteristics are described in relation to one embodiment, it is considered within the knowledge of a person skilled in the art that such features, structures, or characteristics will be affected in relation to other embodiments, whether or not they are explicitly described.

[0116] The terms “about,” “substantially,” “approximately,” and their variations are intended to include the degree of error associated with an indicator of a particular quantity, based on the apparatus available at the time of filing this application. For example, “about” may include a range of ±8%, 5%, or 2% of a given value.

[0117] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or to limit oneself 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 describe the principles of the embodiments, their practical application to the technology found in the market, or technical improvements, or to enable other persons skilled in the art to understand the embodiments described herein.

[0118] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or to limit oneself 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 describe the principles, practical applications, or technical improvements to the technologies available on the market, or to enable those else skilled in the art to understand the embodiments described herein.

[0119] Therefore, computer implementations, systems, or devices 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 part thereof is described in relation to a type of device, the computer implementation, system, or device, computer program product, or part thereof is adapted or configured for use with a preferred and equivalent embodiment of that type of device.

[0120] When an embodiment is described as an implementation 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 capability of an application implementing an embodiment is provided to the user by running the application on a cloud infrastructure. The user may access the application using various 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 further not manage or control the capabilities of the SaaS application. In some other cases, the SaaS implementation of an application may allow for possible exceptions of limited user-specific application configuration settings.

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

[0122] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, but is not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any preferred 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 disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures having instructions recorded thereon, and any preferred combination of those described above. When used herein, computer-readable storage media should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0123] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to each computing / processing device, or to an external computer or external 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 may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in computer-readable storage media within each computing / processing device.

[0124] The computer-readable program instructions for performing the operations of the present invention may be 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 code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may run as a standalone software package, either entirely on the user's computer, 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 wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may be personalized by executing computer-readable program instructions using state information of computer-readable program instructions in order to carry out aspects of the present invention.

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

[0126] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a dedicated computer, or other programmable data processing device to generate a machine, thereby creating means for instructions executed via the processor of the computer or other programmable data processing device to implement functions / operations specified in one or more blocks of a flowchart or block diagram or both. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a particular manner, thereby having a manufactured article in which the computer-readable storage medium in which the instructions are stored contains instructions that implement modes of functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0127] Computer-readable program instructions may also be loaded into a computer, another programmable data processing device, or other device, and a series of operational steps may be performed on the computer, the other programmable device, or the other device to generate a computer implementation process, which in turn may be executed on the computer, the other programmable device, or the other device to implement the function / operation specified in the block(s) of a flowchart or block diagram or both.

[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 the flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may be performed in an order different from that shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart diagram, and combinations of blocks in the block diagram and / or flowchart diagram, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0129] Embodiments of the present invention may also be delivered as part of a service engagement with a client company, non-profit organization, government agency, internal organizational structure, or similar entity. Aspects of these embodiments may include configuring a computer system for implementation 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, creating recommendations in response to the analysis, building a system that implements some of the recommendations, integrating the system into existing processes and infrastructure, quantifying system usage, allocating expenditures to system users, and billing for system usage. While each of the above embodiments of the present invention has been described by stating their respective individual advantages, the present invention is not limited to any particular combination thereof. Conversely, such embodiments may also be combined in any way and number according to the intended development of the present invention without losing their beneficial effects.

Claims

1. The Intelligent Memory Controller (IMC) writes the current snapshot data to a first set of consecutive memory addresses, where the current snapshot data is received by the IMC from the memory of the active virtual machine (VM) via a first direct memory access (DMA) transfer operation; The IMC performs a step of executing concurrent threads associated with each span of the contiguous memory addresses, wherein the concurrent threads control the compression process of each portion of the current snapshot data to obtain the corresponding portion of the processed current snapshot data, and the concurrent threads have a first thread bound to a hardware accelerator to perform the compression process of a first portion of the current snapshot data; and The processed current snapshot data is sent to the standby VM as the current synchronized snapshot of the active VM. A computer implementation method comprising the above.

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

3. The computer implementation method according to claim 1, wherein the current snapshot data includes memory pages designated as having been modified since a previous synchronous snapshot of the active VM, and the previous synchronous snapshot is represented as previous snapshot data.

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

5. The compression process of the first portion of the current snapshot data is performed as follows: The process includes a step in which the hardware accelerator performs an exclusive OR operation between the raw data version of the first portion of the current snapshot data and the corresponding raw data version of the first portion of the previous snapshot data, Here, the exclusive OR operation yields a delta-encoded version of the first portion of the current snapshot data, The computer implementation method according to claim 3, wherein the delta-coded version represents a memory change in the first portion of the current snapshot compared with the corresponding first portion of the previous snapshot data.

6. The compression process of the first portion of the current snapshot data is performed as follows: The hardware accelerator performs a Runtime Length Encoding (RLE) operation on the delta-encoded version of the first portion of the current snapshot data, The computer implementation method according to claim 5, wherein the RLE calculation yields an RLE-encoded version of the first portion of the current snapshot data.

7. The compression process of the first portion of the current snapshot data is performed as follows: A step of 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 implementation method according to claim 6, including the method described in claim 6.

8. The IMC replaces the previous snapshot data with the current snapshot data so that the current snapshot data is used as the previous snapshot data, and in the meantime, generates a subsequent synchronous snapshot of the active VM. The computer implementation method according to claim 7, further comprising:

9. The computer implementation method according to claim 1, wherein the hardware accelerator includes a graphics processing unit (GPU).

10. The computer implementation method according to claim 1, wherein the hardware accelerator includes a field-programmable gate array (FPGA).

11. A program for causing an intelligent memory controller to execute the computer implementation method described in Claim 1.

12. A storage medium storing the program described in Claim 11.

13. A system comprising a storage medium storing a program for causing an intelligent memory controller to execute the computer implementation method described in Claim 1, and the intelligent memory controller.

Images