Determining silence timeout for containerized workloads
By calculating silent timeouts and storage unit specifications for containerized workloads, we address the I/O overflow issue in container orchestration systems and improve the reliability and efficiency of backup operations.
Patent Information
- Application Number
- CN202480012146.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-14
- Filing Date
- 2024-01-03
- Publication Date
- 2025-09-19
AI Technical Summary
In the existing technology, container orchestration systems lack intelligent allocation of storage units when performing backup operations on containerized workloads, resulting in frequent I/O overflows during snapshot quiescing, affecting the reliability and efficiency of backup operations.
By determining the quiescence timeout of the containerized workload, the appropriate storage unit specification is calculated based on the I/O rate and the amount of memory required to buffer the data, and the containerized workload is mapped to a storage unit that can complete the backup operation within the quiescence timeout.
Improves the reliability of backup operations, reduces the occurrence of I/O overflow, optimizes the allocation of storage units to containerized workloads, and enhances the backup reliability of the file system.
Smart Images

Figure CN120677467A_ABST
Abstract
Description
Background Art
[0001] The present disclosure relates to container orchestration, and more particularly, to mapping containerized workloads to storage units.
[0002] Containers are a method for building, packaging, and deploying software. In the simplest terms, a container includes both application code and the dependencies that application code needs to run correctly. Multiple containers (also called containerized workloads or containerized applications) can run on the same machine and share the operating system (OS) kernel with other containers, with each container running as an isolated process in user space. Container orchestration is the automation of the operational tasks required to run containerized workloads or applications and services. These operational tasks include managing the container lifecycle, such as container provisioning, deployment, scaling (increasing and decreasing), networking, and load balancing. Summary of the Invention
[0003] Aspects of the present disclosure relate to a computer-implemented method that includes determining an input / output (I / O) rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to store data. Aspects of the present disclosure also include determining a quiesce timeout for the containerized workload, the quiesce timeout being based at least in part on the I / O rate of data associated with the containerized workload and an amount of memory allocated to buffer data without causing I / O overflow during execution of a backup operation. Aspects of the present disclosure also include determining a storage unit specification that supports execution of the backup operation within the quiesce timeout, and evaluating storage units available to the container environment based on the storage unit specification to identify a storage unit for the containerized workload.
[0004] Additional aspects of the present disclosure relate to systems and computer program products configured to perform the above-described methods.This summary is not intended to illustrate every aspect, every implementation, and / or every embodiment of every embodiment of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The accompanying drawings included in this application are incorporated into and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the specification, are used to explain the principles of the present disclosure. The accompanying drawings are only illustrative of certain embodiments and are not intended to limit the present disclosure.
[0006] Figure 1 is a block diagram illustrating an example container orchestration system according to some embodiments of the present disclosure.
[0007] Figure 2 is a diagram illustrating a hypothetical scenario for mapping a containerized workload to storage units based in part on an estimated quiesce timeout for the containerized workload, according to some embodiments of the present disclosure.
[0008] Figure 3 is a flow chart illustrating an example method for managing storage unit allocation based on a quiesce timeout for a containerized workload, according to some embodiments of the present disclosure.
[0009] Figure 4 is a flow chart illustrating an example method for determining a quiesce timeout for a containerized workload, the quiesce timeout being used to identify a storage unit for the containerized workload, according to some embodiments of the present disclosure.
[0010] Figure 5 is a block diagram illustrating an example computing environment in which aspects of the disclosure can be implemented according to some embodiments of the disclosure.
[0011] Although the present disclosure is susceptible to various modifications and alternative forms, details thereof have been shown by way of example in the drawings and will be described in detail. However, it should be understood that it is not intended to limit the present disclosure to the particular embodiments described. On the contrary, the present disclosure is intended to cover all modifications, equivalents, and alternatives that fall within the scope of the present disclosure. DETAILED DESCRIPTION
[0012] Various aspects of the present disclosure relate to determining a quiesce timeout for a containerized workload that allows a backup operation to successfully complete, and mapping the containerized workload to a storage unit based at least in part on the quiesce timeout. While not limited to these applications, embodiments of the present disclosure may be better understood in light of the foregoing context.
[0013] Container orchestration automates the deployment, management, scaling, and networking of containerized workloads. Containerization is the packaging of software code with operating system (OS) libraries and the dependencies required to execute the software code, creating a single lightweight executable file, referred to herein as a containerized workload, that executes consistently on a general-purpose computing platform.
[0014] Containerized workloads have complex management specifications that become even more complex when scaled. To manage this complexity, container orchestration systems include data stores and file systems that provide a consistent source of truth about the state of containerized workloads at any given point in time. For example, in the context of the Kubernetes container orchestration system, etcd is an open source distributed key-value store that is used to persist and manage critical information required for correct execution, such as configuration data, state data, and metadata for containerized workloads managed by the container orchestration system.
[0015] Periodically performing backups of the file systems used by containerized workloads is important for recovering containerized workloads in the event of a disaster. A backup of a file system can be created to save the file system's contents at a single point in time. The backup contains the state of the containerized workload and other critical information. Backup operations (e.g., snapshot creation and / or deletion) provide online backup capabilities that allow recovery from common problems, such as accidental file deletion and comparison with older versions of files.
[0016] Performing a backup operation requires briefly interrupting access to the file system. This interruption allows the backup process to obtain a consistent point-in-time image of the file system and to update various internal databases with the backup information. The mechanism used to interrupt access to the file system is called quiescing. While the execution of the backup operation may only take a few seconds, the process of reaching the quiesced state may take much longer due to the operations required to achieve the quiesced state. As an illustration, a snapshot is quiesced by sending a remote procedure call (RPC) from the backup process to all nodes (virtual or physical computers) where the file system is mounted. On each node, the RPC handler blocks new file system operations from starting and waits for currently executing file system operations to complete. The backup process also blocks daemon threads (e.g., housekeeping threads) that access the file system from executing. The backup process then performs the snapshot operation. Thereafter, the backup process sends a resume RPC to the nodes, instructing them to allow file system operations and daemon threads to return to normal operation. The time it takes to reach the quiesced state, perform one or more snapshot operations, and return to normal operation is the snapshot quiescing period.
[0017] The snapshot quiescing process described above is problematic in high-frequency containerized workload environments when snapshots are created and deleted frequently. This is because the container orchestration system does not know whether the storage units (units of processing and memory) allocated to the containerized workload are sufficient to buffer the input / output (I / O) of the containerized workload during the snapshot quiescing period. Failure to buffer I / O during the snapshot quiescing period can cause the snapshot operation to fail and result in loss of I / O data for the containerized workload. The lack of intelligence in the container orchestration system can lead to non-optimal scheduling of containerized workloads and create problems in terms of snapshot failures, backup failures, application downtime, and storage resource inefficiency.
[0018] Advantageously, aspects of the present disclosure overcome these challenges by determining a quiesce timeout for individual containerized workloads that allows storage backup operations to be performed without causing I / O overflow, and mapping the individual containerized workloads to storage units based at least in part on the quiesce timeout. More specifically, aspects of the present disclosure determine an I / O rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to perform storage operations. Aspects of the present disclosure then determine a quiesce timeout for the containerized workload, wherein the quiesce timeout is based at least in part on the I / O rate and the amount of memory required to buffer I / O associated with the containerized workload during the execution of the backup operation without causing I / O overflow. Aspects of the present disclosure then determine a storage unit specification that supports the execution of the backup operation within the quiesce timeout. Aspects of the present disclosure then evaluate the storage units available to the container environment to identify a storage unit for the containerized workload based on the storage unit specification. Aspects of the present disclosure can then allocate storage units to the containerized workload, thereby providing the containerized workload with a sufficient amount of computing resources (processing and memory) to support the execution of backup operations without experiencing I / O overflow. Accordingly, aspects of the present disclosure provide improvements to computer-related technologies by optimizing the allocation of storage units to the containerized workload using a quiesce timeout calculated for the containerized workload, thereby increasing the backup reliability of the associated file system by reducing the number of backup failures.
[0019] Referring now to the accompanying drawings, Figure 1 A block diagram of an example container environment 100 including a container orchestration system 120 according to some embodiments of the present disclosure is illustrated, which is configured to determine a quiet timeout for containerized workloads 112A, 112N (collectively referred to as 112, where N can refer to any positive integer representing any number of containerized workloads) and match the containerized workloads 112 to storage units 114A, 114N (collectively referred to as 114, where N can refer to any positive integer representing any number of storage units) based on the quiet timeout. As shown, the container orchestration system 120 is in network communication with multiple nodes 110A, 110N (collectively referred to as 110, where N can refer to any positive integer representing any number of nodes). Node 110 includes a virtual or physical machine that hosts one or more containerized workloads 112. The container orchestration system 120 manages various aspects of the container environment 100, including automated container deployment, scaling, and management.
[0020] The control plane 102 of the container orchestration system 120 includes a collection of modules (processes) for managing various aspects of the containerized workload lifecycle. As will be understood, the modules may include a storage mapping module 104, a container storage interface module 106, a quiet timeout module 108, and other modules.
[0021] The storage mapping module 104 of the control plane 102 maps (e.g., assigns) the containerized workload 112 to the storage unit 114. Typically, the storage mapping module 104 selects the storage unit 114 for a newly created or not yet scheduled (unscheduled) containerized workload 112. Because the containerized workloads 112 can have different requirements, the storage mapping module 104 identifies the storage unit 114 that is specific to the requirements of the containerized workload. When the containerized workload 112 is scheduled, the storage mapping module 104 can assign the storage unit 114 to the containerized workload 112 that corresponds to the quiesce timeout calculated for the containerized workload 112. In some embodiments, as described later in conjunction with Figure 3 As described, before performing a backup operation (e.g., a snapshot operation), the storage mapping module 104 can determine whether the storage unit 114 currently assigned to the containerized workload 112 corresponds to the silent timeout of the containerized workload 112, and perform one or more remedial actions when the currently assigned storage unit 114 does not correspond to the silent timeout.
[0022] Storage units 114 include heterogeneous data storage devices and systems that can be allocated to containerized workloads 112 managed by containerization orchestration system 120. Storage units 114 host file systems that store data associated with processes executed by containerized workloads 112. Storage units 114 include persistent storage devices that can be mounted to containers (e.g., containers) that include containerized workloads 112. Storage units 114 can be heterogeneous and can include various storage systems and devices, including cloud-based storage (e.g., storage provided by a storage service provider). The computing resources (e.g., processing, memory, storage, and software) used to implement storage units 114 vary, enabling some storage units 114 to perform storage operations and storage-related operations faster than other storage units 114. For example, a first storage unit 114A can be implemented using computing resources that enable a snapshot operation to be executed within a ten-second time period, while a second storage unit 114N can be implemented using computing resources that enable the same snapshot operation to be executed within a five-second time period. The ability of the storage unit 114 to perform a backup operation within the quiesce timeout of the containerized workload 112 depends, at least in part, on the computing resource specifications of the storage unit 114 .
[0023] Therefore, as part of mapping the storage units 114 to the containerized workloads 112, the storage mapping module 104 identifies the storage units 114 that correspond to the quiesce timeouts of the containerized workloads 112 and schedules the containerized workloads 112 to be assigned to the storage units 114. As an example, the storage mapping module 104 obtains (or requests) the quiesce timeouts from the quiesce timeout module 108, which is configured to determine the quiesce timeouts for the respective containerized workloads 112, as described below. Based on the quiesce timeouts of the containerized workloads 112, the storage mapping module 104 identifies storage unit specifications (e.g., read / write speeds, buffer flush rates, etc.) that enable the backup operation to be performed by the storage unit 114 within the quiesce timeouts of the containerized workloads 112. The storage mapping module 104 uses the storage unit specifications to identify storage units 114 that are available for assignment to the containerized workloads 112. For example, the storage mapping module 104 may query one or more container storage interface modules 106 for storage units 114 that meet the storage unit specifications. After identifying the storage unit 114 corresponding to the storage unit specification, the storage mapping module 104 schedules the containerized workload 112 to be assigned to the storage unit 114 .
[0024] The quiesce timeout module 108 calculates an estimated quiesce timeout for a containerized workload 112 managed by the container orchestration system 120. The quiesce timeout calculated by the quiesce timeout module 108 for the containerized workload 112 is provided to the storage mapping module 104 to allow identification of storage units 114 that can perform a backup operation within the quiesce timeout of the containerized workload 112. The quiesce timeout for the containerized workload 112 is the amount of time during which a backup operation associated with a file system used by the containerized workload 112 (e.g., a snapshot operation) can be performed without causing an I / O overflow (e.g., an overflow of buffered I / O data associated with the containerized workload 112). The quiesce timeout may include the time to reach the quiesce state and the time to perform the backup operation. An I / O overflow occurs when the containerized workload 112 attempts to write more I / O data to the allocated memory than the memory can hold. Because I / O data held in memory cannot be written to the file system while in the quiesced state, attempting to write more I / O data to memory than the memory buffer can hold may result in I / O data loss, failed backup operations, application downtime, etc.
[0025] The quiesce timeout module 108 calculates the quiesce timeout for the containerized workload 112 by determining a time to quiesce the file system utilized by the containerized workload 112, determining an I / O buffer size for storing I / O data associated with the containerized workload 112 during the execution of the backup operation, and determining an I / O rate associated with the containerized workload 112. Based on the time to quiesce the file system, the I / O buffer size, and the I / O rate, the quiesce timeout module 108 calculates an amount of time that the I / O data associated with the containerized workload 112 can be buffered without causing an I / O overflow. This amount of time comprises the quiesce timeout for the particular containerized workload 112.
[0026] More specifically, in some embodiments, the quiet timeout module 108 determines the I / O buffer size for the containerized workload 112 by identifying the amount of computing resources (processing, memory, local storage) available for buffering the I / O data of the containerized workload. A specification of computing resources allocated for buffering the I / O data of the containerized workload can be obtained via the control plane 102 of the container orchestration system 120, and the computing resource specification indicates the amount of node 110 resources (processing, memory, local storage) allocated for buffering the containerized workload I / O data. Illustratively, when the containerized workload 112 is scheduled (allocated) to the node 110, the container orchestration system 120 allocates the node 110 computing resources to the containerized workload 112. For example, In the context of a container orchestration system, the quiet timeout module 108 can obtain the computing resource specification from a node object (node representation) associated with the node 110 hosting the containerized workload 112 .
[0027] In conjunction with determining the I / O buffer size available for the containerized workload 112, the quiesce timeout module 108 obtains the I / O rate of the containerized workload 112. In some embodiments, the quiesce timeout module 108 analyzes historical workload data 118 associated with the containerized workload 112 to estimate the I / O rate. The I / O rate can be based on historical I / O performance metrics (e.g., I / O operations per second, bandwidth, response time, etc.). Alternatively, in some embodiments, when historical workload data 118 is not available for the containerized workload 112, the quiesce timeout module 108 attempts to identify historical workload data 118 associated with one or more similar containerized workloads (containerized workloads with specifications similar to the specific containerized workload 112). If historical workload data 118 for one or more similar containerized workloads is identified, the quiesce timeout module 108 analyzes the historical workload data 118 to estimate the I / O rate, which can be used as part of determining the quiesce timeout for the individual containerized workload 112.
[0028] In cases where historical workload data 118 may not be available for the containerized workload 112 (e.g., a particular application), in some embodiments, the quiesce timeout module 108 determines the I / O rate of the containerized workload 112 by monitoring I / O operations associated with the containerized workload 112. For example, In the context of a container orchestration system, Kubelet (node agent) reports the resource usage of a pod as part of the pod state. The silent timeout module 108 can analyze the resource usage reported by Kubelet to determine the I / O rate of the pod.
[0029] In some embodiments, both the historical I / O rate and the current I / O rate may be used to calculate the quiesce timeout for the containerized workload 112. Illustratively, the quiesce timeout module 108 obtains the historical I / O rate from the historical workload data 118 and obtains the current I / O rate by monitoring I / O operations associated with the containerized workload 112. The quiesce timeout module 108 then evaluates (compares) the historical I / O rate and the current I / O rate to estimate the I / O rate for use in calculating the quiesce timeout for the containerized workload 112.
[0030] As described above, in some embodiments, the quiesce timeout module 108 determines an estimated time to quiesce a file system used by the containerized workload 112. The estimated quiesce time is the time required for the file system to reach a quiesced state, in which storage operations associated with the file system are blocked, paused, or aborted. Illustratively, quiescing a file system includes the process of placing on-disk data of a physical or virtual storage system in a state suitable for backup. This process may include operations such as flushing dirty memory buffers from the operating system's in-memory cache to the storage disk or other higher-level application-specific tasks, as well as preventing new storage operations from starting, waiting for currently executing storage operations to complete, and / or suspending certain storage-related processes (including housekeeping).
[0031] In some embodiments, determining the estimated time to reach the quiesced state may include estimating the amount of time to flush (copy) I / O data from the node's I / O buffer to persistent storage provided by storage unit 114. The rate at which I / O data can be flushed from the I / O buffer to storage unit 114 may be determined based on the data throughput rates of the components involved (e.g., processor(s), memory, network hardware, etc.). Additionally, in some embodiments, determining the estimated time to reach the quiesced state may include estimating the amount of time to complete pending storage operations associated with containerized workload 112. The time estimate may be based on typical processing times associated with storage operations performed on behalf of containerized workload 112. For example, a containerized workload 112 that processes a large amount of data may be associated with a longer processing time than a containerized workload 112 that processes a small amount of data.
[0032] After collecting the backup-related information described above, the quiesce timeout module 108 calculates a quiesce timeout for the containerized workload 112 based, at least in part, on the backup-related information (the I / O buffer size, the I / O rate, and the estimated file system quiesce time). Illustratively, this calculation may include adding the amount of time it takes for the file system to reach a quiesced state and the amount of time the I / O data of the containerized workload can be buffered at the node 110 before reaching capacity, as determined by the I / O rate. The resulting quiesce timeout indicates the amount of time it takes for a backup operation of the file system to be successfully performed without experiencing a buffer overflow of the containerized workload I / O data. After calculating the quiesce timeout for the containerized workload 112, the quiesce timeout may be used by the storage mapping module 104 to map the containerized workload 112 to a storage unit 114 having a storage unit specification that indicates that the storage unit 114 is capable of performing the backup operation within the quiesce timeout.
[0033] As previously described, the storage mapping module 104 identifies a storage unit 114 that corresponds to the quiesce timeout of the containerized workload 112 and schedules the containerized workload 112 to be assigned to the storage unit 114. In the event that the storage mapping module 104 cannot identify a storage unit 114 with a specification that corresponds to the quiesce timeout of the containerized workload 112, the storage mapping module 104 may allocate additional memory of the node 110 to the containerized workload 112 to support buffering of the containerized workload's I / O during the processing of the backup operation, thereby potentially preventing I / O overflow during the execution of the backup operation.
[0034] In some embodiments, the storage mapping module 104 can evaluate the current allocation of storage units 114 to the containerized workload 112 to determine whether the specifications of the storage units 114 correspond to the quiesce timeout calculated for the containerized workload 112. In some embodiments, the evaluation can be performed in response to a backup operation error associated with the containerized workload 112. If the storage unit specifications do not allow the backup operation to be performed within the quiesce timeout, the storage mapping module 104 identifies an alternative storage unit 114 that is capable of performing the backup operation within the quiesce timeout and migrates the containerized workload 112 to the alternative storage unit 114. For example, the storage mapping module 104 can determine that the currently allocated storage unit 114 does not have sufficient computing resources to enable the backup operation to successfully complete within the quiesce timeout and migrate the containerized workload 112 to another storage unit 114 identified as capable of performing the backup operation within the quiesce timeout.
[0035] Figure 1 A network 116 is shown provided to support communication between components of the container environment 100. The network 116 may include any useful computing network, including an intranet, the Internet, a local area network, a wide area network, a wireless data network, or any other such network or combination thereof. The components used for the network 116 may depend, at least in part, on the type of network and / or environment selected. Communication over the network 116 may be accomplished via wired or wireless connections, or combinations thereof.
[0036] In this illustrative example, container environment 100 includes components that may be implemented in hardware, such as Figure 5The hardware shown in computing environment 100 in FIG. 1 , for example, container orchestration system 120 can be implemented in software, hardware, firmware, or a combination thereof. When software is used, the operations performed by container orchestration system 120 can be implemented in program instructions configured to run on hardware such as a processor unit. When firmware is used, the operations performed by container orchestration system 120 can be implemented in program instructions and data and stored in persistent storage to run on a processor unit. When hardware is used, the hardware may include circuitry that operates to perform the operations of container orchestration system 120.
[0037] In addition, the hardware can take the form of at least one selected from a circuit system, an integrated circuit, an application specific integrated circuit (ASIC), a programmable logic device, or some other suitable type of hardware configured to perform a plurality of operations. Using a programmable logic device, the device can be configured to perform the plurality of operations. The device can be reconfigured at a later time, or can be permanently configured to perform the plurality of operations. Programmable logic devices include, for example, programmable logic arrays, programmable array logic, field programmable logic arrays, field programmable gate arrays, and other suitable hardware devices.
[0038] As used herein, a processor is a hardware device and includes hardware circuits such as integrated circuits that respond to and process instructions and program instructions to operate a computer. Figure 5 The processor is implemented by the processor group 510 in the container environment 100. The processor can be one or more processor units on the same computer or different computers. That is, the process can be distributed between processor units on the same or different computers in the container environment 100. In addition, the number of processor units can be processor units of the same type or different types. For example, the number of processor units can be selected from at least one of a single-core processor, a dual-core processor, multiple processor cores, a general-purpose central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), or some other type of processor unit.
[0039] In some embodiments, combined Figure 1 The modules described can be implemented as computing services hosted in a computing service environment. For example, a module can be considered a service with one or more processes executing on a server or other computer hardware. Such a service can provide a service application that receives requests and provides output to other services or consumer devices. An API can be provided for each module to enable a first module to send requests to a second module and receive output from the second module. Such an API can also allow third parties to interface with the module and make requests and receive output from the module.
[0040] Although Figure 1An example of a container environment is shown in which the above-described techniques may be implemented, but many other similar or different environments are possible. Figure 1 The illustration of a container environment in the illustrative embodiments is not meant to imply physical or architectural limitations to the manner in which the illustrative embodiments may be implemented. Other components may be used in addition to or in place of the components shown. Some components may not be necessary. Furthermore, these blocks are presented to illustrate some functional components. When implemented in the illustrative embodiments, one or more of these blocks may be combined, divided, or combined and then divided into different blocks.
[0041] Figure 2 is a diagram illustrating a hypothetical scenario for mapping containerized workloads 202A, 202B, 202N (collectively 202, where N may refer to any positive integer representing any number of containerized workloads) to storage units 206A, 206B, 206N (collectively 206, where N may refer to any positive integer representing any number of storage units) based in part on an estimated quiet timeout calculated for the containerized workload 202, in accordance with some embodiments of the present disclosure.
[0042] In a first hypothetical scenario, containerized workload 202A is currently assigned (mounted) to storage unit 206A, which has computing resources capable of performing a backup of the file system used by containerized workload 202A within 15 seconds. Container orchestration system 204 determines that the quiesce timeout for containerized workload 202A is approximately 10 seconds (based on the input I / O rate and memory buffer size), which is insufficient time for storage unit 206A to reliably perform the backup operation. In response, before performing the file system backup, container orchestration system 204 migrates containerized workload 202A to storage unit 206N, which has computing resources capable of reliably performing the backup operation within 5 seconds, which corresponds to the quiesce timeout because the backup can be performed without incurring I / O overflow. The migration of containerized workload 202A includes copying data associated with containerized workload 202A stored on storage unit 206A to storage unit 206N, and pointing (mounting) containerized workload 202A to storage unit 206N.
[0043] In a second hypothetical scenario, containerized workload 202B is currently assigned to storage unit 206B, which is capable of performing a backup operation within twenty seconds. In response to determining that the quiesce timeout for containerized workload 202B is approximately eighteen seconds (which is less than the time required for storage unit 206B to reliably perform a backup), containerized workload 202B is migrated to storage unit 206A (which is capable of performing a backup operation within fifteen seconds) before performing a backup of the file system to ensure that the backup is successful.
[0044] In a third hypothetical scenario, containerized workload 202N is currently assigned to storage unit 206N, which is capable of performing a backup operation within five seconds. Container orchestration system 204 determines that the quiesce timeout for containerized workload 202N is approximately ten seconds. Because the time it takes for storage unit 206N to perform the backup is significantly less than the time required to satisfy the quiesce time for containerized workload 202N and balance the storage load of containerized workload 202 across storage units 206, container orchestration system 204 migrates containerized workload 202N to storage unit 206A, which is capable of performing the backup operation within the quiesce timeout for containerized workload 202N.
[0045] Figure 3 is a flow diagram illustrating an example method 300 for managing storage unit allocation for containerized workloads based on a quiesce timeout in accordance with some embodiments of the present disclosure. In operation 302, the method 300 begins by scheduling a backup operation for a file system utilized by a containerized workload executing in a container environment. As part of scheduling the backup operation, the method 300 determines whether the backup operation can be successfully performed. The success of the backup operation is based in part on whether backups (e.g., snapshots) can be created and / or deleted without incurring I / O overflow associated with one or more containerized workloads that utilize the file system. To help determine whether the backup operation can be successfully performed, the method 300 calculates a quiesce timeout for each containerized workload that utilizes the file system and evaluates the storage units allocated to the containerized workloads to determine whether the specifications of the storage units correspond to the quiesce timeouts for the containerized workloads.
[0046] More specifically, in operation 304, the method 300 determines historical data ( Figure 1 The historical data may include historical I / O performance metrics associated with the containerized workload. If historical data is available for the containerized workload, then in operation 306, method 300 uses the historical data to determine a quiesce timeout for the containerized workload. For example, the historical data may be used to estimate a current I / O rate for the containerized workload, and the quiesce timeout for the containerized workload may be calculated using the estimated I / O rate and the specification of a memory buffer that may be used to store I / O associated with the containerized workload during execution of the backup operation.
[0047] In the event that historical data is not available for the containerized workload, then in operation 308, method 300 uses the current (e.g., real-time or near real-time) I / O rate associated with the containerized workload and the specification of the memory buffer available for storing I / O associated with the containerized workload during the execution of the backup operation to determine a quiesce timeout for the containerized workload. For example, the current I / O rate can be determined by monitoring I / O operations associated with the containerized workload. The resource usage of the containerized workload can be provided to the container orchestration system by a node agent executing on the node hosting the containerized workload, and method 300 can use the resource usage information to determine the I / O rate of the containerized workload.
[0048] Alternatively, in some embodiments, if historical data is not available for the corresponding containerized workload, the method 300 may attempt to identify historical data associated with one or more similar containerized workloads having specifications similar to those of the corresponding containerized workload. Upon identifying one or more similar containerized workloads, the method 300 analyzes the historical data of the similar containerized workloads to estimate an I / O rate for use in calculating a quiesce timeout for the corresponding containerized workload.
[0049] After determining the quiesce timeout for the containerized workload, in operation 310, the method 300 determines whether the backup operation can be successfully performed based on the quiesce timeout. That is, the method 300 determines whether the storage unit assigned to the containerized workload is able to perform a backup of the file system within the time period indicated by the quiesce timeout. Figure 2 As described above, the determination of whether the storage unit is able to perform the backup within the quiesce timeout may be determined via an evaluation of the storage unit's specifications (eg, read / write speed, buffer flush rate, etc.).
[0050] In the event that it is determined that the backup operation can be successfully performed by the storage unit currently assigned to the containerized workload, the method 300 continues to operation 320 to determine whether there are additional containerized workloads to evaluate. In the event that it is determined that the storage unit cannot successfully perform the backup operation, the method 300 continues to operation 312, which attempts to identify another storage unit that can perform the backup operation. For example, as previously described in connection with Figure 2 As described, various storage units in a container environment may be available for allocation to a containerized workload. Method 300 may evaluate the specifications of the storage units (e.g., read / write speeds, buffer flush rates, etc.) to identify candidate storage units that can perform backup operations within a quiesce timeout of the containerized workload.
[0051] If an alternative storage unit is found in operation 314, then in operation 318, method 300 migrates the containerized workload from the originally assigned storage unit determined to have insufficient computing resources to support backup processing within the quiesce timeout of the containerized workload to the alternative storage unit. Data associated with the containerized workload is copied from the disk storage of the originally assigned storage unit to the disk storage of the alternative storage unit, and the containerized workload is directed to the alternative storage unit. Thereafter, method 300 continues to operation 320 to determine whether there are additional containerized workloads to evaluate.
[0052] Returning again to operation 314, if no alternative storage unit can be found for the containerized workload, then in operation 316, the container orchestration system performs memory scaling to increase the amount of memory allocated to the node for buffering the I / O of the containerized workload. Method 300 then continues to operation 320 to determine whether there are additional containerized workloads to evaluate. After performing the above operations for each containerized workload that utilizes a file system, method 300 continues to operation 322 to allow the backup operation to be scheduled.
[0053] Figure 4 4 is a flow chart illustrating an example method 400 for determining a quiesce timeout for a containerized workload, the quiesce timeout being used to identify storage units for the containerized workload, according to some embodiments of the present disclosure. In some embodiments, the container orchestration system automates the allocation of storage units to support the creation of snapshots within the quiesce timeout for the containerized workload.
[0054] Beginning at operation 402, method 400 determines an I / O rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to store data. In some embodiments, determining the I / O rate for the containerized workload includes obtaining a historical I / O rate for the containerized workload and estimating a current I / O rate for the containerized workload based on the historical I / O rate. In some embodiments, determining the I / O rate associated with the containerized workload includes monitoring current I / O operations associated with the containerized workload to determine the I / O rate.
[0055] In operation 404, method 400 determines a quiesce timeout for the containerized workload, the quiesce timeout being based at least in part on an I / O rate of data associated with the containerized workload and an amount of memory allocated for buffering data without causing I / O overflow during the backup operation. In some embodiments, determining the quiesce timeout includes estimating a time to complete pending file system operations associated with the containerized workload and estimating a time to copy data from the memory allocated for buffering to a persistent storage device (e.g., a storage unit allocated to the containerized workload).
[0056] In operation 406 , the method 400 determines a storage unit specification that supports performing the backup operation within the quiesce timeout, and in operation 408 , the method 400 evaluates storage units available to the container environment based on the storage unit specification to identify a storage unit for the containerized workload.
[0057] In some embodiments, the method 400 migrates the containerized workload to a storage unit corresponding to the storage unit specification. The containerized workload is moved from a storage unit determined to have an original allocation of computing resources insufficient to support the snapshot processing within the quiesce timeout to a storage unit identified as having a storage unit specification with performance to support the backup operation within the quiesce timeout.
[0058] In some embodiments, in response to determining that a storage unit available to the container environment does not correspond to a storage unit specification that supports creation of a snapshot within a quiesce timeout, method 400 allocates additional memory to the containerized workload to support buffering of I / O associated with the containerized workload during backup processing.
[0059] The above method can be performed by a computer (e.g., Figure 5 501 in the cloud environment (e.g., Figure 5 506 or 505), and / or may generally be implemented in fixed function hardware, configurable logic, logic instructions, etc., or any combination thereof.
[0060] In some alternative implementations of the illustrative embodiments, one or more functions noted in the blocks may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functions involved. Furthermore, other blocks may be added in addition to the blocks shown in the flowchart or block diagram.
[0061] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.
[0062] Computer program product embodiments ("CPP embodiments" or "CPPs") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") that are collectively included in a collection of one or more storage devices, which collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, should not be construed as storing in the form of transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at certain occasional points in time during the normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.
[0063] Now refer to Figure 5, computing environment 500 includes an example of an environment for executing at least some of the computer code involved in performing the disclosed methods, such as block 550 including container orchestration code that determines a quiesce timeout for a containerized workload, the quiesce timeout being used to identify a storage unit for the containerized workload. In addition to block 550, computing environment 500 includes, for example, a computer 501, a wide area network (WAN) 502, an end-user device (EUD) 503, a remote server 504, a public cloud 505, and a private cloud 506. In this embodiment, computer 501 includes a processor group 510 (including processing circuitry 520 and cache 521), a communication fabric 511, volatile memory 512, a persistent storage device 513 (including an operating system 522 and block 550, as described above), a peripheral device group 514 (including a user interface (UI), a device group 523, a storage device 524, and an Internet of Things (IoT) sensor group 525), and a network module 515. Remote server 504 includes a remote database 530. The public cloud 505 includes a gateway 540 , a cloud orchestration module 541 , a host physical machine group 542 , a virtual machine group 543 , and a container group 544 .
[0064] Computer 501 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 530. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 500, the detailed discussion focuses on a single computer, particularly computer 501, to keep the presentation as simple as possible. Computer 501 may be located in the cloud, even though Figure 5 5. While not shown in the cloud, computer 501 need not be located in the cloud except to any extent that can be positively indicated.
[0065] Processor group 510 includes one or more computer processors of any type now known or developed in the future. Processing circuitry 520 can be distributed across multiple packages, such as multiple cooperating integrated circuit chips. Processing circuitry 520 can implement multiple processor threads and / or multiple processor cores. Cache 521 is a memory located in the (multiple) processor chip package and is typically used for data or code that should be quickly accessed by threads or cores running on processor group 510. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuitry. Alternatively, some or all of the processor group's caches may be located "off-chip." In some computing environments, processor group 510 may be designed to work with qubits and perform quantum computing.
[0066] Computer-readable program instructions are typically loaded onto the computer 501 to cause a series of operating steps to be executed by the processor group 510 of the computer 501, thereby implementing the computer-implemented method, such that the instructions so executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as the "disclosed method"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 521 and other storage media discussed below. The computer-readable program instructions and related data are accessed by the processor group 510 to control and direct the execution of the disclosed method. In the computing environment 500, at block 550, at least some of the instructions for executing the disclosed method may be stored in a persistent storage device 513.
[0067] Communications fabric 511 is the signal conduction path that allows the various components of computer 501 to communicate with each other. Typically, the fabric is composed of switches and conductive paths, such as those that constitute a bus, a bridge, physical input / output ports, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.
[0068] Volatile memory 512 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, but this is not required unless explicitly stated. In computer 501, volatile memory 512 is located in a single package and is internal to computer 501, but, alternatively or additionally, the volatile memory can be distributed across multiple packages and / or located externally relative to computer 501.
[0069] Persistent storage 513 is any form of non-volatile storage for computers, now known or developed in the future. The non-volatility of the memory means that the stored data is retained regardless of whether power is supplied to the computer 501 and / or directly to the persistent storage 513. Persistent storage 513 may be a read-only memory (ROM), but typically at least a portion of the persistent storage allows writing, deleting, and rewriting of data. Some common forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 522 may take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type that employ a kernel. The code included in block 550 typically includes at least some of the computer code involved in executing the disclosed method.
[0070] Peripheral device group 514 includes the peripheral device group of computer 501. The data communication connection between the peripheral devices and other components of computer 501 can be implemented in various ways, such as Bluetooth connection, near field communication (NFC) connection, connection made by cable (such as universal serial bus (USB) type cable), plug-in connection (for example, secure digital (SD) card), connection made by local area communication network, and even connection made by wide area network such as the Internet. In various embodiments, UI device group 523 can include components such as display screen, speaker, microphone, wearable device (such as goggles and smart watch), keyboard, mouse, printer, touchpad, game controller and tactile device. Storage device 524 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. Storage device 524 can be persistent and / or volatile. In some embodiments, storage 524 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where computer 501 requires a large amount of storage (e.g., where computer 501 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor group 525 is comprised of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.
[0071] The network module 515 is a collection of computer software, hardware, and firmware that allows the computer 501 to communicate with other computers via the WAN 502. The network module 515 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 515 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control function and the forwarding function of the network module 515 are executed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for executing the disclosed methods can typically be downloaded to the computer 501 from an external computer or external storage device via a network adapter card or network interface included in the network module 515.
[0072] WAN 502 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology now known or later developed for transmitting computer data. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN), which is designed to transmit data between devices located in a local area, such as a Wi-Fi network. A WAN and / or LAN typically includes computer hardware, such as copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.
[0073] End-user device (EUD) 503 is any computer system used and controlled by an end-user (e.g., a customer of the business operating computer 501), and can take any of the forms discussed above in connection with computer 501. EUD 503 typically receives helpful and useful data from the operation of computer 501. For example, in the hypothetical scenario where computer 501 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 515 of computer 501 to EUD 503 via WAN 502. In this manner, EUD 503 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 503 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, or the like.
[0074] Remote server 504 is any computer system that provides at least some data and / or functionality to computer 501. Remote server 504 may be controlled and used by the same entity that operates computer 501. Remote server 504 represents a machine(s) that collects and stores helpful and useful data for use by other computers, such as computer 501. For example, if computer 501 is designed and programmed to provide recommendations based on historical data, then this historical data may be provided to computer 501 from remote database 530 of remote server 504.
[0075] Public cloud 505 is any computer system that can be used by multiple entities and provides on-demand availability of computer system resources and / or other computer capabilities (particularly data storage (cloud storage) and computing power) without requiring direct, active management by users. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct and active management of the computing resources of public cloud 505 is performed by computer hardware and / or software of cloud orchestration module 541. The computing resources provided by public cloud 505 are typically implemented as virtual computing environments running on various computers comprising host physical machine group 542, which is the universe of physical computers in and / or available to public cloud 505. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine group 543 and / or containers from container group 544. It should be understood that these VCEs can be stored as images and transferred between various physical machine hosts either as images or after instantiation of the VCEs. Cloud orchestration module 541 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 540 is a collection of computer software, hardware, and firmware that allows public cloud 505 to communicate over WAN 502 .
[0076] Some further explanation of Virtualized Computing Environments (VCEs) will now be provided. A VCE can be stored as an "image." A new, active instance of the VCE can be instantiated from that image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated userspace instances, called containers. From the perspective of the programs running in them, these isolated userspace instances typically appear to be actual computers. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.
[0077] 502. Private cloud 506 is similar to public cloud 505, except that the computing resources are only available to a single enterprise. Although private cloud 506 is depicted as communicating with WAN 502, in other embodiments, the private cloud can be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is tied together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple component clouds. In this embodiment, public cloud 505 and private cloud 506 are both part of a larger hybrid cloud.
[0078] The terms used herein are only used to describe the purpose of specific embodiments and are not intended to limit the various embodiments. As used herein, the singular forms "one", "an" and "the" are intended to also include plural forms, unless the context clearly indicates otherwise. It will also be understood that the terms "including" and / or "comprising" when used in this specification specify the presence of stated features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. In the previous detailed description of the example embodiments of various embodiments, reference was made to the accompanying drawings (wherein the same reference numerals represent the same elements), which form a part of the present invention and in which specific example embodiments in which the various embodiments can be practiced are illustrated by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice these embodiments, but other embodiments may be used and logical, mechanical, electrical and other changes may be made without departing from the scope of the various embodiments. In the previous description, many specific details have been set forth to provide a thorough understanding of the various embodiments. However, various embodiments may be implemented without these specific details. In other instances, in order not to obscure the embodiments, well-known circuits, structures and techniques are not shown in detail.
[0079] Different instances of the word "embodiment" used in this specification do not necessarily refer to the same embodiment, but they may refer to the same embodiment. Any data and data structures shown or described herein are merely examples, and in other embodiments, different amounts of data, data types, the number and type of fields, field names, the number and type of rows, records, entries, or data organizations may be used. In addition, any data can be combined with logic, so that a separate data structure may not be required. Therefore, the foregoing detailed description should not be understood as limiting.
[0080] The description of various embodiments of the present disclosure has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, practical applications, or improvements over existing technologies in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
[0081] Although the present disclosure has been described in terms of specific embodiments, it will be appreciated that changes and modifications will become apparent to those skilled in the art. It is therefore intended that the appended claims be interpreted as covering all such changes and modifications as fall within the scope of the present disclosure.
[0082] Any advantages discussed in this disclosure are example advantages, and there may be embodiments of the disclosure that achieve all, some, or none of the advantages discussed while remaining within the scope of this disclosure.
Claims
1. A computer-implemented method comprising: determining an input / output (I / O) rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to store I / O data; determining a quiesce timeout for the containerized workload, the quiesce timeout based at least in part on the I / O rate associated with the containerized workload and an amount of memory allocated to buffer the I / O data without causing I / O overflow during performance of a backup operation; determining storage unit specifications that support execution of the backup operation within the quiesce timeout; as well as Based on the storage unit specification, storage units available to the container environment are evaluated to identify a storage unit for the containerized workload.
2. The computer-implemented method of claim 1 , wherein determining the I / O rate associated with the containerized workload further comprises: A historical I / O rate for the containerized workload is obtained.
3. The computer-implemented method of claim 1 , wherein determining the I / O rate associated with the containerized workload further comprises: Current I / O operations associated with the containerized workload are monitored to determine the I / O rate.
4. The computer-implemented method of claim 1 , wherein determining the silence timeout further comprises: estimating a first time for completion of a pending file system operation associated with the containerized workload; as well as A second time is estimated to copy the I / O data from the memory allocated for buffering to persistent storage.
5. The computer-implemented method of claim 1 , further comprising: Migrating the containerized workload to the storage unit corresponding to the storage unit specification, wherein the containerized workload is moved from an originally assigned storage unit that is determined to have insufficient computing resources to support backup processing within the quiesce timeout.
6. The computer-implemented method of claim 1 , further comprising: determining that the storage unit available to the container environment does not correspond to the storage unit specification to support creation of a backup within the quiesce timeout; as well as Additional memory is allocated to the containerized workload to support buffering of the I / O data associated with the containerized workload during the backup operation. 7 . The computer-implemented method of claim 1 , wherein a container orchestration system automates allocation of the storage unit to support creation of a backup within the quiesce timeout.
8. A system comprising: One or more computer-readable storage media storing program instructions and one or more processors, the one or more computer-readable storage media storing program instructions, the one or more processors being configured in response to executing the program instructions to: determining an input / output (I / O) rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to store I / O data; determining a quiesce timeout for the containerized workload, the quiesce timeout based at least in part on the I / O rate associated with the containerized workload and an amount of memory allocated to buffer the I / O data without causing I / O overflow during performance of a backup operation; determining storage unit specifications that support execution of the backup operation within the quiesce timeout; as well as Based on the storage unit specification, storage units available to the container environment are evaluated to identify a storage unit for the containerized workload.
9. The system of claim 8, wherein the program instructions configured to cause the one or more processors to determine the I / O rate associated with the containerized workload are further configured to cause the one or more processors to: Current I / O operations associated with the containerized workload are monitored to determine the I / O rate.
10. The system of claim 8, wherein the program instructions configured to cause the one or more processors to determine the I / O rate associated with the containerized workload are further configured to cause the one or more processors to: A historical I / O rate for the containerized workload is obtained.
11. The system of claim 8, wherein the program instructions configured to cause the one or more processors to determine the silence timeout are further configured to cause the one or more processors to: estimating a time to complete pending file system operations associated with the containerized workload; and A time to copy I / O data from the memory assigned to the containerized workload to storage managed by the file system is estimated.
12. The system of claim 8, wherein the program instructions are further configured to cause the one or more processors to: Migrating the containerized workload to the storage unit corresponding to the storage unit specification, wherein the containerized workload is moved from an originally assigned storage unit that is determined to have insufficient computing resources to support backup processing within the quiesce timeout.
13. The system of claim 8, wherein the program instructions are further configured to cause the one or more processors to: determining that the storage unit available to the container environment does not correspond to the storage unit specification to support creation of a backup within the quiesce timeout; and Additional memory is allocated to the containerized workload to support buffering of the I / O data associated with the containerized workload during the backup operation.
14. The system of claim 8, wherein a container orchestration system automates allocation of the storage unit to support creation of a backup within the quiesce timeout.
15. A computer program product comprising: One or more computer-readable storage media, and program instructions, the program instructions being collectively stored on the one or more computer-readable storage media, the program instructions being configured to cause one or more processors to: determining an input / output (I / O) rate associated with a containerized workload executing in a container environment, wherein the containerized workload interfaces with a storage system to store I / O data; determining a quiesce timeout for the containerized workload, the quiesce timeout based at least in part on the I / O rate associated with the containerized workload and an amount of memory allocated to buffer the I / O data without causing I / O overflow during performance of a backup operation; determining storage unit specifications that support execution of the backup operation within the quiesce timeout; as well as Based on the storage unit specification, storage units available to the container environment are evaluated to identify a storage unit for the containerized workload.
16. The computer program product of claim 15, wherein the program instructions configured to cause the one or more processors to determine the I / O rate associated with the containerized workload are further configured to cause the one or more processors to: Current I / O operations associated with the containerized workload are monitored to determine the I / O rate.
17. The computer program product of claim 15, wherein the program instructions configured to cause the one or more processors to determine the I / O rate associated with the containerized workload are further configured to cause the one or more processors to: A historical I / O rate for the containerized workload is obtained.
18. The computer program product of claim 15, wherein the program instructions configured to cause the one or more processors to determine the silence timeout are further configured to cause the one or more processors to: estimating a time to complete pending file system operations associated with the containerized workload; and A time to copy I / O data from the memory assigned to the containerized workload to storage managed by the file system is estimated.
19. The computer program product of claim 15, wherein the program instructions are further configured to cause the one or more processors to: Migrating the containerized workload to the storage unit corresponding to the storage unit specification, wherein the containerized workload is moved from an originally assigned storage unit that is determined to have insufficient computing resources to support backup processing within the quiesce timeout.
20. The computer program product of claim 15, wherein the program instructions are further configured to cause the one or more processors to: determining that the storage unit available to the container environment does not correspond to the storage unit specification to support creation of a backup within the quiesce timeout; and Additional memory is allocated to the containerized workload to support buffering of the I / O data associated with the containerized workload during the backup operation.