Tracing data in complex replicated systems

Abstract

Example operations may include one or more of receiving a message from an agent installed at a data replication server, the message including a checksum validation status identifier for a data replication operation, identifying a latency value associated with the data replication server, determining whether data loss has occurred based on the checksum validation status identifier and the latency value; and, in response to determining that data loss has occurred, sending a notification of the data loss to a computing system associated with the data replication server.

Description

[Background technology]

[0001] In a complex replication environment, multiple replication sites (nodes) may be connected to each other in a distributed network topology. Within the network, each replication site may include a replication server (e.g., a canonical log server, etc.) that executes a workflow and replicates the workflow to one or more other sites in the network. For example, data stored on one server may be replicated (transferred) to other servers in the distributed network as part of a remote backup storage operation, etc. In many cases, data may be transferred using SQL replication or the like.

[0002] In some cases, data may be lost during replication operations. For example, a small number of rows of data in a table may be missing when the table reaches its destination during a replication operation. Missing data can be very difficult to detect, especially in complex environments where servers must be continuously available in real time. Furthermore, no error is typically reported when data is lost. Therefore, a better mechanism is needed to track data during data replication operations and to notify when data is lost. Summary of the Invention

[0003] One exemplary embodiment provides an apparatus comprising: a network interface configured to receive a message from an agent installed at a data replication server, where the message may include a checksum validation status identifier of a data replication operation; and a processor configured to do one or more of: identify a latency value associated with the data replication server; determine whether data loss has occurred based on the checksum validation status identifier and the latency value; and, in response to determining that data loss has occurred, send a notification of the data loss to a computing system associated with the data replication server via the network interface.

[0004] Another exemplary embodiment provides a method comprising one or more of the following steps: receiving a message from an agent installed at a data replication server, the message including a checksum validation status identifier for a data replication operation; identifying a latency value associated with the data replication server; determining whether data loss has occurred based on the checksum validation status identifier and the latency value; and, in response to determining that data loss has occurred, sending a notification of the data loss to a computing system associated with the data replication server.

[0005] A further exemplary embodiment provides a computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of the following steps: receiving a message from an agent installed at a data replication server, the message including a checksum validation status identifier for a data replication operation; identifying a latency value associated with the data replication server; determining whether data loss has occurred based on the checksum validation status identifier and the latency value; and, in response to determining that data loss has occurred, sending a notification of the data loss to a computing system associated with the data replication server. [Brief explanation of the drawings]

[0006] The patent or application file contains at least one drawing executed in color. Copies of this patent or patent application publication with color drawing(s) will be provided by the U.S. Patent and Trademark Office upon request and payment of the necessary fee.

[0007] [Figure 1] FIG. 1 illustrates a cloud computing environment interacting with various devices according to an example embodiment.

[0008] [Figure 2A] FIG. 1 illustrates abstraction model layers of a cloud computing environment, according to an example embodiment.

[0009] [Figure 2B] FIG. 1 illustrates a system for identifying data loss in a complex replication system, according to an example embodiment.

[0010] [Figure 3A] FIG. 1 illustrates an example of a permissioned network, according to an example embodiment. [Figure 3B] FIG. 1 illustrates an example of a permissioned network, according to an example embodiment. [Figure 3C] FIG. 1 illustrates an example of a permissioned network, according to an example embodiment.

[0011] [Figure 3D] FIG. 1 illustrates a machine learning process via a cloud computing platform, according to an example embodiment.

[0012] [Figure 3E] FIG. 1 illustrates a quantum computing environment associated with a cloud computing platform, according to an example embodiment.

[0013] [Figure 4A] FIG. 1 illustrates a process for sending replication messages between data replication sites according to an example embodiment.

[0014] [Figure 4B] FIG. 1 illustrates a process for verifying the status of a data replication operation based on checksum validation, according to an example embodiment.

[0015] [Figure 4C] FIG. 1 illustrates a process for determining whether data loss has occurred, according to an example embodiment.

[0016] [Figure 4D] FIG. 1 illustrates a process for training a latency model, according to an example embodiment.

[0017] [Figure 5] FIG. 1 illustrates a method for determining whether data loss has occurred, according to an example embodiment.

[0018] [Figure 6] FIG. 1 illustrates an example of a computing system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0019] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is 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.

[0020] Currently, no product exists that can adequately monitor a data replication system and detect data loss in replication operations in an efficient manner. Instead, the traditional strategy is to add diagnostic code to one or more components, rebuild the product, shut down the program, and redeploy the product to the customer's production system. The diagnostic code can provide detailed information that can be analyzed for data loss. Some of the drawbacks of this process include bringing down the server (and potentially causing an outage for the customer or multiple customers). In addition, code changes can cause unintended changes to the product's operation and maintenance. Furthermore, some problems (e.g., random problems) are unpredictable, so they may not be easy to reproduce. Similarly, the computing resources required to debug the code are unpredictable, which can result in additional problems for the host.

[0021] An illustrative embodiment is directed to a tracking system for monitoring and tracking data loss within a complex data replication network. The network may include a distributed network of replication sites. Each replication site may include one or more servers with replication software installed therein. The replication software may be configured to receive and forward data to other servers in the network and synchronize the servers. For example, a source server may wish to back up a copy of its data, applications, etc. The source server may then select a destination server for storing the backup. The destination server may be multiple hops (sites) away from the source server. The replication network may internally form a server / site path for transferring data to be backed up from the source server to the destination server. Additionally, the replication software may ensure and verify that a synchronized copy of the data from the source server is stored at the destination server.

[0022] The tracking system may include agents installed at each server (site) and a central coordinator configured to exchange messages with these agents and determine whether data was lost during a replication operation. As an example, an agent may be a device, key, box, etc. that physically plugs into a server (e.g., via USB, LAN cable, etc.). As another example, an agent may be a software program installed within a server without requiring a physical device to be plugged in. A pluggable device may be beneficial because it is easy to maintain and a user can simply unplug it when no longer needed instead of uninstalling it. Also, because the hardware is contained internally, it is easy to plan dedicated resources (e.g., processor, memory, etc.) for the agent.

[0023] The coordinator may be installed or otherwise operate on a host platform such as a cloud platform, an on-premise server, or the like. The coordinator may be referred to herein as an advisory system or broker. The coordinator communicates with the agents using status check messages, which provide the coordinator with insight into the data replication process. For example, a source site may transfer / backup data to a target site (destination site) through one or more intermediate sites. In this example, the source site may create a checksum or checksums based on the data being transferred (e.g., a checksum of one or more replication transactions in the data being transferred) and add the checksums to a data replication message containing the data being transferred. An intermediate server may receive the data replication message, validate the checksums, and report the validation results to the coordinator. In response, the coordinator may determine whether data loss has occurred and whether additional action should be taken. The coordinator may also request retransmission of transaction content between servers, if necessary.

[0024] Messages exchanged between agents and the coordinator include a status indicator (checksum status indicator) that provides the result of the checksum validation process performed by the agent. For example, the message may include an identifier indicating that the checksum validation resulted in a match (success) or that the checksum validation did not result in a match (suspicious). The message may include an identifier of the agent that sent the message, one or more transaction identifiers of one or more transactions used to create the one or more checksums, respectively, and the validation status of the one or more checksums. Exchanged messages may also include control messages used for management or maintenance purposes, such as heartbeat messages, revalidation requests, and the like.

[0025] According to various embodiments, messages exchanged between agents themselves and between agents and the coordinator differ from messages exchanged by replication servers because they include checksum validation and an identifier for the transaction used to create the checksum. Messages between replication servers, on the other hand, typically include only application / user data without any validation data for data loss. Therefore, agents and coordinators can provide benefits over traditional data replication networks by incorporating data loss detection and real-time notification capabilities into the data replication network, which can reduce downtime, conserve resources, and ensure efficient operation of the data replication process.

[0026] 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 administrative effort or interaction with a service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0027] Examples of cloud computing characteristics that may be associated with example embodiments include:

[0028] 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 service provider.

[0029] 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).

[0030] 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 according to demand. There is location independence in that consumers generally have no control or knowledge over the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center).

[0031] Rapid Elasticity: Capacity can be rapidly and elastically provisioned, in some cases automatically, to rapidly scale out, and rapidly released to rapidly scale in. To the consumer, the capacity available for provisioning often appears unlimited, and can be purchased in any quantity at any point in time.

[0032] 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 usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of utilized services.

[0033] Examples of service models that may be associated with example embodiments include the following:

[0034] 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 a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0035] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a 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 application host environment configuration.

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

[0037] Examples of deployment models that may be associated with example embodiments include the following:

[0038] Private Cloud: This cloud infrastructure operates solely for an organization. It may be managed by that organization or a third party and may exist on-premise or off-premise.

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

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

[0041] Hybrid Cloud: This cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standard or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0042] Cloud computing environments are service-oriented with a 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.

[0043] Referring now to FIG. 1 , an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N, may communicate. The cloud computing nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private, community, public, or hybrid cloud, or combinations thereof, as described hereinabove. This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on their local computing device. It will be understood that the types of computing devices 54A-N shown in FIG. 1 are intended to be illustrative only, and that the cloud computing node 10 and cloud computing environment 50 may communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0044] Referring now to FIG. 2A , a set of functional abstraction layers provided by cloud computing environment 50 ( FIG. 1 ) is illustrated. It should be understood in advance that the components, layers, and functions illustrated in FIG. 2A are intended to be merely illustrative, and that embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided: Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62; servers 63; blade servers 64; storage devices 65; and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68. Virtualization layer 70 provides an abstraction layer over which the following examples of virtual entities can be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75. In one example, management layer 80 may provide the functionality described below.

[0045] Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute 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 of cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides advance arrangements and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

[0046] The workload tier 90 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 91; software development and lifecycle management 92; virtual classroom instruction delivery 93; data analytics processing 94; transaction processing 95; and replication data loss detection 96.

[0047] FIG. 2B illustrates an example process 200 corresponding to replication data loss detection 96 in FIG. 2A, according to an example embodiment. Process 200 may be performed by a system including multiple agents 212, 222, 232, and 242 installed at multiple sites 210, 220, 230, and 240 of a replication network, respectively. Here, each of sites 210-240 may include a replication instance 214, 224, 234, and 244, which handles replication processes, including the transfer of data between different sites 210-240. As one example, agents 212, 222, 232, and 242 may include software programs installed within a data server at the respective site. As another example, agents 212, 222, 232, and 242 may be hardware devices, such as a drive, box, or the like, that can be physically plugged into a data server. Each replication instance may include attributes of the replication operation, including multiple rows per commit, identifiers of data to be written, identifiers of data to be deleted, identifiers of data to be updated, and the like.

[0048] The system shown in FIG. 2B also includes a coordinator 250, which in this example is installed on a cloud platform. The cloud platform is located separately from sites 210, 220, 230, and 240, although this is not a requirement. It should be understood that coordinator 250 may be incorporated into an on-premises server, a data server at a replication site, and the like. Coordinator 250 includes a latency model 252. Latency model 252 may include one or more machine models trained to analyze the data server's replication history logs and determine a respective latency value for each of agents 212, 222, 232, and 242 installed at each of sites 210, 220, 230, and 240. The latency value represents a duration (e.g., 300 seconds, 1000 seconds, etc.) for each of the agents.

[0049] If data is missing from a transfer between two servers but the latency value for an agent installed at the sending server has not yet been exceeded, coordinator 250 may request that the sending server resend the missing data. As another example, coordinator 250 may request a retransmission even if the latency value for the respective agent is exceeded.

[0050] 3A-3E provide various examples of additional features that may be used in connection with the cloud computing environments described herein, which should be considered as further extensions or additional examples of the embodiments described herein.

[0051] FIG. 3A illustrates an example of a permissioned blockchain network 300 featuring a distributed, decentralized, peer-to-peer architecture. The blockchain network may interact with a cloud computing environment 50, enabling additional functionality such as peer-to-peer authentication for data written to the distributed ledger. In this example, a blockchain user 302 may initiate a transaction against the permissioned blockchain 304. In this example, a transaction may be a deployment, invocation, or query and may be issued directly through an API, or through a client-side application leveraging an SDK. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as “auditors” and blockchain users 302 as “clients.” Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query certain types of chaincode.

[0052] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy the chaincode directly to the network through an interface. To include credentials from a traditional data source 312 in the chaincode, the developer 310 can access the data using an out-of-band connection. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before proceeding with any transaction, the peer node 314 obtains the user's registration and transaction certificate from a certificate authority 316, which manages user roles and permissions. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 304. Meanwhile, a user attempting to utilize the chaincode may need to verify their credentials on the traditional data source 312. To confirm the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0053] 3B shows another example of a permissioned blockchain network 320 featuring a distributed, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, transactions may be deploy, invoke, or query and may be issued directly through an API, or through a client-side application leveraging an SDK. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as "auditors" and blockchain users 322 as "clients." Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query certain types of chaincode.

[0054] A blockchain developer 330 writes chaincode and client-side applications. The blockchain developer 330 can deploy the chaincode directly to the network through an interface. To include credentials from a traditional data source 332 in the chaincode, the developer 330 can access the data using an out-of-band connection. In this example, a blockchain user 322 connects to the network through a peer node 334. Before proceeding with any transaction, the peer node 334 obtains the user's registration and transaction certificate from a certificate authority 336. In some cases, a blockchain user must possess these digital certificates to transact on the permissioned blockchain 324. Meanwhile, a user attempting to utilize the chaincode may need to verify their credentials on the traditional data source 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0055] In some embodiments, a blockchain herein may be a permissioned blockchain. Anyone can participate in a permissioned blockchain, as opposed to a permissioned blockchain, which requires permission to participate. For example, to participate in a permissioned blockchain, a user may begin interacting with the network by creating a personal address and submitting transactions, thus adding entries to the ledger. Additionally, all parties have the option to run a node on the system and utilize a mining protocol that helps verify transactions.

[0056] 3C illustrates a transaction process 350 processed by an open-ended blockchain 352 including multiple nodes 354. A sender 356 wishes to send a payment or some other form of value (e.g., a certificate, medical records, a contract, goods, services, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the open-ended blockchain 352. In one embodiment, the sender device 356 and the recipient device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and a display of transaction parameters. In response, the transaction is broadcast throughout the blockchain 352 to the nodes 354. Depending on the network parameters of the blockchain 352, the nodes validate 360 ​​the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the open-ended blockchain 352. For example, this may include verifying the identities of the parties involved, etc. The transaction may be verified immediately or may be queued with other transactions, and node 354 determines whether the transaction is valid based on a set of network rules.

[0057] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process may be performed by mining nodes among nodes 354. Mining nodes may utilize additional software specifically for mining and creating blocks for the open-ended blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with creating a secure and independent chain of blocks.

[0058] Before a block can be added to the blockchain, it must be validated. Validation of a permissionless blockchain 352 may involve proof-of-work (PoW), which is a solution to a puzzle derived from the block's header. Another process for validating a block, not shown in the example of FIG. 3C, is proof-of-stake. Unlike proof-of-work, where an algorithm rewards miners for solving a mathematical problem, in proof-of-stake, the creator of a new block is chosen in a deterministic manner depending on their wealth, also defined as "stake." Similar proofs are then performed by selected / elected nodes.

[0059] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates a proof of work, which guarantees a correct solution. In other words, potential solutions must prove that they have exhausted the computing resources required to solve the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0060] Here, the PoW process chains blocks together, making it extremely difficult for an attacker to modify the blockchain by requiring an attacker to modify all subsequent blocks in order for a modification to one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying the block increases, and the number of subsequent blocks increases. In distribution, successfully validated blocks are distributed throughout the open-source blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the open-source blockchain 352. Furthermore, the value of a transaction submitted by a sender 356 is deposited or otherwise transferred to a digital wallet on a recipient device 358.

[0061] 3D and 3E show additional examples of cloud computing use cases that may be incorporated and used herein. FIG. 3D shows an example 370 of a cloud computing environment 50 that stores machine learning (artificial intelligence) data. Machine learning relies on vast amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to discover non-intuitive patterns.

[0062] 3D , the host platform 376 builds and deploys machine learning models for predictive monitoring of the assets 378. Here, the host platform 366 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, and the like. The assets 378 may be any type of asset (e.g., machinery or equipment, etc.), such as an aircraft, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a boat, a watercraft, a vehicle, and the like. As another example, the assets 378 may be non-tangible assets, such as stocks, currency, digital coins, insurance, or the like.

[0063] The cloud computing environment 50 can be used to significantly improve both the machine learning model training process 372 and the prediction process 374 based on the trained machine learning model. For example, at 372, rather than requiring a data scientist / engineer or another user to collect the data, historical data may be stored on the cloud computing environment 50 by the asset 378 itself (or through an intermediary, not shown). This can significantly reduce the collection time required by the host platform 376 when performing predictive model training. For example, data can be transferred directly and reliably from its origination location to the cloud computing environment 50. By using the cloud computing environment 50 to ensure the security and ownership of the collected data, a smart contract can send the data directly from the asset to the individual who will use the data to build the machine learning model. This enables data to be shared among assets 378.

[0064] Further, training the machine learning model on the collected data may take rounds of refinement and testing by the host platform 376. Each round may be based on additional data or data not previously considered to be useful in expanding the machine learning model's knowledge. At 372, the different training and testing stages (and their associated data) may be stored by the host platform 376 on the cloud computing environment 50. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored on the cloud computing environment 50 to provide verifiable evidence of how the model was trained and what data was used to train the model. For example, the machine learning model may be stored on a blockchain to provide verifiable evidence. Further, once the host platform 376 has achieved a trained model, the resulting model may be stored on the cloud computing environment 50.

[0065] After the model is trained, it may be deployed to a production environment where it can make predictions / decisions based on the execution of the final trained machine learning model. For example, at 374, the machine learning model may be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, medical machinery, and the like. In this example, data fed back from the asset 378 may be input into the machine learning model and used to make event predictions such as failure events, error codes, and the like. Decisions made by the execution of the machine learning model on the host platform 376 may be stored on the cloud computing environment 50 to provide auditable / verifiable evidence. As one non-limiting example, the machine learning model may predict a future breakdown / failure for a portion of the asset 378 and create an alert or notification to replace the portion. The data behind this decision may be stored by the host platform 376 and / or on the cloud computing environment 50. In one embodiment, the features and / or actions described and / or illustrated herein may occur on or for the cloud computing environment 50.

[0066] 3E shows an example 380 of a quantum secure cloud computing environment 382 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, cloud computing users can verify each other's identities using QKD, which transmits information using quantum particles, such as photons, that an eavesdropper cannot copy without corrupting it. In this way, senders and recipients via the cloud computing environment can confirm each other's identities.

[0067] In the example of Figure 3E, there are four users 384, 386, 388, and 390. Each pair of users may share a secret key 392 (i.e., QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD Six different secret keys 392 are used, including the PIN and the PIN. Each pair can create QKD by transmitting information using quantum particles, such as photons, that cannot be copied by an eavesdropper without being corrupted. In this way, pairs of users can verify each other's identities.

[0068] The operation of the cloud computing environment 382 is based on two steps: (i) transaction creation and (ii) the construction of blocks that aggregate new transactions. New transactions may be created similarly to traditional networks, such as blockchain networks. Each transaction may include information about the sender, recipient, time of creation, the amount (or value) being transferred, a list of reference transactions that justify the sender having funds for the operation, and the like. This transaction record is then transmitted to all other nodes, where it is placed in a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 384-390) authenticate the transaction by providing their shared secret key 392 (QKD). This quantum signature may be attached to every transaction, making it extremely difficult to tamper with. Each node checks its entry against its local copy in the cloud computing environment 382 to verify that each transaction has sufficient funds.

[0069] 4A-4D illustrate a data error detection process within a data replication system, such as a distributed data replication system. In this example, a source site (e.g., a source server, etc.) is attempting to transfer / synchronize its content to a backup copy of the source server at a target location (e.g., a target server, etc.). Both the source and target may include agents installed therein according to various embodiments. Additionally, intermediate servers along the transmission path between the source server and the target server may include agents as well. Each of the agents may communicate with a coordinator hosted by a cloud platform, one of the sites, or the like.

[0070] FIG. 4A illustrates a process 400 for sending replication messages between data replication sites, according to an example embodiment. Referring to FIG. 4A, a source site 410 is backing up data to a destination site (not shown). The transmission path for the transfer of data from the source site 410 to the destination site includes an intermediate site 420, which may include multiple intermediate sites (not shown). In this example, the source site includes an agent 412 according to various embodiments and a replication instance 414 that prepares a workload for replication. The workload may include operations to be performed, such as adding new data values, modifying existing data values, deleting existing data values, and the like. Here, the replication instance 414 may generate a replication message 402 having replication data 404 for transfer to the destination site.

[0071] In this example, agent 412 (e.g., plugged into or otherwise installed on a server at source site 410) may generate and inject one or more checksums into replication message 402. For example, agent 412 may generate a checksum (e.g., a hash value, etc.) for a first transaction (e.g., transaction A) and add it to a transaction message for a second transaction (e.g., transaction B) and a transaction message for a third transaction (e.g., transaction C). The combination of transaction A's checksum, transaction message B with checksum A added, and transaction message C with checksum A added may be sent to the next agent / server (i.e., agent 422 at intermediate site 420). The replication operation may include tens or even hundreds of transactions (e.g., database transactions, etc.) to be performed to synchronize the target site with source site 410. Here, agent 412 may randomly select transactions and then generate checksums for the randomly selected transactions. As another example, agent 412 may select predefined transactions and use them for checksum. Replication message 402 is then forwarded to intermediate site 420, which also includes an agent 422 installed therein. Agent 422 installed at the next server may generate a checksum for transaction A and compare it with the checksum value of A stored in transaction message B or transaction message C. Which transaction message is selected can be random; the coordinator may request the corresponding agent to perform checksum reevaluation before / after reaching a latency threshold, which can reduce false alarms caused by latency.The coordinator does not have to ask the replication server to resend the data replication message, instead it will notify the user to take action on the data loss.

[0072] That is, agents may be plugged into the source server, the target destination server, and the intermediate servers. The agent at the source server may inject additional checksum values ​​into the replicated transaction data messages. Additionally, the agent at the intermediate server may validate the checksums and send a suspicious message to the coordinator (Figure 4C) if there is a mismatch. An agent may also be installed on the target destination server, performing the same role as the agent plugged into the intermediate server.

[0073] Referring again to the example in FIG. 4A, an agent 412 installed at the source site 410 (source server) may collect replicated transaction messages before they are sent by the replication instance 414 and add a checksum value to the message before it is sent. The implementation of the replicated transaction message may differ for different replication product providers. As an example, the message may be in XML format. In this case, the checksum may be stored anywhere in the XML format with the correct schema. In other words, it may be present anywhere in the message as long as the message can be correctly interpreted by subsequent servers and existing replication servers.

[0074] 4B illustrates a process 440 for verifying the status of a data replication operation based on checksum validation, according to an example embodiment. Referring to FIG. 4B, a replication message 402 is received by an intermediate site 420. In response, a replication instance 424 may forward the replication message 402 to an agent 422 installed locally on the intermediate site 420 (a server). Based on the transaction ID in the data replication message 402, the agent 422 may identify which transactions in the replicated transaction data 404 were used to create the checksum values ​​406 and 408, and recreate the checksum values ​​based on the replicated transaction data 404.

[0075] Agent 422 may then compare the recreated checksum value with checksum values ​​406 and 408 in replication message 402 to determine if they match. If they match, agent 422 determines that there was no data loss. If they do not match, it is possible that data may have been lost. The result of the determination may be sent from agent 422 to coordinator 430 hosted on a central platform. Agent 422 may then designate that the checksums match (success) or that the checksums do not match (suspect).

[0076] FIG. 4C illustrates a process 450 for determining whether data loss has occurred, according to an example embodiment. Process 450 may be performed by the coordinator 430 illustrated in FIG. 4B. Referring to FIG. 4C, at 451, the coordinator may receive a checksum validation message from an agent (e.g., agent 422 in FIG. 4B). The checksum validation message may include an agent identifier (e.g., agent ID, etc.) that is unique to an agent in the network of agents. The validation message may include a checksum validation status identifier (e.g., pass / fail, etc.). Additionally, the validation message may include an identifier of the transaction used to generate the checksum.

[0077] At 452, the coordinator may add an entry to a tracking table (such as tracking table 470 shown in FIG. 4D). Each agent validation may have its own entry in tracking table 470. For example, if a replication message passes through three intermediate sites (and agents installed therein), the coordinator 430 will receive three validations of the replication data contained in the replication message from the three agents. Each validation message and its internal attributes may be added to an entry in tracking table 470. At 453, the coordinator may determine whether the message received at 451 indicates successful validation (i.e., the checksum created by the agent matches the checksum in the message) or unsuccessful validation (i.e., the checksums do not match). If the checksum validation is successful, at 454 the coordinator may send a compliance notification to one or more administrators of the replication operation.

[0078] However, if the checksum validation is not successful, then at 455 the coordinator may determine whether a latency value has been exceeded. The latency value may be a range of time that can ensure that the failed validation is not due to a false alarm (i.e., network latency). Here, the coordinator may identify how much time has passed since the replicated message was sent based on the timestamp of the replicated message. The coordinator may compare the amount of time with the range of time in the latency value. If the amount of time is within the range of time created by the latency value, the coordinator may send a request to the source site 410 to resend to the intermediate site 420 one or more transactions that were not properly received.

[0079] Referring again to FIG. 4D , the latency value may be a range of time (e.g., 300 seconds, 1000 seconds, etc.) that represents an acceptable amount of latency. The latency value may be determined by a machine learning model 462 shown in FIG. 4D . The machine learning model 462 may receive as input the tracking table 470 and analyze the history of replication operations / communications performed by the source site 410 to determine a latency value 464 of the latency possible at the source site 410. The latency value 464 may be used by the coordinator in determining whether data loss exists, at 456. For example, if the latency value is not exceeded, the coordinator may determine, at 456, to request a retransmission because it is possible that the data did not arrive (and will eventually arrive) due to latency. Further, at 457, the coordinator may send a request for retransmission to the source site. However, if the latency value is exceeded, the coordinator may detect data loss at 456, and the coordinator may send a notification at 458 to a computing system associated with the data replication, such as an administrator or the like. The coordinator may instruct the source site 410 to resend the missing data.

[0080] 5 illustrates a method 500 for simulating a workflow based on a simulated workflow environment, according to an example embodiment. For example, method 500 may be performed by a computer system, such as a cloud platform, a web server, a personal computer or other user device, and the like. Referring to FIG. 5, at 510, the method may include receiving a message from an agent installed at a data replication server, where the message may include a status identifier of a checksum validation of the data replication operation.

[0081] At 520, the method may include identifying a latency value associated with the data replication server. For example, the latency value may be determined by analyzing a log / summary of historical messages from an agent installed on the data replication server. Here, the host may detect an amount of latency that is acceptable (non-error) in a particular situation under certain conditions and use this latency value to determine whether checksum validation may be incomplete because not all data has yet arrived. At 530, the method may include determining whether data loss has occurred based on the checksum validation status identifier and the latency value. At 540, in response to determining that data loss has occurred, the method may include sending a notification of the data loss to a computing system associated with the data replication server.

[0082] In some embodiments, the message may further include an agent identifier of an agent installed on the data replication server and an identifier of a transaction within the data replication operation. In some embodiments, the method may further include receiving a plurality of messages from an agent installed on the data replication server during the data replication operation, and generating a tracing table having identifiers of a plurality of transactions included in the data replication operation and checksum validation status identifiers for the plurality of transactions, each included in the plurality of messages. In some embodiments, the method may further include running a machine learning model on the generated tracing table to predict a latency value. In some embodiments, the method may further include receiving a request for a status of the data replication operation, and displaying content from the tracing table via a user interface in response to the request.

[0083] In some embodiments, the method may further include determining to request revalidation of transactions included in the data replication operation based on a number of occurrences of requests for revalidation that have already been performed. In some embodiments, the method may further include receiving checksum validation status identifiers for the data replication operation from multiple agents installed on multiple data replication servers included in the data replication operation, respectively. In some embodiments, the method may further include identifying transactions that were not successfully received based on the determination and sending a control signal to the source data replication server to retransmit the transactions.

[0084] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0085] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components. For example, FIG. 6 illustrates an exemplary computer system architecture 600 that may represent or integrate with components such as those described above.

[0086] 6 illustrates an example system 600 that supports one or more of the example embodiments described and / or illustrated herein. System 600 includes a computer system / server 602 that is operable with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 602 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0087] Computer system / server 602 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 602 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0088] 6, a computer system / server 602 within a cloud computing node 600 is shown in the form of a general-purpose computing device. Components of the computer system / server 602 may include, but are not limited to, one or more processors or processing units 604, a system memory 606, and a bus coupling various system components including the system memory 606 to the processor 604.

[0089] The bus represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, by way of example and not limitation, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus.

[0090] Computer system / server 602 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system / server 602, including both volatile and nonvolatile media, removable and non-removable media. System memory 606, in one embodiment, implements the flow diagrams of other figures. System memory 606 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 610 and / or cache memory 612. Computer system / server 602 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 614 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such cases, each may be connected to the bus by one or more data media interfaces. As further shown and described below, memory 606 may include at least one program product having a set (e.g., at least one) program module configured to perform the functions of various embodiments of the application.

[0091] A program / utility 616 having a set (at least one) of program modules 618 may be stored in memory 606, by way of example and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may comprise an implementation of a networking environment. The program modules 618 generally perform the functions and / or methodologies of various embodiments of the applications as described herein.

[0092] As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software (including firmware, resident software, microcode, etc.) embodiment, or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0093] The computer system / server 602 may communicate with one or more external devices 620, such as a keyboard, pointing device, display 622, etc.; one or more devices that allow a user to interact with the computer system / server 602; and / or any device (e.g., a network card, modem, etc.) that allows the computer system / server 602 to communicate with one or more other computing devices. Such communication may occur via an I / O interface 624. Furthermore, the computer system / server 602 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 626. As shown, the network adapter 626 communicates with the other components of the computer system / server 602 via a bus. Although not shown, it should be understood that other hardware and / or software components may be used in conjunction with the computer system / server 602. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data archive storage systems, and the like.

[0094] At least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description, but it will be understood that the present application is not limited to the disclosed embodiments and is susceptible to numerous rearrangements, modifications, and permutations as set forth and defined in the following claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or part of the functionality performed by individual modules may be performed by one or more of those modules. Furthermore, the functionality described herein may be performed at various times and in connection with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Furthermore, messages sent or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0095] Those skilled in the art will appreciate that a "system" can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in both local and distributed fashions consistent with computing technology.

[0096] It should be noted that some of the system functionality described herein has been presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

[0097] Modules may also be implemented at least partially in software for execution by various types of processors. For example, an identified unit of executable code may comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. Nevertheless, the executable files of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations, which, when logically combined together, comprise a module and achieve the stated purpose of the module. Furthermore, a module may be stored on a computer-readable medium, which may be, for example, a hard disk drive, a flash device, a random access memory (RAM), a tape, or any other such medium used to store data.

[0098] Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed across several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and depicted herein within modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or may be distributed across different locations, including different storage devices, or may exist, at least in part, solely as electronic signals on a system or network.

[0099] It will be readily understood that the components of the present application, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments of the present application.

[0100] Those skilled in the art will readily appreciate that the above may be practiced in a different order of steps and / or with hardware elements in different configurations than those disclosed. Thus, while the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

[0101] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely exemplary, and that the scope of the present application should be defined solely by the appended claims when considering the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. a network interface configured to receive a message from an agent installed at a data replication server, the message including a status identifier of a checksum validation of a data replication operation; and 1. A processor, comprising: Identifying a latency value associated with the data replication server; determining whether data loss has occurred based on the checksum validation status identifier and the latency value; In response to determining that the data loss has occurred, sending a notification of the data loss via the network interface to a computing system associated with the data replication server. A processor configured to An apparatus comprising:

2. The apparatus of claim 1 , wherein the message further includes an agent identifier of the agent installed at the data replication server and an identifier of a transaction within the data replication operation.

3. 2. The apparatus of claim 1, wherein the network interface receives a plurality of messages from the agent installed on the data replication server during the data replication operation, and the processor is configured to generate a tracing table having identifiers of a plurality of transactions included in the data replication operation and checksum validation status identifiers of the plurality of transactions, each of which is included in the plurality of messages.

4. The apparatus of claim 3 , wherein the processor is further configured to run a machine learning model on the generated tracing table to predict the latency values.

5. The apparatus of claim 3 , wherein the processor is further configured to receive a request for a status of the data replication operation and to display content from the tracing table via a user interface in response to the request.

6. 2. The apparatus of claim 1, wherein the processor is further configured to determine to request revalidation of transactions included in the data replication operation based on a number of occurrences of requests for revalidation that have already been performed.

7. 2. The apparatus of claim 1, wherein the processor is configured to receive a checksum validation status identifier for the data replication operation from a plurality of agents installed on a plurality of data replication servers involved in the data replication operation, respectively.

8. 2. The apparatus of claim 1, wherein the processor is further configured to identify transactions that were not successfully received based on the determination and to send a control signal to a source data replication server to retransmit the transactions.

9. receiving a message from an agent installed at a data replication server, the message including a status identifier of a checksum validation of the data replication operation; identifying a latency value associated with the data replication server; determining whether data loss has occurred based on the checksum validation status identifier and the latency value; and In response to determining that the data loss has occurred, sending a notification of the data loss to a computing system associated with the data replication server. A method comprising:

10. 10. The method of claim 9, wherein the message further includes an agent identifier of the agent installed at the data replication server and an identifier of a transaction within the data replication operation.

11. 10. The method of claim 9, further comprising: receiving a plurality of messages from the agent installed on the data replication server during the data replication operation; and generating a tracing table having identifiers of a plurality of transactions included in the data replication operation and checksum validation status identifiers of the plurality of transactions, each of the plurality of messages being included in the data replication operation.

12. The method of claim 11 , further comprising running a machine learning model on the generated tracing table to predict the latency values.

13. 12. The method of claim 11, further comprising receiving a request for a status of the data replication operation, and displaying content from the tracing table via a user interface in response to the request.

14. 10. The method of claim 9, further comprising determining to request revalidation of transactions involved in the data replication operation based on a number of occurrences of requests for revalidation that have already been performed.

15. 10. The method of claim 9, further comprising receiving a checksum validation status identifier for the data replication operation from a plurality of agents installed on a plurality of data replication servers involved in the data replication operation, respectively.

16. 10. The method of claim 9, further comprising identifying transactions that were not successfully received based on the determination, and sending a control signal to a source data replication server to retransmit the transactions.

17. 1. A computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to: receiving a message from an agent installed at a data replication server, the message including a status identifier of a checksum validation of the data replication operation; identifying a latency value associated with the data replication server; determining whether data loss has occurred based on the checksum validation status identifier and the latency value; and In response to determining that the data loss has occurred, sending a notification of the data loss to a computing system associated with the data replication server. A computer-readable storage medium for performing a method comprising:

18. 20. The computer-readable storage medium of claim 17, wherein the message further includes an agent identifier of the agent installed at the data replication server and an identifier of a transaction within the data replication operation.

19. 20. The computer-readable storage medium of claim 17, wherein the method further comprises receiving, during the data replication operation, a plurality of messages from the agent installed on the data replication server, and generating a tracing table having identifiers of a plurality of transactions involved in the data replication operation and checksum validation status identifiers of the plurality of transactions, each of the plurality of messages being included therein.

20. 20. The computer-readable storage medium of claim 19, wherein the method further comprises running a machine learning model on the generated tracing table to predict the latency values.

Images