Suitability for Legacy Stateful Workloads

Abstract

Embodiments of the present invention provide computer systems, computer program products, and methods, the method including identifying replicated data in each data container of a plurality of data containers based on an indication marker reflecting the replication; calculating an amount of time to interact with the identified replicated data based on an alert threshold that, when activated, alerts remaining data containers of the plurality of data containers; and synchronizing the identified replicated data in each data container to reduce latency for interacting with the identified replicated data based on a priority of the calculated amount of interaction time, with higher priority being placed on lower calculated interaction times.

Description

[Technical Field]

[0001] The present invention relates generally to the field of data consistency, and more particularly to a dynamic consistency mechanism for container orchestration. [Background technology]

[0002] A legacy application is an old or outdated software program. Although they still function, legacy applications may be unstable due to compatibility issues with current operating systems, browsers, and information technology infrastructure. Often, referring to a program, application, or system as legacy means that it has paved the way for standards that follow.

[0003] Container orchestration refers to the process of orchestrating the work of individual components and application layers. Container orchestration automates the deployment, management, scaling, and networking of containers. Container orchestration can be used in any environment that uses containers. It helps deploy the same application across different environments without having to redesign it. Container orchestration is typically used to automate and manage tasks. Additionally, container orchestration tools provide a framework for managing container and microservices architectures at scale.

[0004] Data integrity means that accessed data is available. In a database system, data integrity refers to the requirement that any given database transaction must modify the affected data only in permissible ways. Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination of these. This does not guarantee transaction correctness in every way the application programmer might have desired (i.e., that is the responsibility of the application-level code), but simply ensures that no programming error results in the violation of any defined database constraints.

[0005] Overlay refers to the process of transferring a block of program code or other data into main memory, replacing what is already stored there. Overlay is a programming method that allows a program to be larger than the computer's main memory. Embedded systems typically use overlays due to the limitations of physical memory, which is the internal memory for a system-on-chip, and the lack of virtual memory capabilities. Summary of the Invention

[0006] Embodiments of the present invention provide a computer system, a computer program product, and a method, the method including: identifying replicated data in each data container of a plurality of data containers based on an indication marker reflecting the replication; calculating an amount of time to interact with the identified replicated data based on an alert threshold that, when triggered, alerts remaining data containers of the plurality of data containers; and synchronizing the identified replicated data in each data container to reduce latency for interacting with the identified replicated data based on a priority of the calculated amount of interaction time, with higher priority being placed on lower calculated interaction times. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a functional block diagram illustrating an environment having a computing device connected to or in communication with other computing devices in accordance with at least one embodiment of the present invention. [Figure 2] 1 is a flowchart illustrating operational steps for dynamically generating a consistency mechanism for container orchestration, in accordance with at least one embodiment of the present invention. [Figure 3] 10 is a graph illustrating a comparison of time to access a stateful set according to one embodiment of the present invention. [Figure 4] FIG. 2 is a block diagram of components of a computing system within the computing and display environment of FIG. 1, according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0008] Embodiments of the present invention recognize the need for improvements to current modern shared volume interactions of legacy stateful process workloads that are not designed to take advantage of rapid developments in workload orchestration and new features. For example, a workload might be a multi-process workload that writes to a file with a locking mechanism defined as a stateful interaction, resulting in multiple data containers with their own volumes that will remain inconsistent because locking does not work across volumes. On the other hand, if the workload is treated as replicated data, forcing replicated data containers to mount the same volume, contention, as defined later in this detailed description, does not scale well as the replicated data count increases, thereby slowing the system. Embodiments of the present invention improve current modern shared volume interactions of legacy stateful process workloads by modernizing the shared volume interactions of legacy workloads to support stateful replication and orchestration, while mitigating performance degradation by overlaying a consistency framework and interleaving synchronization processes. Embodiments of the present invention provide systems, methods, and computer program products for solutions that modernize legacy shared volume interactions to create mechanisms that support a form of consistency for orchestrating stateful workloads without assuming the availability of legacy system consistency, and provide interleaved synchronization of volume replication to balance performance and consistency. Currently, legacy systems are not designed to take advantage of rapid developments and new capabilities in orchestrating newer workloads. Generally, legacy stateful process workload technologies do not support any form of consistency for orchestrating stateful workloads and do not have consistency mechanisms for operating across logical constructs between data containers within a stateful set.These use cases are typically found in legacy process workloads that are built to operate within volume management, both as a single process or as multiple processes interacting with advisory locks. Embodiments of the present invention are an improvement over current legacy systems by using an overlaid consistency mechanism that does not assume consistency availability in the legacy software and provides interleaved synchronization of volume replicas to balance performance and consistency. Embodiments of the present invention distribute data into separate sets, monitor separate steps, discover control paths for request types between the separate sets, estimate volume access probabilities across the separate sets, and prioritize the separate sets based on volume synchronization.

[0009] FIG. 1 is a functional block diagram of a computing environment 100 according to an embodiment of the present invention. The computing environment 100 includes a computing device 102 and a server computing device 108. The computing device 102 and the server computing device 108 may be desktop computers, laptop computers, specialized computer servers, smart phones, smart appliances, smart devices, or any other computing devices known in the art. In particular embodiments, the computing device 102 and the server computing device 108 may represent computing devices that utilize multiple computers or components to act as a single pool of seamless resources when accessed over a network 106. In this embodiment, the computing device 102 may be defined as an orchestrator that stores replicated data and mounted volumes and performs stateful set synchronization. In general, the computing device 102 and the server computing device 108 may represent any electronic device or combination of electronic devices capable of executing machine-readable program instructions, as described in more detail with respect to FIG. 4.

[0010] Computing device 102 may include program 104. Program 104 may be a stand-alone program on computing device 102. In other embodiments, program 104 may be stored on server computing device 108. In this embodiment, program 104 modernizes the shared volume interactions of legacy stateful single-process or multi-process workloads by overlaying a consistency framework that monitors the locking and volume interactions of replicated stateful workloads and interleaves synchronization processes between stale and up-to-date replicas within gaps discovered in the volume access patterns of the workload's control path to support stateful replication and orchestration while mitigating performance degradation. In this embodiment, program 104 overlays a consistency framework and interleaves synchronization processes by packaging legacy data into stateful sets, monitoring stateful steps, discovering control paths for request types between control blocks located within the stateful sets and replicated data, estimating volume access probabilities across the stateful sets, and prioritizing the stateful sets based on volume synchronization estimates.

[0011] In this embodiment, the program 104 packages (i.e., distributes) the legacy data into a stateful set by extracting process binaries from a database and converting the extracted process binaries into containers.

[0012] In this embodiment, program 104 monitors changes in the volume manager database and locking mechanisms created for stateful sets by dispatching inputs of access pattern information over a predetermined period associated with each stateful set and synchronizing replicated data across stateful sets. In this embodiment, replicated data is defined as data that is copied in separate sets. In this embodiment, program 104 monitors single-process and multi-process applications using notification locks. In this embodiment, program 104 monitors changes in stateful sets over a period of time.

[0013] In this embodiment, program 104 uses run-time analysis of processes to discover control paths for request types, and these control paths depend on the types of data stored within the stateful set. In this embodiment, program 104 determines logical distances between components located within the stateful set, such as control blocks and replicated data. In this embodiment, program 104 identifies replicated data within each of the multiple data containers based on indicator markers that reflect the replication.

[0014] In this embodiment, program 104 estimates the volume access probability by calculating the volume access probability based on the discovered control path. In this embodiment, the estimation is based on the difference between the time it takes for the discovered control path to reach a given data replica in the volume and the synchronization time for the data replica. In this embodiment, program 104 calculates the amount of time to interact with the identified replica data based on a warning threshold that, when activated, warns the remaining data containers of the plurality of data containers.

[0015] In this embodiment, program 104 prioritizes volume synchronization based on estimated volume access probabilities and discovers interleaving opportunities and priorities for volume synchronization. In this embodiment, program 104 prioritizes based on imminent lock contention events or based on a separate set of new request types with high estimated probabilities. In this embodiment, program 104 synchronizes replicated data within each data container to reduce latency interacting with identified replicated data based on calculated interaction time priorities, where higher calculated interaction times are prioritized over lower calculated interaction times.

[0016] Network 106 can be a local area network ("LAN"), a wide area network ("WAN"), such as the Internet, or a combination of the two, and it may include wired, wireless, or fiber optic connections. In general, network 106 can be any combination of connections and protocols that support communication between computing device 102 and server computing device 108, particularly program 104, in accordance with a desired embodiment of the present invention.

[0017] The server computing device 108 may include the program 104 and may communicate with the computing device 102 over a network. The server computing device 108 may be a single computing device, a laptop, a collection of servers, and other well-known computing devices. In this embodiment, the server computing device 108 may be an external device connected to the computing device 102 over the network 106.

[0018] FIG. 2 is a flowchart 200 illustrating operational steps for dynamically generating a consistency mechanism for container orchestration, in accordance with at least one embodiment of the present invention.

[0019] In step 202, program 104 accesses a database. In this embodiment, program 104 receives opt-in / opt-out permission from a user to gain access to the database. In this embodiment, program 104 accesses a database that may be defined as a volume manager. For example, program 104 accesses a volume manager database that stores data catalogs for multiple users.

[0020] In step 204, program 104 packages legacy processes into a stateful set. In this embodiment, legacy processes are outdated or outdated processes that may be unstable due to compatibility issues with current operating systems, browsers, and information technology infrastructure. In this embodiment, the stateful set manages the deployment and scaling of data containers and provides the ordering and details associated with each data container within the stateful set. Furthermore, stateful is defined as a stable (e.g., unchanging) and ordered program that tracks the state of its interactions by setting values ​​in storage fields designated for this purpose. In this embodiment, program 104 distributes data into the stateful set by extracting process binaries from the accessed database and converting the extracted process binaries into data containers. In this embodiment, a process binary is defined as the output of a random event with two inclusive and mutually exclusive outcomes. For example, program 104 distributes data from a database into three identical stateful sets. In other embodiments, the program 104 distributes data from the database into multiple stateful sets and converts the stateful sets into data containers, and the data in the volume manager database is replicated and stored in the stateful sets within the orchestrator or computing device 102.

[0021] In another embodiment, in response to converting a stateful set to a data container, program 104 mounts a volume to the data container by replicating the data in a volume manager database without alerting other stateful sets to the replication. This is because when a stateful set defined as a legacy process learns of data replication, the data stored in that stateful set becomes stale in response to the stateful set being alerted to the data replication. In this embodiment, the volume manager database is defined as a directory with data accessible to all data containers operating in the stateful set, and mounting a volume is defined as storing replicated data within computing device 102.

[0022] In step 206, program 104 monitors the stateful sets. In this embodiment, program 104 monitors changes to replicated data among legacy processes that maintain stateful sets with replicated data and locking mechanisms for replicated data. In this embodiment, program 104 monitors the orchestrated replication of data in the stateful sets by dispatching inputs of access patterns associated with each stateful set and synchronizing the replicated data across the stateful sets. For example, program 104 observes that replicated data was accessed in a first stateful set, that replicated data was not accessed in a second stateful set, and that data was not allowed to be replicated in a third stateful set due to a locking mechanism.

[0023] In this embodiment, program 104 monitors stateful sets of single process applications by freezing data storage containers within the stateful set if program 104 detects a conflict or duplication and allows updates to be performed one data storage container at a time. In this embodiment, a conflict is defined as immediate access to identical duplicate data on respective volumes for each stateful set.

[0024] In another embodiment, program 104 monitors the stateful sets of a multi-process application for conflicts and duplication by monitoring access to lock files. In this embodiment, the replication data in the stateful sets for a multi-process application is used to inform subsequent operations or sessions of impending conflicts and scheduling steps for synchronization without alerting other stateful sets of conflicts or duplications.

[0025] In step 208, program 104 discovers control paths for the request type between stateful sets. In this embodiment, program 104 discovers control paths for the request type between stateful sets by using a runtime analysis of the process to determine the logical distance between control blocks and replicated data within the stateful sets (e.g., the distance between bit string representations of particular elements), and these control paths access a subset of the replicated data in the volume manager database. In this embodiment, when a data duplication or conflict alerts a stateful set, program 104 makes the replicated data stale in response to accessing at least one stateful set that stores replicated data within a single-process application. In this embodiment, in the absence of a locking mechanism within the stateful set, program 104 does not make the replicated data stale in response to accessing at least one stateful set within a multi-process application due to other stateful sets not being alerted.

[0026] In another embodiment, program 104 discovers control paths for request types between stateful sets by performing sandbox execution for the input request type and identifying the control path. In this embodiment, sandbox execution provides an additional layer of security, isolating applications from critical system resources and other programs and preventing malicious applications from negatively impacting a stateful set. In this embodiment, program 104 performs sandbox execution to prevent negative impacts on multiple stateful sets. In this embodiment, program 104 discovers control paths from control blocks, where control blocks are considered data structures used to store information about synchronized processes and are further known as data containers located within a stateful set and as data-replicated storage units located within the stateful set. In this embodiment, a control block is defined as a data structure used by a computer operating system to store all information about a process. In an example where there are five stateful sets, program 104 can map paths from each of the stateful sets to the others. For example, program 104 maps a path from control block ("CB") 1 to CB2 and CB3, while also mapping a different path to data replica ("DR") 1:1 associated with CB2 and DR2:2 associated with CB3. Further, program 104 maps a path from CB3 to CB4 and CB5, while also mapping a different path to DR3:1 associated with CB4 and DR4:2 associated with CB4. In this embodiment, program 104 discovers control paths for request types to assist in synchronization of stateful sets when replicated data spans multiple stateful sets and accessing a data container that stores replicated data would cause other replicated data to become stale.

[0027] In step 210, the program 104 estimates the volume access probability across the stateful sets. In this embodiment, the program 104 estimates the volume access probability across the separate sets by calculating the volume access probability based on the discovered control paths. In this embodiment, the program 104 estimates the volume access probability across the stateful sets by utilizing the following: (1)T=t access -t sync Regarding Equation 1, "T" is the time it takes for the control path to hit a given replica data in the volume. access "t" for replicated data varies with time, the type of data container, and the location of the replicated data within the data container. sync "T" is a random variable that represents the difference between the access time and the synchronization time. For example, the time it takes to access a stateful set is measured as 4, and the time it takes to synchronize a stateful set is 2. Therefore, "T" is equal to 2 as the difference between the access time and the synchronization time.

[0028] In another embodiment, the program 104 estimates the volume access probability across the stateful set by utilizing:

number

number

[0029] In step 212, program 104 prioritizes the stateful sets based on data replication synchronization. In this embodiment, program 104 prioritizes synchronization based on estimated volume access probabilities and discovers priorities for interleaving opportunities and replication data synchronization. In this embodiment, program 104 may select multiple methods to prioritize the stateful sets. In this embodiment, program 104 prioritizes the stateful sets by prioritizing upcoming lock conflicts and prioritizing requests to replicate data within the stateful sets. In this embodiment, program 104 prioritizes the stateful sets based on upcoming lock conflict events to reduce the latency of lock conflicts for data containers being updated with replicated data. In this embodiment, program 104 indicates that the data container has identified a low probability "Pr" due to the control path already being executed and the presence of lock conflicts requesting replicated data. In this embodiment, low probability is defined as a measurement where "T," the latency measured for a stateful set to be accessed by program 104, is less than or equal to zero. In this embodiment, program 104 further defines this latency as a lull when the stateful set is accessed, which provides a synchronization opportunity for program 104 to synchronize replicated data in data containers stored within the stateful set. For example, program 104 may rank stateful sets that have remained neutral above separate sets that have decreased in volume, and the ranking of the stateful sets may be dynamically adjusted based on the calculated evaluation of the probabilities.

[0030] In this embodiment, program 104 prioritizes the stateful set by prioritizing new requests. In another embodiment, program 104 prioritizes request types with higher probabilities by interleaving replicated data and ordering requests with higher probabilities over replicated data accessed by the control path. In this embodiment, program 104 defines high probability as "T" greater than 0. In this embodiment, program 104 prioritizes the stateful set by prioritizing new requests by utilizing the following:

number

[0031] FIG. 3 illustrates a graph 300 showing a comparison of stateful set accesses versus time, according to one embodiment of the present invention. In this embodiment, graph 300 has a y-axis defined as stateful set accesses and an x-axis as time. In this embodiment, graph 300 illustrates a pause as when stateful set accesses are greater than zero. In this embodiment, a pause provides a synchronization opportunity for program 104 to synchronize replica data within a stateful set. In this embodiment, during at least one pause, program 104 interleaves the stateful set. In this embodiment, program 104 defines interleaving as the synchronization process between stale data and up-to-date data. In this embodiment, program 104 identifies a stateful set access pattern for the discovered control path within the pause based on the determined distance between the requested control block and the data replica associated with the requested control block.

[0032] Figure 4 illustrates a block diagram of computing system components within computing environment 100 of Figure 1, in accordance with one embodiment of the present invention. It is understood that Figure 4 provides only one example of one implementation and is not intended to imply any limitations with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

[0033] The programs described herein are identified based on the application in which they are implemented in a particular embodiment of the invention. However, it should be recognized that the naming of any particular programs herein is used merely for convenience, and thus the invention should not be limited to use only in any particular application identified and / or implied by such naming.

[0034] Computer system 400 includes a communications fabric 402 that provides communications between cache 416, memory 406, persistent storage 408, communications unit 412, and input / output (I / O) interface 414. Communications fabric 402 may be implemented by any architecture designed to communicate data and / or control information between processors (e.g., microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components in the system. For example, communications fabric 402 may be implemented by one or more buses or crossbar switches.

[0035] Memory 406 and persistent storage 408 are computer-readable storage media. In this embodiment, memory 406 includes random access memory (RAM). Generally, memory 406 may include any suitable volatile or non-volatile computer-readable storage medium. Cache 416 is high-speed memory that enhances the performance of computer processor 404 by retaining recently accessed and nearby accessed data from memory 406.

[0036] The program 104 may be stored in persistent storage 408 and in memory 406 for execution by one or more of the respective computer processors 404 via cache 416. In one embodiment, persistent storage 408 includes a magnetic hard disk drive. Alternatively, or in addition to a magnetic hard disk drive, persistent storage 408 may include a solid-state hard drive, a semiconductor memory device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0037] The media used by persistent storage 408 may be removable. For example, a removable hard drive may be used for persistent storage 408. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive to transfer data onto other computer-readable storage media that are also part of persistent storage 408.

[0038] In these examples, communications unit 412 provides for communication with other data processing systems or devices. In these examples, communications unit 412 includes one or more network interface cards. Communications unit 412 may provide communications through one or both physical and wireless communications links. Program 104 may be downloaded to persistent storage 408 through communications unit 412.

[0039] The I / O interface 414 allows for input and output of data to and from other devices that may be connected to the mobile device, authorization device, and / or server computing device 108. For example, the I / O interface 414 may provide a connection to an external device 420, such as a keyboard, keypad, touch screen, or some other suitable input device or combination thereof. The external device 420 may also include portable computer-readable storage media, such as thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to implement embodiments of the present invention, such as the program 104, may be stored on such portable computer-readable storage media and loaded into the persistent storage 408 via the I / O interface 414. The I / O interface 414 also connects to a display 422.

[0040] Display 422 provides a mechanism for displaying data to a user and may be, for example, a computer monitor.

[0041] The present invention may be a system, a method, and / or a computer program product, and may include a computer-readable storage medium having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0042] A computer-readable storage medium may be any tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, without limitation, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as ridge structures in grooves with instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein should not be construed as signals that are themselves ephemeral, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

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

[0044] Computer-readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or conventional procedural programming languages, such as object-oriented programming languages ​​like Smalltalk®, C++, and the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

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

Claims

1. A computer-implemented method executed by a computer, comprising: monitoring changes to volumes and locks created on volumes against replicas of packaged stateful sets, each with its state tracked, using either a single-process application or a multi-process application with advisory locks; Discovering a control path for a received request for a containerized process that accesses at least a subset of the replicas of the packaged stateful set; calculating a volume access probability for one of the discovered control paths based on a difference between a time taken to access a corresponding data replica in the packaged stateful set for that control path and a synchronization time for that data replica; prioritizing volume synchronizations based at least in part on the lock contention and request type at hand; synchronizing the packaged stateful sets according to prioritized volume synchronization; 20. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, further comprising packaging data from the volume manager into the plurality of stateful sets by extracting process binaries from the volume manager and converting the extracted process binaries into a container to obtain at least one of the stateful sets.

3. The monitoring comprises: accessing access pattern information over a predetermined time period associated with each packaged stateful set; replicating said access pattern information within each packaged stateful set; 3. The computer-implemented method of claim 1, comprising:

4. Discovering the control path includes: identifying at least one control block among a plurality of control blocks in the packaged stateful set; identifying at least one replicated data set within the packaged stateful set in response to identifying at least one control block; The computer-implemented method of any one of claims 1 to 3, comprising:

5. The method further comprises discovering the control path by determining a logical distance between the at least one control block in the packaged stateful set and the at least one replicated data set.

5. The computer-implemented method of claim 4.

6. discovering the control path includes performing a sandbox execution for an input request type that prevents a negative impact on the plurality of stateful sets. The computer-implemented method of claim 1 .

7. A computer program comprising: monitoring changes to volumes and locks created on volumes against replicas of packaged stateful sets, each with its state tracked, using either a single-process application or a multi-process application with advisory locks; Discovering a control path for a received request for a containerized process that accesses at least a subset of the replicas of the packaged stateful set; calculating a volume access probability for one of the discovered control paths based on a difference between a time taken to access a corresponding data replica in the packaged stateful set for that control path and a synchronization time for that data replica; prioritizing volume synchronizations based at least in part on the lock contention and request type at hand; synchronizing the packaged stateful sets according to prioritized volume synchronization; A computer program that executes the following:

8. The computer, packaging data from the volume manager into the plurality of stateful sets by extracting process binaries from a volume manager and converting the extracted process binaries into a container to obtain at least one stateful set of the stateful sets; 8. A computer program product according to claim 7.

9. The monitoring comprises: accessing pattern information over a predetermined time period associated with each packaged stateful set; replicating the accessed pattern information in each packaged stateful set; 9. A computer program according to claim 7 or 8, comprising:

10. Discovering the control path includes: identifying at least one control block among a plurality of control blocks in the packaged stateful set; identifying at least one replicated data set within said packaged stateful set in response to program instructions for identifying at least one control block; Equipped with A computer program according to any one of claims 7 to 9.

11. 11. The computer program product of claim 10, further causing the computer to discover the control path by determining a logical distance between the at least one control block in the packaged stateful set and the at least one replicated data set.

12. discovering the control path includes performing a sandbox execution for an input request type that prevents a negative impact on the plurality of stateful sets.

8. A computer program product according to claim 7.

13. 1. A computer system comprising: one or more computer processors; one or more computer-readable storage media; program instructions stored on the one or more computer-readable storage media for execution by at least one of the one or more processors; wherein the program instructions include: program instructions for monitoring changes to volumes and locks created on volumes against replicas of packaged stateful sets, each of which has its state tracked, using either a single-process application or a multi-process application with advisory locks; program instructions for discovering a control path for a received request for a containerized process that accesses at least a subset of the replicas of the packaged stateful set; program instructions for calculating a volume access probability for one of the discovered control paths based on a difference between a time taken to access a corresponding data replica in the packaged stateful set for that control path and a synchronization time for that data replica; program instructions for prioritizing volume synchronizations based at least in part on immediate lock contention and request type; program instructions for synchronizing the packaged stateful sets according to prioritized volume synchronization; A computer system comprising:

Images