Synchronization of distributed data files
By using lock files to synchronize data files in a distributed system, the problems of synchronization latency and high network overhead in existing technologies are solved. This achieves efficient data file synchronization and a simplified database modification process, improving workload execution performance and deployment efficiency.
Patent Information
- Application Number
- CN202111266399.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-03-22
- Filing Date
- 2021-10-28
- Publication Date
- 2025-12-19
- Estimated Expiration
- 2041-10-28
AI Technical Summary
In distributed systems, existing technologies struggle to efficiently synchronize data files, especially when deploying new applications over a wide area network. This results in excessive communication latency and network overhead, and changing the database type may require rewriting the application, a cumbersome process.
By acquiring the lock file from the host node, identifying the node with the latest data version, synchronizing the local copy, and updating the lock file, efficient synchronization of data files is ensured, reducing iterative acquisition of the lock file and providing effective synchronization of distributed data files.
It enables efficient data file synchronization in distributed systems, reduces communication latency and network overhead, simplifies the database type change process, and improves workload execution performance and deployment efficiency.
Smart Images

Figure CN115114257B_ABST
Abstract
Description
BACKGROUND
[0001] Cloud computing facilitates enhanced performance and delivery of applications and services by virtualizing the distribution of computing workloads across a network of computers or servers. Applications can be developed as a set of microservices running in containers. Containers package the workloads and workload dependencies together so that the workloads can be executed in servers located in different geographical locations. Each workload can include configuration settings, characteristics, and properties that can be stored in a data file. The data file can be stored locally on a host server or at a remote storage location. BRIEF DESCRIPTION OF DRAWINGS
[0002] These and other features, aspects, and advantages of the present specification will become better understood with reference to the following detailed description when considered in connection with the accompanying drawings, in which like characters represent like parts throughout the drawings, wherein
[0003] Figure 1 depicts an example networking system for synchronizing data files in a network of distributed nodes according to one example;
[0004] Figure 2A and Figure 2B depicts a lock file according to one example;
[0005] Figure 3 is a flowchart depicting a method for synchronizing distributed data files according to another example;
[0006] Figure 4 is a flowchart depicting a method for synchronizing distributed data files with bulk modifications performed by a plurality of threads associated with a workload according to one example;
[0007] Figure 5A , Figure 5B , Figure 5C and Figure 5D depicts a modification performed by a thread associated with a workload on a data file according to one example;
[0008] Figure 6 is a flowchart depicting a method for synchronizing data files in a distributed network at regular intervals according to one example; and
[0009] Figure 7 is a block diagram depicting a processing resource and a machine-readable medium encoded with example instructions for synchronizing data files in a distributed network according to one example.
[0010] It should be emphasized that in the drawings, various features are not necessarily drawn to scale. Indeed, in the drawings, the dimensions of various features can have been arbitrarily expanded or reduced for the sake of discussion. DETAILED DESCRIPTION
[0011] The following detailed description is directed to the drawings. Like numbers refer to like elements throughout. It will be apparent that the drawings described below are for illustrative purposes and are not intended to limit the disclosed examples. The following detailed description, given by way of example, is not limited to the disclosed examples. Rather, the appropriate scope of the disclosed examples is limited only by the appended claims.
[0012] The terminology used herein is for the purpose of describing particular examples and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. As used herein, the term "another" is defined as at least a second or more. The term "coupled" as used herein is defined as connected, whether directly without any intervening elements or indirectly with at least one intervening element. For example, two elements can be coupled mechanically, electrically, or communicatively through a communication channel, passage, network, or system. Further, the term "and / or" as used herein refers to and encompasses any and all possible combinations of the associated listed items. It will also be understood that, although the terms first, second, third, fourth, etc. can be used herein to describe various elements, these elements should not be limited by these terms since the terms are only used to distinguish one element from another unless otherwise specified or understood from the context. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.
[0013] Cloud computing facilitates performance and delivery of applications and services by virtualizing computing workloads across computer networks or server networks. Applications or workloads can be developed as a collection of microservices running in containers. Containers package workloads and workload dependencies together to make workloads executable and hatchable in different servers located in different geographical locations over a wide area network, thus providing improved services to consumers in a global manner.
[0014] Examples of workloads can include, but are not limited to, containerized applications, containers, pods, virtual machines, or any piece of code that can be implemented as microservices. Workloads can be managed via workload orchestration systems. Various features of cloud computing such as microservices architecture, modern design, containerization, automation, etc. allow faster development and delivery of new workloads and faster problem resolution.
[0015] Many cloud-based applications are developed using links in databases such as relational databases that provide on-disk data storage. Such applications can store a copy of a data file locally on the deployed server. The data file can include configuration settings, characteristics, and properties of the application. Scaling such an application to a cluster of servers involves several challenges. For example, if transactions or modifications on the data file are performed by an application instance on one server, other instances of the same application deployed on other servers can not be aware of these transactions.
[0016] In some solutions, such as in a hybrid cloud environment, data used by an application can be stored at a central server, which in some examples can be a remote server. Once an application requests the latest version of a data file, the data can be accessed from the central server to synchronize and update the local data file. However, in this example, applications accessing the same data file stored at a common central server can run slower than expected due to high latency and low bandwidth. For example, when a server is far from the centralized storage and / or the shared data file is large, communication latency can result.
[0017] Changing the type of database, for example, to a client-server database, can introduce problems. For example, other types of databases do not provide automatic discovery or synchronization of newly instantiated applications and related data files in a network. Specifically, other databases do not provide synchronization of distributed data files if a new application is hatched or deployed in another cloud environment over a wide area network. Even if synchronization is implemented, it can introduce a large amount of network overhead. Still further, an application can be coded to use an on-disk database file format; therefore, changing the database type of the application can involve rewriting the application, which can be tedious and labor intensive.
[0018] To this end, in accordance with aspects of the present disclosure, a solution for synchronizing distributed data files is presented. In some examples, a host node obtains a lock file from a central node storing a central copy of a data file, the lock file including a first list of nodes and a second list of nodes. The first list of nodes indicates identities of a first set of nodes having a latest version of the data file, and the second list of nodes indicates identities of a second set of nodes that have modified the data file. If an identity of the host node is not indicated in the first list of nodes, a most recent node to the first list of nodes is identified. The host node obtains an updated portion of the latest version of the data file from the most recent node for synchronizing a local copy. The host node performs modifications to the local copy and updates the lock file by indicating the identity in the first list of nodes and the second list of nodes. The host node then provides the modified portion of the local copy to the central node for synchronizing the central copy with the local copy.
[0019] It should be appreciated that the examples presented herein facilitate enhanced synchronization of distributed data files. The examples presented herein ensure that modifications or transactions performed by multiple participating nodes are retrieved and applied in the correct order before transactions are produced in a local copy. Efficient synchronization of distributed data files can provide enhanced performance and execution of workloads on target environments (e.g., clusters of workload orchestration systems) in customers’ local private cloud data centers that are owned or rented or consumed as a service product of a public cloud provider (e.g., by pay-per-use or consumption-based financial models), for example. Further, the enhanced synchronization of distributed data files affected by the various example aspects presented herein reduces or eliminates iterative acquisition of lock files by a host node to synchronize transactions initiated by each thread in a workload. For instance, a host node can complete modifications or transactions performed by threads in a workload and then release a lock file back to a central node. Also, the examples presented herein provide efficient synchronization of distributed data files once new workload instances are deployed over a wide area network.
[0020] Now, referring to the drawings, in Figure 1 a networking system 100 is depicted in accordance with an example. The networking system 100 can include a plurality of nodes 102, 104, 106 and a central node 108 coupled to each other via a network 110. In some examples, the networking system 100 can be a distributed system in which the nodes 102-106 and the central node 108 can be located at physically different locations (e.g., on different racks, on different enclosures, in different buildings, in different cities, in different countries, etc.) while connected via the network 110. In yet another example, the central node 108 and the nodes 102-106 can be co-located
[0021] Examples of the network 110 can include, but are not limited to, an Internet Protocol (IP) or non-IP based Local Area Network (LAN), a Wireless LAN (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Storage Area Network (SAN), a Personal Area Network (PAN), a cellular communication network, a Public Switched Telephone Network (PSTN), and the Internet. Communications over the network 110 can be performed in accordance with various communication protocols such as, but not limited to, the Transmission Control Protocol and the Internet Protocol (TCP / IP), the User Datagram Protocol (UDP), IEEE 802.11, and / or cellular communication protocols. Communications over the network 110 can be implemented via wired (e.g., copper, optical communications, etc.) or wireless communication technologies. In some examples, the network 110 can be enabled via private communication links including, but not limited to, communication links established via wireless, wired (e.g., copper wire), etc. In some examples, the private communication links can be direct communication links between the nodes 102-106 and the central node 108.
[0022] Each node 102-106 can facilitate resources, e.g., compute, storage, and / or networking capabilities, on which one or more workloads are executed. Nodes 102-106 can be systems that include processors or microcontrollers and / or any other electronic components, or devices or systems that can facilitate various computing and / or data storage services. Nodes 102-106 can have similar or varying hardware and / or software configurations in a given implementation of networked system 100. In some examples, central node 108 can facilitate storage and networking capabilities for centrally storing data files associated with workloads. Alternatively, in other examples, the central node can also facilitate compute capabilities for executing one or more workloads. Examples of nodes 102-106 and central node 108 can include, but are not limited to, servers, server clusters, container orchestration systems, container orchestration system clusters, computer facilities, workstations, desktop computers, laptops, smartphones, storage systems, or converged or hyper-converged systems, etc. Further, in certain examples, nodes 102-106 can be virtual machines or containerized applications executing on hardware in networked system 100. By way of example, while some nodes 102-106 can have high-end compute capabilities, some nodes can facilitate strong data security, and certain nodes can have enhanced heat dissipation capabilities.
[0023] In some examples, nodes 102-106 can include processing resources 112, 114, 116 and machine-readable media 118, 120, 122. Machine-readable media 118-122 can be any electronic, magnetic, optical, or other physical storage device that can store data and / or executable instructions 124, 126, 128. For example, machine-readable media 118-122 can include random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), a storage drive, Flash memory, compact disc read-only memory (CD-ROM), and the like. Machine-readable media 118-122 can be non-transitory. As detailed herein, machine-readable media 118-122 can be encoded with executable instructions 124-128 to perform one or more methods, e.g., Figure 3 、 Figure 4 and Figure 6 the methods described.
[0024] In some examples, the nodes 102-106 can execute workloads 130, 132, 134. In one example implementation, the workloads 130-134 can be different instances of the same workload. The term workload can refer to a computing resource including, but not limited to, an application (e.g., machine executable instructions), a virtual machine (VM), a container, a pod, or a containerized application. In some examples, the workloads 130-134 can include any code that can be developed as a microservice. It should be appreciated that a workload such as a VM can be an instance of an operating system hosted on a given node via a VM host program such as a hypervisor. Further, a workload such as a container can be an encapsulated application with its dependencies (e.g., operating system resources, processing allocation, memory allocation, etc.) hosted on a given node via a container host program such as, for example, a container runtime (e.g., Docker Engine). Further, in some examples, a workload can include a pod formed by grouping one or more containers. For example, a group of containers associated with a general purpose application can be grouped to form a pod.
[0025] In the description, for purposes of illustration, the workloads 130-134 are described as applications and the nodes 102-106 are described as servers located in different data centers in various geographic locations. In other examples, the workloads 130-134 can be different types of workloads such as VMs, containers, pods, or other types of workloads. Figure 1 In examples, the nodes 102-106 can be considered to host different instances of the same workload. Depending on the respective hardware and / or software configuration, the nodes 102-106 can facilitate execution of any number of workloads 130-134. Each node 102-106 can also facilitate an on-disk database for storing local copies of data files associated with the workload instances 130-134 hosted in the respective node. In some examples, the nodes 102-106 can include a combination of different types of storage devices such as disks, flash, solid state drives (SSDs), etc. In various examples, the local copies of the data files 136-140 can be embedded to the end of the workloads 130-134 as an embedded database for local storage. Examples of the embedded database can include a relational database management system, a key-value database, a multi-threaded disk-based table, a transactional database engine, etc.
[0026] Further, processing resources 112-116 can be physical devices, such as one or more central processing units (CPUs), one or more semiconductor-based microprocessors, one or more graphics processing units (GPUs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), other hardware devices capable of retrieving and executing instructions 124-128 stored in machine-readable media 118-122, or a combination thereof. Processing resources 112-116 can fetch, decode, and execute instructions 124-128 stored in machine-readable media 118-122 to synchronize data files (further described below) associated with a workload. Alternatively or in addition to executing instructions 124-128, processing resources 112-116 can be comprised of at least one integrated circuit (IC), control logic, electronic circuitry, or a combination thereof, that includes several electronic components for performing functions intended to be performed by nodes 102-106. Also, in certain examples in which nodes 102-106 can be virtual machines or containerized applications, processing resources 112-116 and machine-readable media 118-122 can represent processing resources and machine-readable media of a hardware or computing system that hosts nodes 102-106 as virtual machines or containerized applications.
[0027] In Figure 1 In the example, although networking system 100 is shown to include three nodes 102-106, networking system 100 can include any number of nodes without limiting the scope of the present disclosure. Also, although a single central node 108 is shown, networking system 100 can include more than one central node 108 located in different geographic locations without limiting the scope of the present disclosure. For purposes of explanation, node 102 can be referred to as host node or processor-based system 102 hereinafter. Also, nodes 104, 106 can be collectively referred to as participating host nodes or participating nodes 104, 106 hereinafter.
[0028] During operation of host node 102, processing resources 112 can obtain lock file 142 from central node 108, which can store a central copy of a distributed data file 144 associated with workload instances 130-134 distributed across network 110. The distributed data file can be a transactional data file or a shared data file system. The distributed data file can be an ACID (Atomicity, Consistency, Isolation, Durability) compliant database file. Throughout the specification, the terms “data file” and “distributed data file” can be used interchangeably. Figure 2A And 2B An example of lock file 142 is depicted. Referring to Figure 2AThe lock file 142 can include a first node list 202 and a second node list 204. In some examples, the first node list 202 can indicate the identity of a first set of nodes that have the latest version of the data file, and the second node list 204 can indicate the identity of a second set of nodes that recently performed modifications to the data file. The second node list 204 can indicate the second set of nodes in an order in which the nodes modified the data file. The identity of the node that can have performed the latest modification is indicated at the top, i.e., as the first entry in the list. For example, in the lock file 142-1, the first node identity (indicated at the top of the second node list 204) is host #2, which indicates that host 104 can have performed the latest modification to the data file.
[0029] In some examples, upon acquiring the lock file 142 by a node (e.g., host node 102), other hosts (e.g., participating nodes 104, 106) in the network 110 can be prevented or disabled from modifying the central copy of the data file 144. In some examples, a locking mechanism such as a portable operating system interface (POSIX) lock can be implemented to lock the central copy of the data file 144 from being modified by other nodes 104, 106. In some examples, acquiring the lock file 142 can include implementing a user space file system (FUSE) interface to create a remote call request to the central node 108 for exclusive read / write privileges to the central copy of the data file 144.
[0030] Referring back to Figure 1 , the processing resource 112 can check whether the identity of the host node 102 matches the identity specified in the first node list 202 in the lock file 142. If the identities do not match, the processing resource 112 can identify a most recent participating node 104, 106 that has the latest version of the data file from the first set of nodes in the first node list 202. The processing resource 112 can obtain an updated portion of the latest version of the data file from the identified most recent participating node 104, 106. The processing resource 112 can synchronize the local copy of the data file 136 with the latest version using the updated portion. The processing resource 112 can modify the local copy of the data file 136 after the synchronization. In some examples, the modification can include adding, deleting, or updating a row included in a database table in the data file (as described herein with respect to Figures 5A to 5D
[0031] After modifying the local copy of the data file 136, the processing resource 112 can update the lock file 142 by indicating the identity of the host node 102 in the first node list 202 and the second node list 204. In some examples, updating the lock file 142 after modification can include erasing or deleting the identities of the first set of nodes in the first node list 202 and indicating the identity of the host node 102. As shown, Figure 2B “Host #2” and “Host #3” are erased from the lock file 142-1 and “Host #1” is indicated in the first node list 202 of the lock file 142-2. Further, the identity of the host node 102 is appended to the top, i.e., as the first entry on the second node list 204. Thus, the second node list 204 indicates “Host #1” above the “Host #2” that previously modified the data file. In some examples, the identity of the host node can be indicated using the IP address of the respective host node.
[0032] The processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108 for synchronizing the central copy of the data file 144 with the modified local copy of the data file 136. The host node 102 can then release the lock file 142 back to the central node 108 and can make the lock file 142 available for acquisition by the participating nodes 104, 106. It should be understood that the nodes 102-106 presented herein facilitate improved deployment and execution of the workload instances 130-134. Specifically, with the enhanced synchronization of the data files as influenced by the various example aspects presented herein, the workload instances 130-134 can be executed on a highly configured host node that has sufficient resources to meet the requirements of the workload. Synchronizing the data files associated with the workload can enable enhanced performance and execution of the workload on a networked system (e.g., a workload orchestration system cluster) of the customer’s indoor product or as-a-service product. Moreover, the synchronization of the data files can be performed after multiple threads of the workload 130-134 make block modifications to the data files, thereby reducing latency and bandwidth issues (described in greater detail herein with respect to Figure 4
[0033] Reference is now made to Figure 3 , in accordance with an example, a flowchart depicting a method 300 for synchronizing data files in the distributed network 110 is presented. For purposes of illustration, the method 300 is presented in conjunction with the distributed network 110. Figure 1 The networking system 100 of FIG. 1 is described with respect to a method 300. The method 300 can include method blocks 302, 304, 306, 308, 310, 312, and 314 (hereinafter collectively referred to as blocks 302-314) that can be performed by a processor-based system, such as, for example, the host node 102. Specifically, the operations of each of the method blocks 302-314 can be performed by the processing resource 112 by executing instructions 124 stored in the machine-readable medium 118 (see FIG. 1). Moreover, it should be noted that the order of execution of the blocks 302-314 can differ from that shown in Figure 1 FIG. 3 in some examples. For example, the blocks 302-314 can be executed in series, in parallel, or in a combination of series and parallel. Figure 3
[0034] At block 302, the processing resource 112 can obtain the lock file 142 from the central node 108, which can store a central copy of the data file 144 associated with the workload 130 in the network 110. As previously described, the lock file 142 can include a first node list indicating the identity of a first set of nodes having the most recent version of the data file and a second node list indicating the identity of a second set of nodes that recently modified the data file. In some examples, the size of the lock file 142 can be extremely small or negligible compared to the size of the data file (e.g., the central copy of the data file 144). For example, the lock file 142 can be less than 1-2 megabytes of data, while the central copy of the data file 144 can be greater than 20 megabytes in size.
[0035] The processing resource 112 can use the lock file 142 to check whether the host node 102 has the most recent version of the data file. For example, the processing resource 112 can check whether the first node list indicates the identity of the host node 102. At block 304, if the identity of the host node 102 does not match the identity indicated in the first node list 202, the processing resource 112 can identify the nearest participating node 104, 106 from the first node list 202. In other examples, the identification of the nearest participating node 104, 106 can be performed based on the location or geographic proximity to the host node 102. In other examples, the identification of the nearest participating node 104, 106 can be based on the minimum latency or highest bandwidth associated with the nodes 102-106.
[0036] Further, at block 306, the processing resource 112 can obtain the updated portion of the latest version of the data file from the most recently participating node 104, 106. At block 308, the processing resource 112 can synchronize the local copy of the data file 136 stored on the host node 102 with the latest version using the updated portion. Further, the processing resource 112 can modify the local copy of the data file 136. In some examples, modifying the local copy of the data file 136 can be initiated by a plurality of threads associated with the workload 130 (described in greater detail herein with respect to FIG. 3). At block 312, the processing resource 112 can update the lock file 142 by indicating the identity of the host node 102 in the first node list 202 and the second node list 204. Further, at block 314, the processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108 to synchronize the central copy 144 with the local copy of the data file 136 using the modified portion. In some examples, when a new instance of the workload is deployed on a new node in the network, the method can further include obtaining the lock file 142 from the central node 108 and retrieving the central copy 144 of the data file 108 from the central node. The modification can be performed in a similar manner as described in method blocks 302-314. Figure 4 Further, at block 306, the processing resource 112 can obtain the updated portion of the latest version of the data file from the most recently participating node 104, 106. At block 308, the processing resource 112 can synchronize the local copy of the data file 136 stored on the host node 102 with the latest version using the updated portion. Further, the processing resource 112 can modify the local copy of the data file 136. In some examples, modifying the local copy of the data file 136 can be initiated by a plurality of threads associated with the workload 130 (described in greater detail herein with respect to FIG. 3). At block 312, the processing resource 112 can update the lock file 142 by indicating the identity of the host node 102 in the first node list 202 and the second node list 204. Further, at block 314, the processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108 to synchronize the central copy 144 with the local copy of the data file 136 using the modified portion. In some examples, when a new instance of the workload is deployed on a new node in the network, the method can further include obtaining the lock file 142 from the central node 108 and retrieving the central copy 144 of the data file 108 from the central node. The modification can be performed in a similar manner as described in method blocks 302-314.
[0037] 202and second node list 204. At block 312, the processing resource 112 can update the lock file 142 by indicating the identity of the host node 102 in the first node list 202 and the second node list 204. Further, at block 314, the processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108 to synchronize the central copy 144 with the local copy of the data file 136 using the modified portion. In some examples, when a new instance of the workload is deployed on a new node in the network, the method can further include obtaining the lock file 142 from the central node 108 and retrieving the central copy 144 of the data file 108 from the central node. The modification can be performed in a similar manner as described in method blocks 302-314.
[0038] 142.In some examples, updating the first node list 202 after the modification can include removing the identities of the first set of nodes and indicating the identity of the host node 102 in the first node list. In some examples, updating the second node list 204 can include appending the identity of the host node 102 to the top of the second set of nodes 204. Further, at block 314, the processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108 to synchronize the central copy 144 with the local copy of the data file 136 using the modified portion. In some examples, when a new instance of the workload is deployed on a new node in the network, the method can further include obtaining the lock file 142 from the central node 108 and retrieving the central copy 144 of the data file 108 from the central node. The modification can be performed in a similar manner as described in method blocks 302-314.
[0039] Figure 4 is a flowchart depicting a method for synchronizing a data file involving modifications performed by a plurality of threads associated with a workload, according to another example. At block 402, the processing resource 112 receives a modification flag from a thread of the workload 130. The modification flag can be a notification indicating that at least one thread associated with the workload 130 has modified the local copy of the data file 136. Figure 5A 、 Figure 5B 、 Figure 5C and Figure 5D depicts a modification performed by a thread associated with a workload on a data file, according to one example. As described above, the modification can be performed by a plurality of threads associated with the workload (described in greater detail herein with respect to FIG. 3). At block 404, the processing resource 112 can obtain the updated portion of the latest version of the data file from the most recently participating node 104, 106. At block 406, the processing resource 112 can synchronize the local copy of the data file 136 stored on the host node 102 with the latest version using the updated portion. Further, the processing resource 112 can modify the local copy of the data file 136. In some examples, modifying the local copy of the data file 136 can be initiated by a plurality of threads associated with the workload 130 (described in greater detail herein with respect to Figure 5AAs shown in 500A, the workload process 502 can include multiple threads 504-N. Each thread 504-N can be a sequence of instructions in the workload process 502 that can perform modifications or transactions on a local copy of the data file 136. The local copy of the data file 136 can include a transactional database table 506 having multiple rows and columns indicating key-value pair data.
[0040] In response to receiving the modification flag, the processing resource 112 can perform a double check using the lock file 142 whether any modifications have been made. For example, at block 404, the processing resource 112 can check the lock file 142 and determine that the identity of the host node 102 is indicated at the top of the second node list to confirm that a modification has been made to the local copy of the data file 136 at the host node 102. In various examples, multiple modifications or chunk modifications of the local copy of the data file 136 can be performed by multiple threads 504-N associated with the workload 130. As shown in 500B, the thread 504-1 can perform an operation to add a new row of key-value pairs (4, instance 4, instance 2, host 2) to the database table. In 500C, the thread 504-2 can perform an update operation by updating the hostname in the 3rd row on the database table. In 500D, the thread 504-3 can perform a delete operation on the local copy of the data file 136 by deleting the key-value pair in the 4th row (4, instance 4, instance 2, host 2). The modifications of the multiple threads 504-N can be performed serially or in parallel on the database table. In some examples, the multiple threads can perform modifications sequentially, i.e., waiting for a modification to complete by a thread before performing the modification of the thread itself. Figure 5B Figure 5C Figure 5D
[0041] At block 406, the processing resource 112 can provide the modified portion of the local copy of the data file 136 to the central node 108. In some examples, the modified portion can be provided to the central node 108 in real-time. Alternatively, the modified portion can be provided to the central node 108 after completion of the modifications to the upstream transmission. The modified portion of the local copy of the data file 136 can include incremental modifications resulting from the multiple modifications performed by the multiple threads 504-N. In some examples, the modifications performed by each thread can be provided to the central node 108 in a single operation, rather than providing the modifications individually. In response to determining that modifications have been made to the local copy of the data file 136, the processing resource 112 can wait for the modifications to complete. For example, at block 408, the processing resource 112 can wait until a notification is received indicating that the multiple modifications to the local copy of the data file 136 performed by the multiple threads 504-N are complete. In some examples, the processing resource 112 can perform block 408, then perform block 406, or vice versa. In some examples, the processing resource 112 can perform blocks 406 and 408 concurrently. At block 410, the processing resource 112 can release the lock file 142 back to the central node 108 after providing the modified portion. Upon releasing the lock file 142, other participating host nodes 104, 106 can be able to access the central copy of the data file 144 and the lock file 142. For example, the participating host node 104 can acquire the lock file 142 and perform the method depicted in FIG. 4B. Figure 3 and Figure 4 the method depicted.
[0042] Figure 6is a flowchart depicting a method for synchronizing data files in distributed network 110 at regular intervals according to one example. At block 602, processing resource 112 can check whether a modification flag is received from thread 504-N associated with workload 130. At block 604, if no modification flag is received within a predetermined period of time, processing resource 112 can acquire lock file 142 from central node 108. At block 606, processing resource 112 can check whether the top of second node list 204 indicates the identity of host node 102. If the identity of host node 102 is indicated at the top of second node list 204, lock file 142 can be released back to central node 108. If the identity of the host node is not indicated at the top of second node list 204, host node 102 can obtain the latest copy from another node 104, 106. At block 608, processing resource 112 can obtain an updated portion of the latest version of data file from the most recent node indicated in first node list 202. At block 610, processing resource 112 can synchronize the local copy of data file 136 with the latest version of data file using the updated portion obtained from the most recent node. At block 612, processing resource 112 can append the identity of host node 102 to first node list 202. At block 614, processing resource 112 can release lock file 108 back to central node 108.
[0043] Moving to Figure 7 FIG. 7 is a block diagram 700 depicting processing resource 702 and machine-readable medium 704 encoded with example instructions to facilitate synchronization of data files 136-140 associated with workloads 130-134 according to one example. Machine-readable medium 704 can be non-transitory and can alternatively be referred to as non-transitory machine-readable medium 704. In some examples, machine-readable medium 704 can be accessible by processing resource 702. In some examples, processing resource 702 can represent one example of processing resource 112 of host node 102. Further, machine-readable medium 704 can represent one example of machine-readable medium 118 of host node 102.
[0044] Machine-readable medium 704 can be any electronic, magnetic, optical, or other physical storage device that can contain or store data and / or executable instructions. Thus, machine-readable medium 704 can be, for example, RAM, EEPROM, a storage drive, an optical data storage device, or the like. As described in detail herein, machine-readable medium 704 can be encoded with executable instructions 706, 708, 710, 712, 714, 716, and 718 (hereinafter collectively referred to as instructions 706-718) to perform Figure 3The method 300 is described. Although not shown, in some examples, the machine- readable medium 704 can be encoded with certain additional executable instructions to perform Figure 3 the method 300. Figure 3 operations and / or any other operations performed by the node 102.
[0045] The processing resource 702 can be a physical device, such as one or more CPUs, one or more semiconductor-based microprocessors, one or more GPUs, ASICs, FPGAs, other hardware devices capable of retrieving and executing instructions 706-718 stored in the machine- readable medium 704, or a combination thereof. In some examples, the processing resource 702 can fetch, decode, and execute the instructions 706-718 stored in the machine-readable medium 704 to synchronize data files of workloads deployed on one or more of the nodes 102-106 and the central node 108. In certain examples, the processing resource 702 can include at least one IC, other control logic, other electronic circuitry, or a combination thereof that includes several electronic components for performing the functions intended to be performed by the instructions 706-718 as an alternative or supplement to retrieving and executing the instructions 706-718. Figure 1 The host node 102 performs functions intended to be performed by the instructions 706-718 as an alternative or supplement to retrieving and executing the instructions 706-718.
[0046] The instructions 706, when executed by the processing resource 702, can cause the processing resource 702 to obtain the lock file 142 from the central node 108 that stores the central copy 110 of the data file 144 associated with the workload distributed across the network. As previously described, the lock file 142 includes a first node list and a second node list, the first node list indicating the identity of a first set of nodes having the most recent version of the data file, and the second node list indicating the identity of a second set of nodes that have modified the data file. Further, the instructions 708, when executed by the processing resource 702, can cause the processing resource 702 to identify a most recent node from the first node list in response to the identity of the processor-based system not matching the identities indicated in the first node list. In addition, the instructions 710, when executed by the processing resource 702, can cause the processing resource 702 to obtain an updated portion of the most recent version of the data file from the most recent node. Also, the instructions 712, when executed by the processing resource 702, can cause the processing resource 702 to synchronize the local copy of the data file stored on the node 102 with the most recent version using the updated portion. Further, the instructions 714, when executed by the processing resource 702, can cause the processing resource 702 to modify the local copy of the data file. The instructions 716, when executed by the processing resource 702, can cause the processing resource 702 to update the lock file by indicating the identity of the node 102 in the first node list and the second node list. The instructions 712, when executed by the processing resource 702, can cause the processing resource 702 to provide the modified portion of the local copy of the data file to the central node 108 for use in synchronizing the central copy with the local copy of the data file.
[0047] While certain implementations have been shown and described above, various changes can be made in form and detail. For example, some features and / or functions described in relation to one implementation and / or process can be associated with other implementations. In other words, processes, features, components and / or characteristics described in relation to one implementation can be used in other implementations. Still further, it is to be appreciated that the systems and methods described herein can include various combinations and / or sub-combinations of the components and / or features of the different implementations described.
[0048] In the foregoing description, numerous details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations can be practiced without some or all of these details. Other implementations can include modifications, combinations, and variations of the details discussed above. The following claims are intended to cover such modifications and variations.
Claims
1. A method comprising: A lock file is obtained by a processor-based system from a central node that stores a central copy of a data file associated with a workload, wherein the data file and the workload are distributed across a node network, and wherein the lock file includes a first node list and a second node list, the first node list indicating the identities of a first group of nodes that have the latest version of the data file, and the second node list indicating the identities of a second group of nodes that have modified the data file; In response to a mismatch between the identity of the processor-based system and the identity indicated in the first node list, the processor-based system identifies the nearest node from the first node list; The processor-based system obtains the latest version of the updated portion of the data file from the nearest node; The processor-based system uses the updated portion to synchronize a local copy of the data file stored on the processor-based system with the latest version. The local copy of the data file is modified by the processor-based system; The processor-based system updates the lock file by indicating the identity of the processor-based system in the first node list and the second node list; as well as The processor-based system provides the central node with a modified portion of the local copy of the data file, wherein the central copy uses the modified portion to synchronize with the local copy of the data file.
2. The method of claim 1, wherein the modification of the local copy of the data file is performed by a plurality of threads associated with the workload, and wherein the modification comprises: Add, delete, or update rows in the local copy of the data file.
3. The method according to claim 2, further comprising: The processor-based system receives a notification indicating the completion of multiple modifications to the local copy of the data file executed by the multiple threads; as well as The processor-based system provides the central node with the modified portions of the plurality of modifications to the local copy of the data file, wherein the central copy uses the modified portions to synchronize with the local copy of the data file.
4. The method according to claim 3, further comprising: After synchronizing the central copy with the local copy of the data file, the lock file is released back to the central node.
5. The method according to claim 1, further comprising: In response to the deployment of a new instance of the workload, the central copy of the data file is retrieved from the central node.
6. The method of claim 1, wherein updating the lock file further comprises: The identity of the first group of nodes in the first node list is removed by the processor-based system; The processor-based system indicates the identity of the processor-based system in the first node list; as well as The processor-based system appends the identity of the processor-based system to the top of the second node list.
7. The method according to claim 1, further comprising: In response to obtaining the lock file from the central node, the node is disabled from modifying the central copy of the data file.
8. The method of claim 1, wherein identifying the nearest node includes selecting the node from the first node list based on the location, bandwidth, or latency associated with the node.
9. A system comprising: Processing resources; A machine-readable medium stores instructions that, when executed by the processing resource, cause the processing resource to: A lock file is obtained from a central node that stores a central copy of a data file associated with a workload, wherein the data file and the workload are distributed across a node network, and wherein the lock file includes a first node list and a second node list, the first node list indicating the identities of a first group of nodes that have the latest version of the data file, and the second node list indicating the identities of a second group of nodes that have modified the data file. In response to a mismatch between the system's identity and the identity indicated in the first node list, the nearest node is identified from the first node list; Obtain the updated portion of the latest version of the data file from the nearest node; The updated portion is used to synchronize a local copy of the data file stored on the system with the latest version. Modify the local copy of the data file; The lock file is updated by indicating the identity of the system in the first node list and the second node list; as well as The modified portion of the local copy of the data file is provided to the central node, wherein the central node uses the modified portion to synchronize with the local copy of the data file.
10. The system of claim 9, wherein the workload includes multiple threads modifying the local copy of the data file, wherein modifying the local copy of the data file includes: Add, delete, or update rows in the data file.
11. The system of claim 10, wherein the processing resource executes one or more of the instructions to: Receive notifications indicating the completion of multiple modifications to the local copy of the data file executed by the multiple threads; and The central node is provided with a modified portion of the plurality of modifications to the local copy of the data file, wherein the central copy uses the modified portion to synchronize with the local copy of the data file.
12. The system of claim 11, wherein the processing resource executes one or more of the instructions to: release the lock file back to the central node after synchronizing the central copy with the local copy of the data file.
13. The system of claim 9, wherein, in order to update the lock file, the processing resource executes one or more of the instructions to: Remove the identity of the first group of nodes from the first node list; The identity of the system is indicated in the first node list; as well as The identity of the system is appended to the top of the second node list.
14. The system of claim 9, wherein, in order to identify the nearest node, the processing resource executes one or more of the instructions to: select the node from the first node list based on the location, bandwidth, or latency associated with the node.
15. The system of claim 9, wherein the workload includes an application, a container, a pod, a virtual machine, or a containerized application.
16. A non-transitory machine-readable medium storing instructions executable by processing resources, the instructions comprising: Instructions for retrieving a lock file from a central node storing a central copy of a data file associated with a workload, wherein the data file and the workload are distributed across a node network, and wherein the lock file includes a first node list and a second node list, the first node list indicating the identities of a first group of nodes having the latest version of the data file, and the second node list indicating the identities of a second group of nodes that have modified the data file; An instruction to identify the nearest node from the first node list in response to a mismatch between the system's identity and the identity indicated in the first node list; Instructions for obtaining the latest version of the updated portion of the data file from the nearest node; Instructions for synchronizing a local copy of the data file stored on the system with the latest version using the updated portion; Instructions for modifying the local copy of the data file; Instructions for updating the lock file by indicating the identity of the system in the first node list and the second node list; as well as Instructions for providing the central node with a modified portion of the local copy of the data file, wherein the central node uses the modified portion to synchronize with the local copy of the data file.
17. The non-transitory machine-readable medium of claim 16, further comprising instructions for: Receive notifications indicating the completion of multiple modifications to the local copy of the data file, executed by multiple threads associated with the workload; and The central node is provided with a modified portion of the plurality of modifications to the local copy of the data file, wherein the central copy uses the modified portion to synchronize with the local copy of the data file.
18. The non-transitory machine-readable medium of claim 17, further comprising instructions for releasing the lock file back to the central node after synchronizing the central copy with the local copy of the data file.
19. The non-transitory machine-readable medium of claim 16, wherein the instructions for updating the lock file further include instructions for: Remove the identity of the first group of nodes from the first node list; The identity of the system is indicated in the first node list; and The identity of the system is appended to the top of the second node list.
20. The non-transitory machine-readable medium of claim 16, further comprising an instruction for disabling the node from modifying the central copy of the data file in response to obtaining the lock file from the central node.
Citation Information
Patent Citations
Techniques for coordinating parallel performance and cancellation of commands in a storage cluster system
CN107079056A
Efficient management of client synchronization updates
CN111448559A