selecting data for transmission from different asynchronous data replication sessions running on the storage system

Abstract

An apparatus includes a processing device configured to identify a set of asynchronous data replication sessions currently running on a storage system, each asynchronous data replication session associated with a corresponding recovery point target, and in response to determining that a current synchronization time of at least one of the asynchronous data replication sessions exceeds its corresponding recovery point target for a first iteration of a given time window, compute a session weight for each of the asynchronous data replication sessions. The processing device is further configured to select data from the asynchronous data replication sessions for transmission based at least in part on the computed session weights for a second iteration of the given time window. The processing device is further configured to transmit the selected data during the second iteration of the given time window.

Description

Technical Field

[0001] This field relates generally to information processing, and more specifically to storage in information processing systems. Background Technology

[0002] Storage arrays and other types of storage systems are typically shared over a network by multiple host devices. Applications running on these host devices each consist of one or more processes that perform application functions. These processes issue input-output (I / O) operation requests to the storage system. The storage system's storage controller service these I / O operation requests. In some information processing systems, multiple storage systems can be used to form a storage cluster. Summary of the Invention

[0003] The illustrative embodiments of this disclosure provide techniques for selecting data for transfer from different asynchronous data replication sessions running on a storage system.

[0004] In one embodiment, an apparatus includes at least one processing means, the at least one processing means including a processor coupled to a memory. The at least one processing means is configured to perform the following steps: identifying a set of two or more asynchronous data replication sessions currently running on a storage system, each of the two or more asynchronous data replication sessions being associated with a corresponding recovery point target; and determining whether the current synchronization time of any one of the two or more asynchronous data replication sessions exceeds its corresponding recovery point target for a first iteration of a given time window. The at least one processing means is further configured to perform the following steps: in response to determining that the current synchronization time of at least one of the two or more asynchronous data replication sessions exceeds its corresponding recovery point target for a first iteration of a given time window, calculating a session weight for each of the two or more asynchronous data replication sessions; and for a second iteration of the given time window, selecting data for transmission from each of the two or more asynchronous data replication sessions based at least in part on the calculated session weight. The at least one processing device is further configured to perform the following steps: during the second iteration of a given time window, transferring selected data from each of the set of two or more asynchronous data replication sessions.

[0005] These and other illustrative embodiments include, but are not limited to, methods, devices, networks, systems, and processor-readable storage media. Attached Figure Description

[0006] Figure 1This is a block diagram of an information processing system for selecting data for transfer from different asynchronous data replication sessions running on a storage system, as shown in an illustrative implementation.

[0007] Figure 2 This is a flowchart of an exemplary process in an illustrative implementation for selecting data for transfer from different asynchronous data replication sessions running on a storage system.

[0008] Figure 3 An application demonstrating the asynchronous replication session balancing algorithm in an illustrative implementation is shown.

[0009] Figure 4 The illustrated implementation shows a process flow for performing balancing between asynchronous replication sessions.

[0010] Figure 5A and Figure 5B An example application illustrating the illustrative implementation of balancing among a set of asynchronous replication sessions is shown.

[0011] Figure 6 and Figure 7 An example of a processing platform, which can be used to implement at least a portion of an information processing system, is shown in the illustrative implementation. Detailed Implementation

[0012] The illustrative embodiments will be described herein with reference to exemplary information processing systems and associated computers, servers, storage devices, and other processing devices. However, it should be understood that the embodiments are not limited to use with the specific illustrative system and device configurations shown. Therefore, the term "information processing system" as used herein is intended to be interpreted broadly to encompass, for example, processing systems including cloud computing and storage systems, as well as other types of processing systems including various combinations of physical and virtual processing resources. Thus, an information processing system may include, for example, at least one data center or other type of cloud-based system that includes one or more clouds hosting tenants accessing cloud resources.

[0013] Figure 1 An information processing system 100 is shown, configured according to an illustrative embodiment to provide functionality for selecting data for transfer from different asynchronous data replication sessions running on a storage system. The information processing system 100 includes one or more host devices 102-1, 102-2, ... 102-N (collectively referred to as host devices 102), which communicate via a network 104 with one or more storage arrays 106-1, 106-2, ... 106-M (collectively referred to as storage arrays 106). The network 104 may include a storage area network (SAN).

[0014] Storage array 106-1 (e.g.) Figure 1 The storage array 106-1 (shown) includes multiple storage devices 108, each storing data utilized by one or more applications running on the host device 102. The storage devices 108 are illustratively arranged in one or more storage pools. The storage array 106-1 also includes one or more storage controllers 110 that facilitate input / output (I / O) processing of the storage devices 108. The storage array 106-1 and its associated storage devices 108 are examples of what is more generally referred to herein as a “storage system.” In this embodiment, this storage system is shared by the host device 102 and is therefore also referred to herein as a “shared storage system.” In embodiments where only a single host device 102 exists, the host device 102 may be configured to exclusively use the storage system.

[0015] Host device 102 illustratively includes a corresponding computer, server, or other type of processing device capable of communicating with storage array 106 via network 104. For example, at least a subset of host device 102 may be implemented as a corresponding virtual machine of a computing service platform or other type of processing platform. In this arrangement, host device 102 illustratively provides computing services, such as executing one or more applications on behalf of each of one or more users associated with a corresponding host device in host device 102.

[0016] The term “user” in this article is intended to be interpreted broadly to encompass various arrangements of human, hardware, software, or firmware entities, as well as combinations of these entities.

[0017] Computing and / or storage services can be provided to users under Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Function as a Service (FaaS), and / or Storage as a Service (STaaS) models; however, it should be understood that many other cloud infrastructure deployments can be used. Furthermore, illustrative implementations can be implemented outside of a cloud infrastructure environment, such as in the case of stand-alone computing and storage systems implemented within a given enterprise.

[0018] Storage device 108 of storage array 106-1 can implement logical units (LUNs) configured to store user objects associated with host device 102. These objects may include files, blocks, or other types of objects. Host device 102 interacts with storage array 106-1 using read and write commands, as well as other types of commands transmitted over network 104. In some embodiments, such commands more specifically include Small Computer System Interface (SCSI) commands, although other types of commands may be used in other embodiments. When the terms are used broadly herein, a given I / O operation illustratively includes one or more of these commands. References to terms such as “input-output” and “IO” herein should be understood to refer to input and / or output. Thus, an I / O operation involves at least one of input and output.

[0019] Furthermore, as used herein, the term "storage device" is intended to be interpreted broadly to encompass, for example, logical storage devices, such as LUNs or other logical storage volumes. A logical storage device can be defined in storage array 106-1 as a distinct portion comprising one or more physical storage devices. Therefore, storage device 108 can be considered to include a corresponding LUN or other logical storage volume.

[0020] Storage device 108 of storage array 106-1 can be implemented using a solid-state drive (SSD). Such SSDs are implemented using non-volatile memory (NVM) devices, such as flash memory. Other types of NVM devices that can be used to implement at least a portion of storage device 108 include non-volatile random access memory (NVRAM), phase-change RAM (PC-RAM), magnetic RAM (MRAM), resistive RAM (RRAM), etc. Various combinations of these and other types of NVM devices or other storage devices can also be used. For example, a hard disk drive (HDD) can be used in combination with an SSD or other types of NVM devices, or in place of an SSD or other types of NVM devices. Therefore, at least a subset of storage device 108 can be implemented using many other types of electronic or magnetic media. In some embodiments, it is assumed that storage array 106-1 includes persistent memory implemented using flash memory or other types of non-volatile memory of storage array 106-1. It is further assumed that the persistent memory is separate from the storage device 108 of the storage array 106-1, but in other embodiments, the persistent memory may be implemented as one or more designated portions of one or more of the storage devices 108.

[0021] In some implementations, storage array 106 may be part of a storage cluster (e.g., storage array 106 may be used to implement one or more storage nodes in a clustered storage system comprising multiple storage nodes interconnected via one or more networks), and it is assumed that host device 102 submits I / O operations to be processed by the storage cluster. Different storage arrays in storage array 106 may be associated with different sites. For example, storage array 106-1 may be at a first site, while storage array 106-2 may be at a second site that is geographically distant from the first site. It is assumed that at least one of the storage controllers of storage array 106 (e.g., storage controller 110 of storage array 106-1) implements intelligent data replication functionality. This data replication can be performed across storage device 108 of storage array 106-1, across multiple storage arrays in storage array 106, or between the storage cluster including storage array 106 and one or more external storage systems, such as cloud-based storage device 116. This intelligent data replication functionality is provided through data replication session balancing module 112 and data replication module 114.

[0022] The data replication session balancing module 112 is configured to identify a set of two or more asynchronous data replication sessions currently running on a storage system (e.g., storage array 106-1, a clustered storage system comprising two or more storage arrays 106, etc.). Each of the two or more asynchronous data replication sessions is associated with a corresponding Recovery Point Objective (RPO). The data replication session balancing module 112 is also configured to determine whether the current synchronization time of any of the two or more asynchronous data replication sessions in the set exceeds its corresponding RPO for the first iteration of a given time window. The data replication session balancing module 112 is also configured to calculate a session weight for each of the two or more asynchronous data replication sessions in the set in response to determining that the current synchronization time of at least one of the two or more asynchronous data replication sessions in the set exceeds its corresponding RPO for the first iteration of a given time window. The data replication session balancing module 112 is also configured to select data for transmission from each of the two or more asynchronous data replication sessions in the set for a second iteration of a given time window, at least in part based on the calculated session weights. The data replication module 114 is configured to transfer selected data from each of the set of two or more asynchronous data replication sessions during the second iteration of a given time window.

[0023] Despite Figure 1In one implementation, the data replication session balancing module 112 and the data replication module 114 are shown to be implemented inside the storage array 106-1 and outside the storage controller 110. However, in other implementations, one or both of the data replication session balancing module 112 and the data replication module 114 may be implemented at least partially inside the storage controller 110 or at least partially outside the storage array 106-1, for example, on one of the host devices 102, on one or more other storage arrays 106-2 to 106-M, or on one or more servers outside the host device 102 and the storage array 106 (e.g., including implementation on a cloud computing platform or other types of information technology (IT) infrastructure). Furthermore, although... Figure 1 Not shown, but other storage arrays in storage arrays 106-2 to 106-M can implement corresponding instances of data replication session balancing module 112 and data replication module 114.

[0024] The functionality of the data replication session balancing module 112 and the data replication module 114 can be implemented, at least in part, in the form of software stored in memory and executed by the processor.

[0025] As described above, it is assumed that storage array 106 in some embodiments is part of a storage cluster. A storage cluster can provide or implement multiple different storage tiers in a tiered storage system. By way of example, a given tiered storage system may include a speed or performance tier implemented using flash storage devices or other types of SSDs, and a capacity tier implemented using HDDs, possibly one or more of which are server-based. As those skilled in the art will appreciate, a variety of other types of storage devices and tiered storage systems can be used in other embodiments. The specific storage device used in a given storage tier may vary depending on the specific requirements of a given embodiment, and a variety of different storage device types may be used within a single storage tier. As previously indicated, the term "storage device" as used herein is intended to be interpreted broadly and may therefore encompass, for example, SSDs, HDDs, flash drives, hybrid drives, or other types of storage products and devices or portions thereof, and illustratively include logical storage devices such as LUNs.

[0026] It should be understood that a tiered storage system may include more than two storage tiers, such as one or more "performance" tiers and one or more "capacity" tiers, wherein the performance tiers illustratively provide increased IO performance characteristics relative to the capacity tiers, and the capacity tiers illustratively use storage that is relatively less expensive than the performance tiers. There may also be multiple performance tiers, each providing a different level of service or performance as needed, or multiple capacity tiers.

[0027] assumed Figure 1 The host device 102 and storage array 106 in the embodiments are implemented using at least one processing platform, wherein each processing platform includes one or more processing units, each processing unit having a processor coupled to memory. Such processing units may illustratively include specific arrangements of computing, storage, and networking resources. For example, in some embodiments, the processing units are implemented at least in part using virtual resources such as virtual machines (VMs) or Linux containers (LXCs), or a combination of both, such as in an arrangement in which Docker containers or other types of LXCs are configured to run on VMs.

[0028] Although the host device 102 and the storage array 106 can be implemented on correspondingly different processing platforms, many other arrangements are possible. For example, in some embodiments, at least a portion of one or more of the host devices 102 and one or more of the storage arrays 106 are implemented on the same processing platform. Thus, one or more of the storage arrays 106 can be implemented, at least partially, within at least one processing platform that implements at least one subset of the host devices 102.

[0029] Network 104 can be implemented using multiple different types of networks to interconnect storage system components. For example, network 104 may include a SAN as part of a global computer network such as the Internet, but other types of networks may be part of a SAN, including wide area networks (WANs), local area networks (LANs), satellite networks, telephone or wired networks, cellular networks, wireless networks such as WiFi or WiMAX networks, or various portions or combinations of these and other types of networks. Therefore, in some embodiments, network 104 includes a combination of multiple different types of networks, each network including processing means configured to communicate using Internet Protocol (IP) or other related communication protocols.

[0030] As a more specific example, some implementations may utilize one or more high-speed local networks, wherein associated processing devices communicate with each other using peripheral components interconnected with high-speed (PCIe) cards and network protocols such as InfiniBand, Gigabit Ethernet, or Fibre Channel. As those skilled in the art will understand, there are a variety of alternative networking arrangements that may be possible in a given implementation.

[0031] While in some embodiments certain commands used by host device 102 to communicate with storage array 106 illustratively include SCSI commands, other types of commands and command formats may be used in other embodiments. For example, some embodiments may utilize command features and functionalities associated with NVM High Speed ​​(NVMe) to perform I / O operations, as described in the NVMe specification, July 2021, Revision 2.0a, which is incorporated herein by reference. Other storage protocols of this type that may be used in the illustrative embodiments disclosed herein include NVMe via a structure, also known as NVMoF, and NVMe via Transmission Control Protocol (TCP), also known as NVMe / TCP.

[0032] As described above, communication between the host device 102 and the storage array 106 can utilize a PCIe connection or other types of connections implemented through one or more networks. For example, illustrative embodiments may use interfaces such as Internet SCSI (iSCSI), Serial Attached SCSI (SAS), and Serial ATA (SATA). In other embodiments, many other interfaces and associated communication protocols may be used.

[0033] In some implementations, storage array 106 can be implemented as part of a cloud-based system.

[0034] Therefore, it should be understood that the term “memory array” as used herein is intended to be interpreted broadly and may encompass several different instances of commercially available memory arrays.

[0035] Other types of storage products that can be used to implement the given storage system in the illustrative embodiments include software-defined storage, cloud storage, object-based storage, and scale-out storage. In the illustrative embodiments, combinations of these and several other storage types can also be used to implement the given storage system.

[0036] In some implementations, the storage system includes first and second storage arrays arranged in an active-active configuration. For example, this arrangement can be used to ensure that data stored in one storage array is replicated to another storage array using a synchronous replication process. This data replication across multiple storage arrays can facilitate fault recovery in system 100. Thus, one storage array can operate as a production storage array relative to another storage array operating as a backup or recovery storage array.

[0037] However, it should be understood that the embodiments disclosed herein are not limited to active-active configuration or any other particular storage system arrangement. Therefore, the illustrative embodiments in this document can be configured using a variety of other arrangements, including, for example, active-passive arrangements, active-active asymmetric logical unit access (ALUA) arrangements, and other types of ALUA arrangements.

[0038] These and other storage systems may be part of what is more generally referred to herein as a processing platform, which includes one or more processing units, each including a processor coupled to memory. A given processing unit may correspond to one or more virtual machines or other types of virtualization infrastructure, such as Docker containers or other types of LXC. As indicated above, communication between such components of system 100 may take place on one or more networks.

[0039] As used herein, the term "processing platform" is intended to be interpreted broadly to encompass (by way of illustration and not limitation) multiple sets of processing devices and one or more associated storage systems configured to communicate over one or more networks. For example, a distributed implementation of host device 102 is possible, where some host devices of host device 102 reside in a data center in a first geographic location, while other host devices of host device 102 reside in one or more other data centers in one or more other geographic locations that may be far from the first geographic location. Storage array 106 may be implemented at least partially in the first geographic location, the second geographic location, and one or more other geographic locations. Thus, in some implementations of system 100, different components of host device 102 and storage array 106 may reside in different data centers.

[0040] Numerous other distributed implementations of host device 102 and storage array 106 are possible. Therefore, host device 102 and storage array 106 can also be implemented in a distributed manner across multiple data centers.

[0041] The following will combine Figure 6 and Figure 7 Additional examples of the processing platform used to implement part of system 100 in the illustrative implementation are described in more detail.

[0042] It should be understood that Figure 1 The specific set of elements shown for selecting data for transfer from different asynchronous data replication sessions running on the storage system is presented as an illustrative example only, and additional or alternative examples may be used in other embodiments. Therefore, another embodiment may include different arrangements of additional or alternative systems, devices, and other network entities, as well as modules and other components.

[0043] It should be understood that these and other features of the illustrative implementation are presented by way of example only and should not be construed as limiting in any way.

[0044] Now refer to Figure 2 The flowchart describes in more detail an exemplary process for selecting data for transfer from different asynchronous data replication sessions running on the storage system. It should be understood that this particular process is merely an example, and in other embodiments, additional or alternative processes for selecting data for transfer from different asynchronous data replication sessions running on the storage system may be used.

[0045] In this embodiment, the process includes steps 200 to 208. These steps are assumed to be performed by the data replication session balancing module 112 and the data replication module 114. The process begins at step 200, identifying a set of two or more asynchronous data replication sessions currently running on the storage system, each of which is associated with a corresponding RPO.

[0046] In step 202, it is determined whether the current synchronization time of any of the two or more asynchronous data replication sessions in the set exceeds its corresponding RPO for the first iteration of a given time window. The length of the given time window can be set to the least common multiple of the allowed synchronization times specified by the RPO corresponding to each of the two or more asynchronous data replication sessions in the set. The current synchronization time for a given asynchronous data replication session in the set of two or more asynchronous data replication sessions can be determined at least in part based on the synchronization cost time for the current incremental data of the given asynchronous data replication session delivered during the first iteration of the given time window. The current incremental data for the given asynchronous data replication session delivered during the first iteration of the given time window can be calculated based on a comparison of the two storage system snapshot increments for the given asynchronous data replication session. The synchronization cost time can include the difference between the last synchronization time of the given asynchronous data replication session and the start time of the current synchronization session in the first iteration of the given time window of the given asynchronous data replication session.

[0047] In response to determining that the current synchronization time of at least one asynchronous data replication session in the set of two or more asynchronous data replication sessions exceeds its corresponding RPO for the first iteration of a given time window, a session weight is calculated for each asynchronous data replication session in the set of two or more asynchronous data replication sessions in step 204. Calculating the given session weight of a given asynchronous data replication session in the set of two or more asynchronous data replication sessions may be based at least in part on (i) the size of the incremental data delivered for the given asynchronous data replication session during the first iteration of the given time window, and (ii) the given RPO associated with the given asynchronous data replication session. Calculating the given session weight of a given asynchronous data replication session may further be based at least in part on (iii) the ratio of the size of the incremental data to the RPO of all said two or more asynchronous data replication sessions in the set.

[0048] In step 206, data for transmission is selected from each of the set of two or more asynchronous data replication sessions for a second iteration at a given time, based at least in part on the calculated session weights. Step 206 may include performing a weighted round-robin balancing algorithm using the calculated session weights. During the second iteration of a given time window, the selected data is transmitted from each of the set of two or more asynchronous data replication sessions in step 208.

[0049] In some implementation schemes, Figure 2 The process also includes determining the amount of total asynchronous data replication capacity allocated to the storage system for the group of two or more asynchronous data replication sessions during the first iteration of a given time window, and initiating one or more remedial measures on the storage system in response to determining that the amount of total asynchronous data replication capacity allocated to the storage system for the group of two or more asynchronous data replication sessions during the first iteration of a given time window exceeds a specified threshold. At least one of the one or more remedial measures may include adjusting a given RPO associated with a given asynchronous data replication session in the group of two or more asynchronous data replication sessions. At least one of the one or more remedial measures may include generating an alarm indicating that at least one of the following is true: the asynchronous data replication capacity of the storage system is insufficient; and at least one asynchronous data replication session in the group of two or more asynchronous data replication sessions will not meet its corresponding RPO.

[0050] At least one of the one or more remedies may include adjusting the total asynchronous data replication capacity of the storage system. The total asynchronous data replication capacity of the storage system may be determined at least in part based on the physical capacity of one or more storage ports of the storage system allocated for performing asynchronous data replication, and adjusting the total asynchronous data replication capacity of the storage system may include allocating one or more additional storage ports of the storage system for asynchronous data replication. The total asynchronous data replication capacity of the storage system may also be determined, or alternatively at least in part, based on a user-specified asynchronous data replication limit threshold, and adjusting the total asynchronous data replication capacity of the storage system may include increasing the user-specified asynchronous data replication limit threshold.

[0051] Asynchronous replication is a data protection feature that can be implemented across various storage systems for different types of storage objects or other data stored thereon. Asynchronous replication can be performed between different sites (e.g., a primary site and secondary or replica sites) or locally within the same site (e.g., between different storage devices in the same storage array, between storage arrays in the same storage cluster, and combinations thereof). Asynchronous replication methods offer a variety of advantages for remote data protection. However, asynchronous replication differs from storage pools or file systems where the total capacity (allocated and available) is readily apparent to the end user. The techniques described herein provide a solution that helps end users understand asynchronous replication capacity and enables runtime planning and monitoring of the synchronization status of asynchronous data replication sessions to achieve self-rebalancing when any relevant conditions deviate.

[0052] In some cases, multiple asynchronous data replication sessions coexist on a storage array (e.g., running simultaneously or at least partially overlapping). Multiple asynchronous data replication sessions (also known as asynchronous replication sessions, asynchronous replication sessions, or replication sessions) consume the same bandwidth resources but may differ in speed. To provide the required data protection through asynchronous replication, it is crucial that the data synchronization time of each replication session is less than its specified Recovery Point Objective (RPO). The techniques described herein provide a method for defining asynchronous data replication capacity and for presenting that capacity to end users in real time. The limited bandwidth available for asynchronous data replication is one of the critical resources for asynchronous replication sessions running on a storage array. When multiple replication sessions are synchronized simultaneously, they compete for bandwidth, leading to prolonged data synchronization times. In some implementations, an asynchronous replication balancing algorithm is provided that uses session incremental synchronization data prediction and weighted round-robin (WRR) scheduling to automatically rebalance bandwidth usage among multiple asynchronous data replication sessions (e.g., these sessions may include one or more failed sessions and one or more healthy sessions).

[0053] For the sake of clarity and simplicity, Figure 2 The steps of the process are shown in sequence, and some steps may at least partially overlap with other steps. In other embodiments, additional or alternative steps may be used.

[0054] Combination Figure 2 The specific processing operations and other system functions described in the flowcharts are presented by way of illustrative example only and should not in any way be construed as limiting the scope of this disclosure. Alternative embodiments may use other types of processing operations to select data for transfer from different asynchronous data replication sessions running on the storage system. For example, as indicated above, in other embodiments, the order of process steps may vary, or certain steps may be performed at least partially simultaneously with each other rather than sequentially. Moreover, one or more process steps may be repeated periodically, or multiple instances of the process may be performed in parallel with each other, to implement multiple data selection processes for corresponding different storage systems or different portions of one or more storage systems.

[0055] For example, combining Figure 2 The functionality described in the flowchart can be implemented, at least in part, in the form of one or more software programs stored in memory and executed by a processor of a processing device such as a computer or server. As will be described below, the memory or other storage device embodying the executable program code of one or more software programs is an example of what is more generally referred to herein as a "processor-readable storage medium".

[0056] Asynchronous data replication is a widely used feature for performing data protection on different types of storage objects, where replication can be performed locally (e.g., within a given site) or between a primary and secondary site, particularly for remote data protection. In cases of disaster, scheduled maintenance windows, etc., customers or other end users may failover to a destination (e.g., the location where data is replicated, whether at a secondary site or a different storage resource on the same local site). Production data will be synchronized to the destination at intervals specified by the customer or other end user, according to a specified RPO. For different storage objects, the RPO of a replication session can vary widely depending on the importance of the data being replicated. When multiple asynchronous data replication sessions coexist on the same storage array (e.g., running simultaneously or at least partially overlapping), different replication sessions can consume the same bandwidth resources at potentially different speeds. To provide the required data protection through asynchronous data replication, it is crucial that the data synchronization time of each asynchronous data replication session is less than its associated RPO. Otherwise, this can lead to various problems with the storage system. For example, such problems could include skipping the next RPO if the current synchronization is still in progress, making it impossible to protect data in a timely manner as expected and required by customers or end users. Furthermore, under certain extreme conditions at customer sites, basic backup functionality may be affected because synchronization takes too long to complete, causing sessions to hang. Other replication-related features, such as failover / failover and non-disruptive upgrades (NDU), may also be blocked, and attempting to recover from a failed or faulty replication session can be time-consuming, labor-intensive, and resource-intensive.

[0057] In the illustrative implementation, asynchronous data replication capacity is determined and presented to customers or other end users in real time. The limited bandwidth available for asynchronous data replication is a critical resource for asynchronous data replication sessions running on the storage array. When multiple replication sessions are synchronizing simultaneously, they compete for bandwidth, leading to prolonged data synchronization times. If each running asynchronous data replication session is able to complete data synchronization according to its associated RPO, there is more capacity available in the storage array for additional asynchronous data replication sessions. If the overall asynchronous data replication capacity of the storage array exceeds the high watermark (e.g., corresponding to the maximum bandwidth allocated or available for asynchronous data replication), then the bandwidth for all asynchronous data replication sessions currently running on the storage array is insufficient. Therefore, desynchronization issues are likely to occur, and alerts will be sent to customers or other end users.

[0058] If some asynchronous data replication sessions fail to complete data synchronization within their associated RPO time, and the overall asynchronous replication capacity remains below the high watermark, a bandwidth self-balancing mechanism is triggered. This mechanism uses session incremental synchronization data prediction and WRR scheduling to automatically rebalance bandwidth usage among different replication sessions (e.g., including failed and healthy sessions). In the next session synchronization window, weights are assigned to each replication session based on its last synchronization time and associated RPO. All incremental data (e.g., data to be synchronized) for each replication session is queued according to the WRR schedule and then sent to the network stack. Failed replication sessions (e.g., those that have missed or are predicted to miss their associated RPO) receive more bandwidth, while the remaining replication sessions continue to synchronize within their associated RPOs because the overall asynchronous replication capacity is below the high watermark. If the overall asynchronous replication capacity exceeds the high watermark, the self-balancing algorithm stops. Optionally, an alert is generated and sent to customers or other end users, indicating that the asynchronous replication capacity has reached its limit or is nearing full capacity.

[0059] To present replication capacity to customers or other end users in a more comprehensive manner, some implementations collect metrics for each replication session at fixed intervals (e.g., five minutes) for a specified duration. For example, the specified duration could be the least common multiple of the RPO times of all asynchronous data replication sessions currently running on the storage array. The following notation will be used in the description below:

[0060] An iteration, which represents a sample data collection cycle (e.g., it could be the minimum RPO across all currently running asynchronous data replication sessions);

[0061] Session_Status represents the current session state inherited from command-line utilities such as uemcli;

[0062] k represents the total number of currently running replication sessions;

[0063] Max_Bandwidth represents the maximum bandwidth available for asynchronous data replication (e.g., the smaller of the bandwidth of the storage array port used for asynchronous data replication and the limit value specified by the customer or other end user).

[0064] Last_Sync_Time i , which represents the last synchronization time of the current replication session i;

[0065] Current_Sync_Start_Time iThis indicates when the current replication session i started (if the current replication session i's status is "synchronizing"), where this data will be retrieved directly from the log or at the end of the iteration;

[0066] Updated_Last_Sync_Time i This indicates that when the iteration ends, the process will check the Last_Sync_Time of the replication session i again. i ;

[0067] Time i It represents the synchronization cost time of the current data increment of replication session i, which can be determined based on Updated_Last_Sync_Time. i -Current_Sync_Start_Time i calculate;

[0068] Data_Delta i , which represents the size of the data in replication session i that will be transferred at the current synchronization time, can be calculated by comparing the increments of the two system snapshots;

[0069] Session_Weight i It represents the weight of replication session i, where Session_Weight i The larger the value, the closer the replication session i is to being out of sync within its RPO;

[0070] High_Watermark represents the threshold for triggering alarms and stopping self-rebalancing of the total asynchronous data replication capacity. The value of High_Watermark is set to a default value (e.g., 90%), which can be adjusted according to the needs of customers or other end users; and

[0071] RPO i This represents the RPO set for replication session i.

[0072] The ratio of the data increment of all replication sessions within the calculated time window to the maximum amount of data that can be synchronized over the duration indicates the overall replication capacity of the storage array, and is calculated according to the following formula:

[0073]

[0074] Where k represents the number of replication sessions, j represents the calculated duration iteration count, and B M This represents the maximum bandwidth (also expressed as Max_Bandwidth), and D cThis represents the calculated duration. If the allocated replication capacity exceeds the total capacity threshold High_Watermark (e.g., 90%), an alert will be generated and sent to the client or other end user, indicating that the asynchronous data replication capacity is insufficient. For each replication session i, if the session synchronization time exceeds RPO... i This will trigger a bandwidth self-rebalancing algorithm between currently running replication sessions (e.g., including failed and healthy sessions).

[0075] Figure 3 An example implementation is shown where a self-rebalancing algorithm 303 is applied to a set of input queues 301-1, 301-2, and 301-3 (collectively referred to as input queue 301) associated with different currently running replication sessions. Data from replication session 1 in input queue 301-1 is represented by 1s, data from replication session 2 in input queue 301-2 is represented by 2s, and data from replication session 3 in input queue 301-3 is represented by 3s. The self-balancing algorithm 303 determines how data should be retrieved from input queue 301 and placed in output queue 305 for transfer from one or more storage array ports designated for asynchronous replication. The self-balancing algorithm 303 is based on weighted proportions using WRR scheduling. Figure 3 In the example, the weights of replication sessions 1, 2, and 3 are 3:1:1 (for example, data from replication session 1 is sent three times more frequently than data from replication sessions 1 and 2).

[0076] For each replication session, if the session synchronization time exceeds the RPO, the write storage system will trigger self-balancing algorithm 303 (e.g., between a failed session and a healthy session). Figure 4 The process flow 400 for implementing the self-balancing algorithm 303 is shown. Iteration begins in step 401, and the replication session status is checked in step 403. If the replication status of replication session i is "synchronizing" or "synchronized," process flow 400 proceeds to step 405. Otherwise, process flow 400 terminates in step 421. If it is determined in step 405 that the status of replication session i is not "synchronizing" (e.g., it is "synchronized"), process flow 400 proceeds to step 407, where i is recorded. If it is determined in step 405 that the status of replication session i is "synchronizing," the Current_Sync_Start_Time of replication session i is recorded in step 409. i Last_Sync_Time i and Data_Delta i .

[0077] In step 411, the last synchronization time of the update for replication session i is determined (denoted as Updated_Last_Sync_Time). i Is it different from Last_Sync_Time? i If the result of step 411 is negative, the process flow returns to step 403. If the result of step 411 is positive, the process flow 400 proceeds to step 413, where Time is determined. i And it is related to RPO i Comparison. Time i It can be calculated as Last_Sync_Time i With Current_Sync_Start_Time i The difference between them:

[0078] Time i =Last_Sync_Time i -Current_Sync_Start_Time i

[0079] If Time i <RPO i (For example, if the result of step 413 is no), then process flow 400 returns to step 403. If Time i >RPO i (For example, if the result of step 413 is yes), then process flow 400 proceeds to step 415, where it is determined whether the total bandwidth capacity (Max_Bandwidth) is greater than the RPO for replication session i. i Synchronized data. If the result of step 415 is negative, that is, if...

[0080]

[0081] Then process flow 400 proceeds to step 417, where an alarm can be generated and sent to the customer or other end user to notify them that the bandwidth capacity is insufficient to synchronize the data of the replicated session i according to its associated RPOi.

[0082] If the result of step 415 is yes, that is, if

[0083]

[0084] The process flow 400 then proceeds to step 419, where the self-balancing algorithm 303 is executed. After step 419, the process flow returns to step 403. The self-balancing algorithm 303 executed in step 419 may include calculating replication session weights for performing bandwidth self-balancing between failed replication sessions and healthy replication sessions. The session weight of replication session | is determined according to the following formula:

[0085]

[0086] The ratio between each of the k replication sessions is then calculated using the following formula:

[0087] Session_Weight1:Session_Weight2:...:Session_Weight k

[0088] in:

[0089]

[0090]

[0091]

[0092] exist Figure 3 In the example, sessions 1, 2, and 3 have a weight ratio of 3:1:1 (e.g., data from input queue 301-1 used to replicate session 1 is placed in output queue 305 three times more frequently than data from input queues 301-2 and 301-3 used to replicate sessions 2 and 3).

[0093] Figure 5A and Figure 5B An example is shown for calculating session weights in self-balancing algorithm 503. In this example, it is assumed that there are three replication sessions with different RPOs specified by customers or end users, such as Figure 5A As shown in Table 500. Here, the RPO for replication session 1 is 5 minutes, the RPO for replication session 2 is 10 minutes, and the RPO for replication session 3 is 20 minutes. Here, Max_Bandwidth is set to 10 GB / s (Gb / s). The Data_Delta1 for replication session 1 is set to 120,000 megabytes (MB), the Data_Delta2 for replication session 2 is set to 120,000 MB, and the Data_Delta3 for replication session 3 is set to 120,000 MB. Figure 5A Table 525 shows the Last_Sync_Time for replication sessions 1, 2, and 3. i and Current_Sync_Start_Time iValue. In this example, the synchronized data for replication session 1 will exceed its associated RPO, and therefore the total bandwidth capacity (Max_Bandwidth) is compared to the data that will be synchronized in the associated RPO:

[0094] Max_Bandwidth*High_Watermark*RPO i =276480MB

[0095]

[0096] Here, it is applied to, for example Figure 5B The self-balancing algorithm 503 for the data of replication sessions 1, 2, and 3 in the corresponding input queues 501-1, 501-2, and 501-3 (collectively referred to as input queue 501) results in a proportion of the replication session weights being adjusted according to the following formula:

[0097] Session_Weight1:Session_Weight2:Session_Weight3=4:2:1

[0098] After applying the self-balancing algorithm 503, data from the input queue 501 is selected to be inserted into the output queue 505 in the WRR schedule, which follows the following... Figure 5B This ratio is described in the document. Then, in idle state, replication session 1 can send 157988.57MB of data within 5 minutes, which will not exceed the RPO time of replication session 1.

[0099] The technology described in this article advantageously enables automatic, real-time tracking of asynchronous replication capacity. Therefore, customers or other end users can clearly understand the replication capacity of the entire storage array or other storage system, as well as individual replication sessions, which helps in planning and updating configurations (e.g., the RPO of a replication session, bandwidth allocated for replication, etc.). Furthermore, if the overall asynchronous replication capacity does not exceed the high watermark, bandwidth between failed and healthy replication sessions will be automatically rebalanced. Alerts can also be generated and provided when asynchronous replication capacity is nearing full capacity to help customers or other end users identify critical replication sessions.

[0100] It should be understood that the specific advantages described above and elsewhere herein are associated with specific illustrative embodiments and are not required to exist in other embodiments. Furthermore, the specific types of information processing system features and functionalities shown in the accompanying drawings and as described above are merely exemplary, and numerous other arrangements may be used in other embodiments.

[0101] Now refer to Figure 6 and Figure 7An illustrative embodiment of a processing platform for implementing the function of selecting data for transfer from different asynchronous data replication sessions running on a storage system is described in more detail. Although described in the context of system 100, these platforms can also be used to implement at least part of other information processing systems in other embodiments.

[0102] Figure 6 An example processing platform including cloud infrastructure 600 is shown. Cloud infrastructure 600 includes components that can be used to implement... Figure 1 The information processing system 100 comprises at least a portion of physical and virtual processing resources. Cloud infrastructure 600 includes multiple virtual machines (VMs) and / or container groups 602-1, 602-2, ..., 602-L implemented using virtualization infrastructure 604. Virtualization infrastructure 604 runs on physical infrastructure 605 and illustratively includes one or more hypervisors and / or operating system-level virtualization infrastructures. Operating system-level virtualization infrastructure illustratively includes a kernel control group of a Linux operating system or other types of operating systems.

[0103] The cloud infrastructure 600 also includes multiple sets of applications 610-1, 610-2, ..., 610-L, which run on corresponding VM / container groups within VM / container groups 602-1, 602-2, ..., 602-L under the control of the virtualization infrastructure 604. A VM / container group 602 may include a corresponding VM, a corresponding set of one or more containers, or a corresponding set of one or more containers running within a VM.

[0104] exist Figure 6 In some implementations of the scheme, VM / container group 602 includes corresponding VMs implemented using virtualization infrastructure 604 including at least one hypervisor. A hypervisor platform can be used to implement the hypervisor within virtualization infrastructure 604, wherein the hypervisor platform has an associated virtual infrastructure management system. The underlying physical machines may include one or more distributed processing platforms, which include one or more storage systems.

[0105] exist Figure 6 In other embodiments of the implementation, VM / container group 602 includes corresponding containers implemented using virtualization infrastructure 604 that provides operating system-level virtualization functionality, such as support for Docker containers running on bare metal hosts or on VMs. The containers are illustratively implemented using the corresponding kernel control group of the operating system.

[0106] As is evident from the above, one or more of the processing modules or other components of system 100 may each run on a computer, server, storage device, or other processing platform element. Such a given element can be considered as an example of what is more generally referred to herein as a "processing device". Figure 6 The cloud infrastructure 600 shown can represent at least a portion of a processing platform. Another example of this processing platform is... Figure 7 The processing platform 700 shown.

[0107] In this embodiment, the processing platform 700 includes a portion of the system 100 and includes a plurality of processing devices denoted as 702-1, 702-2, 702-3, ..., 702-K, which communicate with each other via a network 704.

[0108] Network 704 can include any type of network, such as global computer networks (e.g., the Internet), WANs, LANs, satellite networks, telephone or wired networks, cellular networks, wireless networks (e.g., WiFi or WiMAX networks), or various parts or combinations of these and other types of networks.

[0109] The processing device 702-1 in the processing platform 700 includes a processor 710 coupled to a memory 712.

[0110] The processor 710 may include a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), a video processing unit (VPU), or other types of processing circuitry, as well as portions or combinations of such circuitry elements.

[0111] Memory 712 may take any combination of forms including random access memory (RAM), read-only memory (ROM), flash memory, or other types of memory. Memory 712 and other memories disclosed herein should be considered as illustrative examples of what is more generally referred to as a “processor-readable storage medium” storing executable program code of one or more software programs.

[0112] Articles of manufacture including such processor-readable storage media are considered illustrative embodiments. A given such article of manufacture may include, for example, a storage array, a storage disk, or an integrated circuit comprising RAM, ROM, flash memory, or other electronic memory, or any of a variety of other types of computer program products. As used herein, the term “article of manufacture” should be understood to exclude transient propagating signals. Many other types of computer program products including processor-readable storage media may be used.

[0113] The processing device 702-1 also includes a network interface circuit 714 for interfacing the processing device with the network 704 and other system components, and may include a conventional transceiver.

[0114] It is assumed that the other processing devices 702 of the processing platform 700 are configured in a manner similar to that shown for the processing device 702-1 in the figure.

[0115] Again, the particular processing platform 700 shown in the figure is presented only by way of example, and the system 100 may include additional or alternative processing platforms, as well as a number of different processing platforms in any combination, wherein each such platform includes one or more computers, servers, storage devices or other processing devices.

[0116] For example, other processing platforms used to implement the illustrative implementation scheme may include converged infrastructure.

[0117] Therefore, it should be understood that in other embodiments, additional or alternative elements with different arrangements may be used. At least a subset of these elements may be implemented together on a common processing platform, or each such element may be implemented on a separate processing platform.

[0118] As previously indicated, components of the information processing system disclosed herein can be implemented, at least in part, as one or more software programs stored in memory and executed by a processor of a processing device. For example, at least part of the functionality disclosed herein for selecting data for transfer from different asynchronous data replication sessions running on a storage system is illustratively implemented as software running on one or more processing devices.

[0119] It should be emphasized again that the above embodiments are presented for illustrative purposes only. Many variations and other alternative embodiments may be used. For example, the disclosed technology is applicable to a variety of other types of information processing systems, storage systems, etc. Moreover, the specific configurations of the system and apparatus elements illustrated in the accompanying drawings, as well as the associated processing operations, may change in other embodiments. Furthermore, the various assumptions made above in describing the illustrative embodiments should be considered exemplary and not as requirements or limitations of this disclosure. Numerous other alternative embodiments within the scope of the appended claims will be apparent to those skilled in the art.

Claims

1. An apparatus, the apparatus comprising: At least one processing device includes a processor coupled to a memory; The at least one processing device is configured to perform the following steps: Identify a set of two or more asynchronous data replication sessions currently running on the storage system, each of which is associated with a corresponding recovery point target; Determine whether the current synchronization time of any one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of a given time window; In response to determining that the current synchronization time of at least one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of the given time window, a session weight is calculated for each of the two or more asynchronous data replication sessions in the set. For the second iteration of the given time window, data for transmission is selected from each of the two or more asynchronous data replication sessions in the set based at least in part on the calculated session weights; as well as During the second iteration within the given time window, selected data is transferred from each of the set of two or more asynchronous data replication sessions.

2. The device of claim 1, wherein the length of the given time window is set to the least common multiple of the allowed synchronization time specified by the recovery point target corresponding to each of the set of two or more asynchronous data replication sessions.

3. The device of claim 1, wherein the current synchronization time of the given asynchronous data replication session in the set of two or more asynchronous data replication sessions is determined at least in part based on the synchronization cost time of the current incremental data of the given asynchronous data replication session transmitted during the first iteration of the given time window.

4. The device of claim 3, wherein the current incremental data of the given asynchronous data replication session passed during the first iteration of the given time window is calculated based on a comparison of the snapshot increments of two storage systems for the given asynchronous data replication session.

5. The device of claim 3, wherein the synchronization cost time includes the difference between the last synchronization time of the given asynchronous data replication session and the start of the current synchronization session in the first iteration of the given time window of the given asynchronous data replication session.

6. The apparatus of claim 1, wherein the calculation of a given session weight of a given asynchronous data replication session in the set of two or more asynchronous data replication sessions is based at least in part on (i) the size of incremental data of the given asynchronous data replication session passed during the first iteration of the given time window, and (ii) a given recovery point target associated with the given asynchronous data replication session.

7. The apparatus of claim 6, wherein the calculation of the given session weight of the given asynchronous data replication session is further based at least in part on (iii) the ratio of the size of the incremental data to the recovery point target of all of the set of two or more asynchronous data replication sessions.

8. The device of claim 1, wherein, for the second iteration of the given time window, selecting the data for transmission from each of the two or more asynchronous data replication sessions in the set comprises performing a weighted round-robin balancing algorithm using the calculated session weights.

9. The apparatus of claim 1, wherein the at least one processing device is further configured to perform the following steps: Determine the amount of total asynchronous data replication capacity of the storage system allocated to the set of two or more asynchronous data replication sessions during the first iteration of the given time window; In response to determining that the amount of total asynchronous data replication capacity of the storage system allocated to the set of two or more asynchronous data replication sessions exceeds a specified threshold during the first iteration of the given time window, one or more remedial measures are initiated against the storage system.

10. The apparatus of claim 9, wherein at least one of the one or more remedies includes adjusting the total asynchronous data replication capacity of the storage system.

11. The apparatus of claim 10, wherein the total asynchronous data replication capacity of the storage system is determined at least in part based on the physical capacity of one or more storage ports of the storage system allocated for performing asynchronous data replication of the storage system, and wherein adjusting the total asynchronous data replication capacity of the storage system includes allocating one or more additional storage ports of the storage system for asynchronous data replication.

12. The device of claim 10, wherein the total asynchronous data replication capacity of the storage system is determined at least in part based on a user-specified asynchronous data replication limit threshold, and wherein adjusting the total asynchronous data replication capacity of the storage system includes increasing the user-specified asynchronous data replication limit threshold.

13. The device of claim 9, wherein at least one of the one or more remedies includes adjusting a given recovery point target associated with a given asynchronous data replication session in the set of two or more asynchronous data replication sessions.

14. The device of claim 9, wherein at least one of the one or more remedies includes generating an alarm indicating at least one of the following: the asynchronous data replication capacity of the storage system is insufficient; and at least one of the two or more asynchronous data replication sessions in the set will not meet its corresponding recovery point target.

15. A computer program product comprising a non-transitory processor-readable storage medium in which program code of one or more software programs is stored, wherein the program code, when executed by at least one processing means, causes the at least one processing means to perform the following operations: Identify a set of two or more asynchronous data replication sessions currently running on the storage system, each of which is associated with a corresponding recovery point target; Determine whether the current synchronization time of any one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of a given time window; In response to determining that the current synchronization time of at least one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of the given time window, a session weight is calculated for each of the two or more asynchronous data replication sessions in the set. For the second iteration of the given time window, data for transmission is selected from each of the two or more asynchronous data replication sessions in the set based at least in part on the calculated session weights; as well as During the second iteration within the given time window, selected data is transferred from each of the set of two or more asynchronous data replication sessions.

16. The computer program product of claim 15, wherein the calculation of a given session weight of a given asynchronous data replication session in the set of two or more asynchronous data replication sessions is based at least in part on (i) the size of incremental data of the given asynchronous data replication session passed during the first iteration of the given time window, and (ii) a given recovery point target associated with the given asynchronous data replication session.

17. The computer program product of claim 15, wherein, for the second iteration of the given time window, selecting the data for transmission from each of the two or more asynchronous data replication sessions in the set comprises performing a weighted round-robin balancing algorithm using the calculated session weights.

18. A method, the method comprising: Identify a set of two or more asynchronous data replication sessions currently running on the storage system, each of which is associated with a corresponding recovery point target; Determine whether the current synchronization time of any one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of a given time window; In response to determining that the current synchronization time of at least one of the two or more asynchronous data replication sessions in the set exceeds its corresponding recovery point target for the first iteration of the given time window, a session weight is calculated for each of the two or more asynchronous data replication sessions in the set. For the second iteration of the given time window, data for transmission is selected from each of the two or more asynchronous data replication sessions in the set based at least in part on the calculated session weights; as well as During the second iteration within the given time window, selected data is transferred from each of the set of two or more asynchronous data replication sessions; The method is performed by at least one processing device, which includes a processor coupled to a memory.

19. The method of claim 18, wherein calculating the given session weight of a given asynchronous data replication session in the set of two or more asynchronous data replication sessions is based at least in part on (i) the size of incremental data of the given asynchronous data replication session passed during the first iteration of the given time window, and (ii) a given recovery point target associated with the given asynchronous data replication session.

20. The method of claim 18, wherein for the second iteration of the given time window, selecting the data for transmission from each of the two or more asynchronous data replication sessions in the set comprises performing a weighted round-robin balancing algorithm using the calculated session weights.

Images