End-to-end resumption of cross-region replication using new replication

Abstract

Techniques are described for performing different types of restart operations on file storage replication between a source file system and a target file system in different cloud infrastructure areas. In some embodiments, the disclosed techniques perform a restart operation to terminate current cross-region replication by synchronizing resource cleanup operations in a source file system and a target file system, respectively. In other embodiments, the disclosed techniques perform a restart operation to allow a customer to reuse a source file system by identifying a restarted base snapshot in the source file system, without relying on a target file system.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Non-Provisional Application No. 18 / 332,462, filed on June 9, 2023, entitled “END-TO-END RESTARTABILITY OF CROSS-REGION REPLICATION USING ANEW REPLICATION” and U.S. Non-Provisional Application No. 18 / 332,462, filed on June 9, 2023, entitled “END-TO-END RESTARTABILITY OF CROSS-REGION REPLICATION USING A COMMON SNAPSHOT”, all of which claim the benefit of and priority to U.S. Provisional Application No. 63 / 352,992 filed on June 16, 2022, U.S. Provisional Application No. 63 / 357,526 filed on June 30, 2022, U.S. Provisional Application No. 63 / 412,243 filed on September 30, 2022, and U.S. Provisional Application No. 63 / 378,486 filed on October 5, 2022, under 35 U.S.C. 119(e), the disclosures of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] The present disclosure relates generally to file systems. More specifically, but not limited to, techniques for performing different types of restart operations on file storage replication between file systems in different cloud infrastructure regions are described. Background Art

[0004] The replication process for disaster recovery may require restarting file system replication due to failures, outages, or infrastructure changes. It is important to restart file system replication appropriately and efficiently. Therefore, there is a need to enhance the restartability of file system replication. Summary of the invention

[0005] The present disclosure relates generally to file systems. More specifically, but not limited to, techniques for performing different types of restart operations on file storage replication between file systems in different cloud infrastructure regions are described. Various embodiments are described herein, including methods, systems, non-transitory computer-readable media storing programs, codes, or instructions executable by one or more processors, and the like.

[0006] In certain embodiments, a technique is provided that includes a method, the method comprising: performing, by a computing system, cross-region replication between a source file system and a target file system, the source file system and the target file system being in different regions; receiving, by the computing system, a request to terminate the cross-region replication between the source file system and the target file system; synchronizing, by the computing system, operations in the source file system and operations in the target file system by using a first set of states and a second set of states, the operations in the source file system including performing resource cleanup in the source file system, and the operations in the target file system including performing resource cleanup in the target file system; and starting, by the computing system, a new cross-region replication between the source file system and the target file system after the resource cleanup in the source file system and the resource cleanup in the target file system.

[0007] In yet another embodiment, the first set of states tracks resource management and utilization and is visible to the client.

[0008] In yet another embodiment, the second set of state tracks ownership of replication-related jobs of components of the source and target file systems and is not visible to the client.

[0009] In another embodiment, resource cleanup in the source file system and the target file system is performed using a first set of states; and, when a request to terminate cross-region replication is initiated by the source file system, resource cleanup in the source file system and the target file system is performed using a first subset of the second set of states, and when a request to terminate cross-region replication is initiated by the target file system, resource cleanup in the source file system and the target file system is performed using a second subset of the second set of states.

[0010] In yet another embodiment, a request to terminate the cross-region replication is initiated by the source file system, and resource cleanup in the source file system and resource cleanup in the target file system are performed simultaneously.

[0011] In yet another embodiment, the request to terminate the cross-region replication is initiated by the target file system, and resource cleanup in the target file system is executed and completed before resource cleanup in the source file system begins.

[0012] In various embodiments, a system is provided that includes one or more data processors and a non-transitory computer-readable medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to perform part or all of one or more methods disclosed herein.

[0013] In various embodiments, a non-transitory computer-readable medium stores computer-executable instructions that, when executed by one or more processors, cause the one or more processors of a computer system to perform one or more methods disclosed herein.

[0014] In various embodiments, a computer program product comprises a computer program / instructions which, when executed by a processor, cause the processor to perform any of the methods disclosed herein.

[0015] The techniques described above and below can be implemented in a variety of ways and in a variety of contexts. Several example implementations and contexts are provided with reference to the following figures, as described in more detail below. However, the following implementations and contexts are only a small part of the numerous implementations and contexts. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The features, embodiments, and advantages of the present disclosure may be better understood when the following detailed description is read with reference to the accompanying drawings.

[0017] Figure 1 Depicted are example concepts of recovery time objective (RTO) and recovery point objective (RPO) in accordance with certain embodiments.

[0018] Figure 2 is a simplified block diagram illustrating an architecture for cross-region remote replication according to certain embodiments.

[0019] Figure 3 is a simplified schematic diagram of components involved in cross-region remote replication according to certain embodiments.

[0020] Figure 4 is a simplified flow chart illustrating steps performed during cross-region remote replication according to certain embodiments.

[0021] Figure 5 is a simplified diagram illustrating the high-level concepts of a B-tree walk in accordance with certain embodiments.

[0022] Fig. 6A is a diagram illustrating pipeline stages of cross-region replication according to certain embodiments.

[0023] Figure 6B is a diagram illustrating pipeline stages of cross-region replication according to certain embodiments.

[0024] Figure 7 is a diagram illustrating a layered structure in a file storage service (FSS) data plane according to certain embodiments.

[0025] Figure 8 Depicted is a simplified example binary large object (BLOB) format in accordance with certain embodiments.

[0026] Fig. 9 Depicted is an example replication bucket format in accordance with certain embodiments.

[0027] Fig.10 is a flow diagram illustrating a state machine for concurrent source upload and target download according to some embodiments.

[0028] Fig.11 is an example flow diagram illustrating the interaction between a data plane and a control plane in a source region according to some embodiments.

[0029] Fig.12 is a flow diagram illustrating a state machine of a control plane of a file system according to certain embodiments.

[0030] Fig.13 is a diagram illustrating an example use of a provenance ID in accordance with certain embodiments.

[0031] Fig.14 is a flow chart illustrating a process of using a provenance ID to identify a base snapshot for cross-region replication according to certain embodiments.

[0032] Fig.15 is a flow diagram illustrating a replica creation process according to some embodiments.

[0033] Fig.16 is a flow diagram illustrating source-initiated duplicate deletion processing according to some embodiments.

[0034] Fig.17 is a flow diagram illustrating target-initiated replication deletion processing according to some embodiments.

[0035] Fig.18 is a flow chart illustrating a high-level process flow for duplicate deletion according to some embodiments.

[0036] Fig.19 is a flow chart illustrating a high-level process flow for a replication previous snapshot restart process with the same data flow as an existing cross-region replication, according to certain embodiments.

[0037] Fig. 20 is a simplified diagram illustrating a failback mode according to some embodiments.

[0038] Fig.21 is a flow chart illustrating the process flow of a failover mode according to some embodiments.

[0039] Fig. 22 is a flow chart illustrating a high-level process flow of a copy previous snapshot restart process with reverse data flow according to certain embodiments.

[0040] Fig.23is a block diagram illustrating one mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0041] Fig.24 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0042] Fig.25 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0043] Fig.26 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0044] Fig. 27 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION

[0045] In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. However, it is apparent that various embodiments can be practiced without these specific details. The figures and descriptions are not intended to be limiting. The word "exemplary" as used herein means "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as being preferred or superior to other embodiments or designs.

[0046] When a file system encounters a problem, it needs a way to restart running jobs to ensure that they restart from exactly the right point with deterministic results. Failures during replication may involve, for example, a system crash, the inability to obtain a KMS key, or the need for an upgrade. The system may need to restart from either the source file system or the destination file system, as either file system may have failed during replication.

[0047] Existing technologies without checkpointing mechanisms may need to wait until everything is complete and clean up a lot of information because they have no background cleanup. Even if a checkpointing mechanism exists, the checkpoints reside in the data plane and the control plane knows nothing about the checkpoints. Therefore, checkpointing alone has its limitations for cross-region restart purposes.

[0048] Another challenge in the restart process is the coordination between the source and target file systems, because the source file system cannot be restarted until the target file system is cleaned up. Otherwise, corruption may occur in the file system.

[0049] Scale-out distributed systems where machines and databases are spread across different geographic regions pose additional challenges due to network latency or congestion. Such systems may require a mechanism to ensure atomic transactions between different regions to maintain consistency between databases in the event of failures or updates.

[0050] The technology disclosed in the present disclosure may cover different types of restart operations of existing cross-region replication processing, such as replication deletion and replication previous snapshot restart. Replication deletion can terminate and exit the current replication processing, perform resource cleanup by cleaning up all data (e.g., metadata, checkpoint-related records, job / processing queues, etc.) in both the source file system and the target file system, and then start a new cross-region replication. This replication deletion technology can be used when there is a permanent failure, the customer expects to switch to a different region, etc. Replication previous snapshot restart can restart (or continue) the existing replication processing from an earlier common snapshot between the source file system and the target file system without cleaning up all data in the two file systems to complete the replication processing. This technology can be used when some recoverable failure events (such as software problems) occur or due to some problems with the current snapshot, the customer expects to continue the replication processing from an earlier snapshot. The technology for resuming the replication of the previous snapshot can also include restarting with the same data flow direction as the current replication or the opposite data flow direction. An example of resuming the previous snapshot by reversing the data flow can be a customer who expects to use the original source file system again after performing cross-region replication between the source file system and the target file system.

[0051] The source region and the target region can each have their own database (e.g., a shared database, referred to as an SDB) for communication between the data plane (DP) and the control plane (CP) in each region. The two databases are not connected, and the objects in the two databases are independent. Each database can be of a different type, such as relational or nonSQL, etc. The technology disclosed in the present disclosure utilizes cross-region APIs and state machines in the control planes (CP) of both the source region and the target region to track the replication process in the two regions to ensure that they are synchronized. There is a state machine in each region, and a state in a region may cause a state transition in another region. Reservations with sequence numbers and new tables in the database and locking mechanisms in distributed regions are used to help with this atomicity guarantee. Therefore, the disclosed technology helps synchronize these asynchronous operations in the source file system and the target file system, such as incremental (delta) uploads and incremental downloads, by using two sets of states.

[0052] The disclosed technology can provide the following additional benefits: Isolate failed jobs to identify the root cause and then restart without affecting other jobs running in the same area or the same file system. The disclosed technology also supports deterministic re-application and retry to ensure the same results. This can be called idempotent.

[0053] Finally, the disclosed technology can help customers save significant resources (e.g., bandwidth, computing power) and costs by restarting from the most recent previous common snapshot between the source file system and the target file system, rather than having to restart the entire cross-region replication simply because a snapshot was corrupted during the replication process.

[0054] When referring to a cross-region replication process, the terms source region and source file system can be used interchangeably because the replication process is performed by the source file system in the source region. Similarly, when referring to a cross-region replication process, the terms target region and target file system can be used interchangeably because the replication process is performed by the target file system in the target region.

[0055] Explanation of terms in certain embodiments

[0056] In certain embodiments, “recovery time objective” (RTO) refers to the time that users require their replicas to become available in a secondary (or target) region after a failure of an availability domain (AD) in the primary (or source) region, whether the failure is planned or unplanned.

[0057] In certain embodiments, a “recovery point objective” (RPO) refers to the maximum acceptable tolerance in terms of time of data loss between a primary region failure (usually due to an unplanned failure) and the availability of a secondary region.

[0058] In some embodiments, a "replicator" may refer to a component (e.g., a virtual machine (VM)) in the data plane of a file system that is used to upload deltas to a remote object repository (i.e., an object storage service) if the component is located in a source region, or to download deltas from an object storage device for delta application if the component is located in a target region. Replicators may be formed into a queue (i.e., multiple VMs or replicator threads), referred to as a replicator queue, to perform cross-region (or X-region) replication processing (e.g., uploading deltas to a target region) in parallel.

[0059] In some embodiments, a "delta generator" (DG) may refer to a component in the data plane of a file system that extracts deltas (i.e., changes) between key values ​​of two snapshots if the component is located in a source region, or applies deltas to the latest snapshot in a B-tree of the file system if the component is located in a target region. A delta generator in a source region may use several threads (referred to as delta generator threads or range threads for multiple partitioned B-tree key ranges) to perform delta extractions (or B-tree walks) in parallel. A delta generator in a target region may use several threads to apply downloaded deltas to its latest snapshot in parallel.

[0060] For purposes of this disclosure and in certain embodiments, a "shared database" (SDB) may refer to a key-value store that components in the control plane and data plane of a file system (e.g., a replicator queue) can read from and write to communicate with each other. In certain embodiments, the SDB may be part of a B-tree.

[0061] In some embodiments, "File System Communicator" (FSC) may refer to a file manager layer that runs on storage nodes in the data plane of a file system. This service facilitates file creation, deletion, read, and write requests, and collaborates with an NFS server (e.g., Orca) to provide IO services to clients. A replicator queue may communicate with many storage nodes, distributing the work of reading / writing file system data to the storage nodes.

[0062] In some embodiments, "blob" may refer to a data type used to store information in a database (e.g., a formatted binary file). A blob is generated by a source region during replication and uploaded to an object repository (i.e., an object storage device) in a target region. A blob may include binary tree (B-tree) keys and values ​​as well as file data. A blob in an object repository is referred to as an object. B-tree key-value pairs and their associated data are packaged together in a blob to be uploaded to an object repository in a target region.

[0063] In some embodiments, a "manifest" may refer to information communicated by a file system in a source region (referred to herein as a source file system) to a file system in a target region (referred to herein as a target file system) to facilitate a cross-region replication process. There are two types of manifest files, master manifests and checkpoint manifests. A range manifest file (or master manifest file) is created by the source file system at the beginning of the replication process, describing the information expected by the target file system (e.g., B-tree key ranges). A checkpoint manifest file is created after a checkpoint in the source file system, informing the target file system of the number of blobs included in the checkpoint and uploaded to the object repository so that the target file system can download that number of blobs accordingly.

[0064] In some embodiments, a "delta" may refer to the differences identified between two given snapshots after a replicator recursively visits each node of a B-tree (also referred to herein as a walk of the B-tree). A delta generator identifies difference pairs of B-tree key values ​​and traverses the B-tree nodes to obtain the file data associated with the B-tree keys. The delta between two snapshots may contain multiple blobs. When used in the context of a source file system uploading information to an object repository and a target file system downloading from the object repository, the term "delta" may include blobs and manifests.

[0065] In some embodiments, an "object" may refer to a partial collection of information representing an entire increment during a cross-region replication cycle and is stored in an object repository. An object may be several MB in size and is stored in a specific location in a bucket of an object repository. An object may contain many increments (i.e., blobs and manifests). A blob uploaded to and stored in an object repository is called an object.

[0066] In some embodiments, a "bucket" may refer to a container that stores objects in a compartment within an object storage namespace (tenancy). In the present disclosure, a bucket is used by a source replicator to store secure deltas using server-side encryption (SSE) and is also used by a target replicator to download to apply changes to a snapshot.

[0067] In some embodiments, "delta apply" may refer to the process of applying the downloaded delta of the target file system to its most recent snapshot to create a new snapshot. This may include parsing the manifest file, applying snapshot metadata, inserting B-tree keys and values ​​into its B-tree, and storing the data associated with the B-tree key (i.e., file data or data portion of a blob) to its local storage. Snapshot metadata is created and applied at the beginning of a replication cycle.

[0068] In some embodiments, a "region" may refer to a logical abstraction corresponding to a geographic region. Each region may include one or more connected data centers. Regions are independent of other regions and may be separated by great distances.

[0069] End-to-end cross-region replication architecture

[0070] An end-to-end cross-region replication architecture provides novel techniques for end-to-end file storage replication and security between file systems in different cloud infrastructure regions. In certain embodiments, the file storage service generates deltas between snapshots in a source file system and transmits the deltas and associated data through a high-throughput object storage device to recreate new snapshots in a target file system located in a different region during disaster recovery. The file storage service utilizes novel techniques to achieve scalable, reliable, and restartable end-to-end replication. Novel techniques for ensuring secure transmission and consistency of information during end-to-end replication are also described.

[0071] In the context of cloud, a domain is a logical collection of one or more regions. Domains are usually isolated from each other and do not share data. Within a region, data centers in the region can be organized into one or more availability domains (ADs). Availability domains are isolated from each other, fault-tolerant, and very unlikely to fail at the same time. ADs are configured so that a failure at one AD in a region is unlikely to affect the availability of other ADs in the same region.

[0072] Current practices for disaster recovery can include taking snapshots periodically and resynchronizing them to another file system in a different availability domain (AD) or region. While resynchronization can be managed and maintained by the customer, it lacks a user interface for viewing progress, is a slow and serialized process, and is not easy to manage as data grows over time.

[0073] Therefore, different approaches are needed to address these and other challenges. The cloud service provider (e.g., Oracle Cloud Infrastructure (OCI)) file storage replication disclosed in the present disclosure is based on incremental snapshots to provide a consistent point-in-time view of the entire file system by propagating the increment of the changed data from the primary AD in the region to the secondary AD located in the same or different regions. As used herein, the primary site (or source side) may refer to the following location (e.g., AD or region): the file system is located at this location and initiates replication processing for disaster recovery. The secondary site (or target side) may refer to the following location (e.g., AD or region): the file system receives information from the file system in the primary site at this location during the replication process to become a new operating file system after disaster recovery. The file system located in the primary site is referred to as the source file system, and the file system located in the secondary site is referred to as the target file system. Therefore, the primary site, the source side, the source area, the primary file system, or the source file system (referring to one of the file systems on the source side) can be used interchangeably. Similarly, the secondary site, the target side, the target area, the secondary file system, or the target file system (referring to one of the file systems on the target side) can be used interchangeably.

[0074] The file storage service (FSS) of the present disclosure supports full disaster recovery for failover or failback with minimal management effort. Failover is a series of actions that make the secondary / target site become the primary / source (i.e., start serving the workload), and may include planned and / or unplanned failovers. Planned failover (also referred to as planned migration) is initiated by the user to perform a planned failover from the source side (e.g., source area) to the target side (e.g., target area) without losing data. Unplanned failover refers to when the source side stops unexpectedly due to, for example, a disaster, and the user needs to start using the target side because the source side is lost. Failback is to restore the primary / source side before the failover to become the primary / source again. Failback may occur when the user wants to reuse the source side as its primary AD by reversing the failover process after the planned or unplanned failover and the triggering event (e.g., interruption) ends. The user can recover from the last point in time of the source side before the triggering event, or can recover from the latest changes on the target side. The replication process described in the present disclosure can preserve the file system identity after round-trip replication. In other words, the source file system can serve the workload again after performing a failover and then a failback.

[0075] The technology disclosed in the present disclosure (e.g., method, computer-readable medium, and system) includes cross-region replication of file system data and / or metadata by: using consistent snapshot information to copy the delta between snapshots from a source region to multiple remote (or target) regions, and then visiting (or recursively visiting) all keys and values ​​in one or more file trees (e.g., B-trees) of the source file system (sometimes referred to as "visiting B-trees" or "visiting keys" in this article) to build consistent information (e.g., deltas or differences between keys and values ​​of two snapshots created at different times). The built consistent information is put into a blob format and transmitted to a remote side (e.g., a target region) using an object interface (e.g., an object repository (described later)), so that the target file system on the remote side can immediately download and start applying the information once it detects the transmission information on the object interface. This process is completed by using a control plane, and the process can be expanded to thousands of file systems and hundreds of replication machines. Both the source file system and the target file system can operate concurrently and asynchronously. Concurrent operation means that the data upload process of the source file system and the data download process of the target file system can occur at the same time. Asynchronous operation means that the source file system and the target file system can each operate at their own pace without waiting for each other at each stage, for example, different start time, end time, processing speed, etc.

[0076] In some embodiments, multiple file systems may exist in the same region and be represented by the same B-tree. Each of these file systems in the same region may be independently replicated across regions. For example, file system A may have a set of replicator threads running in parallel that walk the B-trees to perform replication for file system A. File system B represented by the same B-tree may have another set of such replicator threads running in parallel that walk the same B-tree to perform replication for file system B.

[0077] Regarding security, cross-region replication is completely secure. Information is transmitted securely and applied securely. The disclosed technology provides isolation between the source region and the target region so that keys are not shared between the two in an unencrypted manner. Therefore, if the source key is compromised, the target is not affected. In addition, the disclosed technology includes how to read the keys, how to convert them into certain formats, and how to upload and download them securely. Different keys are created and used in different regions, so separate keys are created on the target and applied to information in a target-centric security mechanism. For example, FSS generates session keys that are valid only within one replication cycle or session to encrypt data to be uploaded from the source region to the object repository and decrypt data downloaded from the object repository to the target region. Different keys are used locally in the source and target regions.

[0078] In the disclosed technology, each upload process and download process through the object repository during replication has different pipeline stages. For example, the upload process has several pipeline stages, including visiting the B-tree to generate increments, accessing storage IO, and uploading data (or blobs) to the object repository. The download process has several pipeline stages, including downloading data, applying increments to snapshots, and storing data in storage devices. Each of these pipelines also has parallel processing threads to increase the throughput and performance of the replication process. In addition, the parallel processing threads can take over any failed processing threads and recover the replication process from the point of failure without starting over from the beginning. Therefore, the replication process is highly scalable and reliable.

[0079] Figure 1 Depicted are example concepts of recovery point objective (RPO) and recovery time objective (RTO) for unplanned failover according to certain embodiments. RPO is the maximum tolerance for data loss between a primary site failure and secondary site availability (usually specified in minutes). Figure 1As shown in , primary site A 102 encounters an unplanned incident at time 110, which triggers a failover replication process by copying the latest snapshot and its deltas to secondary site B 104. The initially copied information arrives at secondary site B 104 at time 112. Primary site A 102 completes its copying of information to secondary site B 104 at time 114, and secondary site B 104 completes its replication process at time 116. Therefore, secondary site B 104 becomes fully operational at time 116. Therefore, from point 110 until point 116 when the data is available again, the user's data is inaccessible in primary site A 110. Therefore, the RPO is the time between point 110 and point 116. For example, if there is 10 minutes of data that the user does not care about, then the RPO is 10 minutes. If the data is lost for more than 10 minutes, then the RPO is not met. Zero RPO means synchronous replication.

[0080] The RTO is the time (usually specified in minutes) required for the secondary site to be fully operational so that users can access data again after a failure. This is considered from the perspective of the secondary site. Figure 1 , primary site A 102 begins the failover replication process at time 120. However, secondary site B 104 remains operational until time 122 when it becomes aware of the incident (or outage) at primary site A 102. Therefore, secondary site B 104 stops its service at time 122. Using a similar failover replication process as described for RPO, secondary site B 104 becomes fully operational at time 126. Therefore, RTO is the time between 122 and 126. Secondary site B 104 can now assume the role of the primary site. However, for customers using primary site A 102, the loss of service occurs between time 120 and 126.

[0081] The primary (or source) site is where the action is happening, and the secondary (or target) site is inactive and unavailable until a disaster occurs. However, customers can be provided with a point in time where they can continue to use the secondary site for testing-related activities. This involves how customers set up replication, how they start using the target if a problem occurs, and how they return to the source once their source fails over.

[0082] Figure 2 is a simplified block diagram illustrating the architecture of cross-region remote replication according to some embodiments. Figure 2, the end-to-end replication architecture is shown with two regions: a source region 290 and a target region 292. Each region may contain one or more file systems. In some embodiments, the end-to-end replication architecture includes data planes 202 and 212, a control plane (only control APIs 208a-n and 218a-n are shown), local storage devices 204 and 214, an object repository 260, and a key management service (KMS) 250 for both the source region 290 and the target region 292. For simplicity, Figure 2 Only one file system 280 in the source region 290 and one file system 282 in the target region 292 are shown. If there is more than one file system in the region, the same replication architecture applies to each pair of source and target file systems. In some embodiments, multiple cross-region replications can be performed concurrently between each pair of source and target file systems by utilizing parallel processing threads. In some embodiments, a source file system can be replicated to different target file systems located in the same target region. In addition, file systems in a region can share resources. For example, depending on the implementation, certain resources in KMS250, object repository 260, and the data plane can be shared by many file systems in the same region.

[0083] The data plane in this architecture includes local storage nodes 204a-n and 214a-n and replicators (or replicator queues) 206a-n and 216a-n. The control API host in each region performs all coordination between different regions. The FSS receives a request from a customer to establish replication between a source file system 280 and a target file system 282 to which the customer wants to move its data. The control plane 208 obtains the request, allocates resources, and notifies the replicator queues 206a-n in the source data plane 202 to start uploading data 230a (or what can be called the increment being uploaded) from different snapshots to the object storage device 260. The API can be used to help customers set replication time objectives and recovery time objectives (RTO). The replication model disclosed in this disclosure is a "push-based" model based on snapshot increments, which means that the source region initiates the replication.

[0084] As used herein, data 230a and 230b transferred between the source file system 280 and the target file system 282 is a general term and may include the initial snapshot, keys and values ​​in the B-tree that differ between the two snapshots, file data (e.g., fmap), snapshot metadata (i.e., a set of snapshot B-tree keys reflecting the various snapshots taken in the source file system), and other information that helps facilitate the replication process (e.g., manifest files).

[0085] Turning to the data plane of the cross-region replication architecture, the replicator is a component in the data plane of the file system. Depending on the region in which the file system is located, it performs delta generation or delta application for the file system. For example, the replicator queue 206 in the source region file system 280 performs delta 230a generation and replication. The replicator queue 216 in the target region file system 282 downloads delta 230b and applies the delta to the latest snapshot in the target region file system 282. The target region file system 282 can also use its control plane and workflow to ensure end-to-end delivery.

[0086] All incremental work is based on snapshots, which are existing resources in File Storage as a Service. Snapshots are points in time, data points, or views of what is happening in the file system and are performed periodically in the source area file system 280. For the first replication, FSS takes a base snapshot that is a snapshot of all the content of the source file system (e.g., it has never been replicated before) and transfers all of that content to the target system. In other words, the replicator reads from the storage layer of that particular file system and puts all the data into the object storage bucket.

[0087] Once the data plane 202 of the source file system 280 uploads all the data 230a to the object storage device (or object repository) 260, the source side control plane 208 will notify the target side control plane 218 that there is new work to be done on the target side, which is then relayed to the replicator on the target side. The target side replicator 216a-n then starts downloading objects (e.g., initial snapshots and deltas) from the object storage bucket 260 and applies the deltas captured on the source side.

[0088] If it is a base copy (e.g., the entire file system contents up to a certain point in time, e.g., from the past five days to five years), then the upload process may take a long time. To help achieve service level goals for time and performance, the source system 280 can take replication snapshots for a specific duration, such as one hour. The source side 280 can then transfer all the data for that hour to the target side 282, and take a new snapshot every hour. If some caches have a lot of changes, then the replication can be set to a lower replication interval.

[0089] To illustrate the above discussion, consider a scenario in which a first snapshot is created in a file system in a source area (referred to as the source file system). Replication is performed periodically; therefore, the first snapshot is replicated to a file system in a target area (referred to as the target file system). When some updates are performed in the source file system thereafter, a second snapshot will be created. If an unplanned outage occurs after the second snapshot is created, the source file system will attempt to replicate the second snapshot to the target file system. During this failover, the source file system can identify the difference (i.e., the delta) between the first snapshot and the second snapshot, which includes the B-tree keys and values ​​in the B-tree representing both the first snapshot and the second snapshot and their associated file data. The deltas 230a and 230b are then transferred from the source file system to the target file system via the object repository 260 in the target area so that the target file system recreates the second snapshot by applying the delta to the first snapshot that it previously established in the target area. Once the second snapshot is created in the target file system, the replication process for the failover is complete, and the target file system is ready.

[0090] Turning to the control plane and its application programming interface ("API"), the control plane provides instructions to the data plane, which includes the replicator as an executor to carry out the instructions. Both storage devices (204 and 214) and replicator queues (206 and 216) are in the data plane. Figure 2 The control plane is not shown in the figure. As used herein, a "cycle" may refer to the duration starting when the source file system 280 begins transferring data 230a to the target file system 282 and ending when the target file system 282 receives all of the data 230b and completes its application of the received data. The data 230a-b is captured on the source side and then applied to the target side. Once all changes for a cycle are applied on the target side, the source file system 280 takes another snapshot and starts another cycle.

[0091] The control API (208a-n and 218an) is a set of hosts in the overall architecture of the control plane and performs file system configuration. The control API is responsible for passing state information between different regions. State machines that track various state activities in the region (such as the progress of jobs, the location of keys, and future tasks to be performed) are distributed among multiple regions. All of this information is stored in the control plane of each region and passed among the regions through the control API. In other words, the state information is about life cycle details, incremental details, and the life cycle of resources. The state machine can also track the progress of replication and collaborate with the data plane to help estimate the time required for replication. Therefore, the state machine can provide users with status on whether replication is on time and whether the job is healthy.

[0092] In addition, the communication between the control API (208a-n) of the source file system 280 in different regions and the control API (218a-n) of the target file system 218 includes the transfer of snapshots and metadata to make an exact copy from the source to the target. For example, when a customer takes snapshots regularly in the source file system, the control plane can ensure that the same user snapshots are created on the target file system, including metadata tracking, transfer and re-creation.

[0093] Figure 2 The object store 260 (also referred to herein as "object") in is an object storage service (e.g., Oracle's object storage service) that allows reading blobs and writing files for archiving. The benefits of using an object store are: first, it is easy to configure; second, it is easy to stream data into the object store; third, it has the benefit of secure streaming as a reliable repository for saving information; all of this is because there is no network loss, so the data can be downloaded immediately and saved permanently. Although direct communication between replicators in the source and target regions is possible, direct communication requires a cross-region network setup, which is not scalable and difficult to manage.

[0094] For example, if there is a large amount of data to be moved from a source to a target, the source can upload it to the object repository 260, and the target 282 does not have to wait for all the information to be uploaded to the object repository 260 before starting to download. Therefore, both the source 280 and the target 282 can operate concurrently and continuously. Using an object repository allows the system to scale and achieve faster throughput. In addition, the key management service (KMS) 250 can control access to the object repository 260 to ensure security. In other words, the source tries to move the data out of the source area as quickly as possible and keep the data somewhere before applying it to the target so that the data is not lost.

[0095] Compared to using network pipelining (which has packet loss and recovery issues), using object storage repository 260 between the source and target regions enables continuous data streaming, allowing hundreds of file systems from the source region to write to the object storage repository while the target region can apply hundreds of files concurrently. Therefore, data streaming through the object storage repository can achieve high throughput. In addition, both the source and target regions can operate at their own rates for uploads and downloads.

[0096] Whenever a user changes some data in source file system 280, a snapshot is taken and the deltas before and after the changes are updated. The changes can be accumulated on source file system 280 and streamed to object repository 260. Target file system 282 can detect that the data is available in object repository 260 and immediately download the changes and apply them to its file system. In some embodiments, only deltas are uploaded to the object storage device after the base snapshot.

[0097] In some embodiments, the replicator can communicate with many different regions (e.g., from Phoenix to Ashburn to other remote regions), and the file system can manage many different endpoints on the replicator. Each replicator 206 in the source file system 280 can keep a cache of these object storage device endpoints, and can also collaborate with the KMS250 to generate a transfer key (e.g., a session key) to encrypt the data address of the data in the object storage repository 260 (e.g., server-side encryption or SSE) to protect the data stored in the bucket. One master bucket is used for each AD in the target region. A bucket is a container that stores objects in a compartment within an object storage namespace (lease). All remote clients can communicate with the bucket and write information in a specific format so that the information of each file system can be uniquely identified to avoid mixing up data from different customers or file systems.

[0098] The object storage repository 260 is a high throughput system, and the techniques disclosed in the present disclosure can utilize the object storage repository. In some embodiments, the replication process has several pipeline stages, B-tree walks in the source file system 280, storage IO accesses, uploading data to the object storage repository 260, downloading data from the object storage repository 260, and incremental applications in the target file system 282. Each stage involves parallel processing threads to improve the performance of streaming data from the source area 290 to the target area 292 through the object storage repository 260.

[0099] In some embodiments, each file system in the source region can have a set of replicator threads 206a-n running in parallel to upload the increments to the object repository 260. Each file system in the target region can also have a set of replicator threads 216a-n running in parallel to download the increments from the object repository 260. Because the source and target sides operate concurrently and asynchronously, the source can upload as quickly as possible, and the target can start downloading as soon as the target detects that the increment is available in the object repository. The target file system then applies the increment to the latest snapshot and deletes the increment in the object repository after applying it. Therefore, the FSS takes up very little space in the object repository, and the object repository has a very high throughput (e.g., gigabytes of transfer).

[0100] In some embodiments, multiple threads also run in parallel to perform storage IO access (e.g., DASD) 204a-n and 214a-n. Therefore, all processing related to the replication process, including accessing the storage device, uploading the snapshot and data 230a from the source file system 280 to the object storage repository 260, and downloading the snapshot and data 230b to the target file system 282, has multiple threads running in parallel to perform data streaming.

[0101] File storage is an AD native service. When a file system is created, it is located in a specific AD. For customers to transfer or replicate data from one file system to another file system in the same region or in a different region, it may be necessary to use artifact (also known as manifest) transfer.

[0102] As an alternative to using an object repository to transfer data, VCN peering can be used to establish network connectivity between remote machines (e.g., between source and target replicator nodes) using Classless Inter-Domain Routing ("CIDR") for each region.

[0103] Reference again Figure 2 , the key management system (KMS) 250 is for the security of replication and provides storage services for cloud service providers (e.g., OCI). In some embodiments, the file system 280 on the source (or primary) side and the target (or secondary) side uses different KMS keys, and the key management is hierarchical. The reason for using different keys is that if the source is destroyed, the destroyer cannot use the same key to decrypt the target. FSS has a three-layer key architecture. Since the source and the target use different keys when transmitting data, the source needs to decrypt the data first, re-encrypt it with an intermediate key, and then re-encrypt the data on the target side. FSS defines a session, and each session is a data cycle. Create a key for the session to transmit data. In other words, a new key is used for each new session. In other embodiments, a key can be used for more than one session (e.g., more than one data transmission) before creating another key. No key is transmitted through the object repository 260, and the key is only available on the source side and is not visible outside the source for security reasons.

[0104] The replication cycle (also referred to as a session) is periodic and adjustable. For example, once an hour, the replicators (206a-n and 216a-n) perform replication. The cycle starts when a new snapshot is created in the source side 280, and ends when all deltas 230b have been applied in the target side 282 (i.e., the target reaches the DONE state). Each session is completed before another session is started. Therefore, only one session exists at any time, and there is no overlap between sessions.

[0105] Secret management (i.e., replication using KMS) utilizes KMS 250 to handle the transfer of secret materials between the source (primary) file system 290 and the target (or secondary) file system 292. The source file system 280 computes the delta, reads the file data, and then uses the local file system encryption key and cooperates with the key management service to decrypt the file data. The source file system 280 then generates a session key (called the delta encryption key (DEK)), encrypts it to become an encrypted session key (called the delta transfer key (DTK)), and transmits the DTK to the target file system 282 through their respective control planes 208 and 218. The source file system 280 also uses the DEK to encrypt data 230a and upload it to the object storage library 260 via the transport layer security (TLS) protocol. The object storage device library 260 then uses server-side encryption (SSE) to ensure the security of the stored data (e.g., deltas, manifests, and metadata) 230a.

[0106] The target file system 282 securely obtains the encrypted session key DTK through its control plane 218 (via cross-region API communication using HTTPS), decrypts it via KMS 250 to obtain the DEK, and places it somewhere in the target region 292. When a replication job is scheduled in the target file system 282, the DEK is provided to the replicator (one of the replication queues 216a-n), and the replicator uses the key to decrypt the data (e.g., including the delta of file data) 230b downloaded from the object repository 260 for the application, and re-encrypts the file data using its local file system key.

[0107] The replication between the source file system 280 and the target file system 282 is a concurrent process, and both the source file system 280 and the target file system 282 operate at their own pace. When the source side completes the upload (which may occur before the download process of the target), the source side cleans up its memory and removes all keys. When the target completes the application of the increment to its latest snapshot, it also cleans up its memory and removes all keys. The FSS service also releases the KMS key. In other words, there are two copies of the session key, one in the source file system 280 and the other in the target file system 282. Both copies are removed at the end of each session, and a new session key is generated in the next replication cycle. This process ensures that the same key is not used for different purposes. In addition, the session key is encrypted by the file system key to create double protection. This is to ensure that only a specific file system can use the session key.

[0108] Figure 3is a simplified schematic diagram of the components involved in cross-region remote replication according to certain embodiments. In certain embodiments, a component called delta generator (DG) 310 in source region A 302 and a component called 330 in target region B 304 are part of a replicator queue 318 and run on thousands of storage nodes in the queue. The replicator 318 in source region A makes a remote procedure call (RPC) (e.g., get key value set, lock block, etc.) to the delta generator 310 to collect B-tree keys and values ​​and data pages from a direct access storage device (DASD) 314, which is a replication storage service for accessing storage devices and is considered a data server. The DG 310 in source region A is an assistant to the replicator 318 for decomposing the key range of the delta and packing all the keys / values ​​of a given range into blobs to send back to the replicator 318. There are multiple storage nodes 322 and 342 attached to DASD 314 and 334 in both regions, with each node having many disks (e.g., 10TB or more).

[0109] In some embodiments, the file system communicators (FSCs) 312 and 332 in both zones are metadata servers that help update the source file system so that users can update the system. FSCs 312 and 332 are used for file system communication, and delta generator 310 is used for replication. DGs 310 and 330 and FSCs 312 and 332 are metadata servers. User traffic passes through FSCs 312 and 332 and DASDs 314 and 334, while replication traffic passes through the DG. In alternative embodiments, the functionality of the FSCs can be merged into the functionality of the DGs.

[0110] In some embodiments, the shared databases (SDBs) 316 and 336 of the two regions are key-value storage libraries, and the components of the control plane and the data plane (e.g., the replicator queue) can read and write through these key-value storage libraries to communicate with each other. The control planes 320 and 340 of the two regions can queue new jobs to their respective shared databases 316 and 336, and the replicator queues 318 and 338 can continuously read the queues in the shared databases 316 and 336, and once the replicator queues 318 and 338 detect the job request, the file system replication is started. In other words, the shared databases 316 and 336 are pipes between the replicator queues and the control plane. In addition, the shared databases 316 and 336 are distributed resources across different regions, and the IO traffic to / from the shared databases 316 and 336 should be minimized. Similarly, the IO traffic to / from the DASD needs to be minimized to avoid affecting the performance of the user. However, the replication process may be occasionally limited because it is an auxiliary service compared to the main service.

[0111] The replicator queue 318 in source region A can collaborate with DG 310 to start walking the B-tree in the file system in source region A to collect key values ​​and convert them into flat files or blobs to be uploaded to the object store. Once the data blobs (including key values ​​and actual data) are uploaded, the target can apply them immediately without waiting for a large number of blobs to exist in the object store 360. For disaster recovery reasons, the object store 360 ​​is located in the target region B. The goal is to push from the source to the target region B as quickly as possible and make the data safe.

[0112] There are many replicators that replicate thousands of file systems by optimizing space by utilizing low-cost machines with a small footprint, and scheduling as many replications as possible while ensuring that bandwidth is shared fairly between them. The replicator queues 318 and 338 in the two regions run on virtual machines that can automatically expand and shrink to build the entire queue for performing replication. The replicators and replication services can be dynamically adjusted based on the ability to support each job. If one replicator is overloaded, another can take over to share the load. The different replicators in the queue can balance the load between themselves to ensure that jobs can continue and do not stop due to overloading of individual replicators.

[0113] Figure 4 is a simplified flow chart illustrating steps performed during cross-region remote replication according to certain embodiments.

[0114] Step S1: When a customer sets up replication, the customer provides a source (or primary) file system (A) 402, a target (or secondary) file system (B) 404, and an RPO. The file system is uniquely identified by a file system identifier (e.g., Oracle Cloud ID or OCID), which is a globally unique identifier for the file system. Data is stored in the File Storage Service ("FSS") control plane database.

[0115] Step S2: The source (A) control plane (CP-A) 410 coordinates the creation of system snapshots regularly at a certain interval (less than the RPO) and notifies the data plane (including the replicator / uploader 412) of the latest snapshot and the last snapshot successfully copied to the target (B) file system 404.

[0116] Step S3: CP-A 410 notifies the replicator 412 (or uploader) as a component in the data plane to copy the latest snapshot:

[0117] S3a: The replicator 412 in the source (A) walks the B-tree to compute the delta between two given snapshots. The existing key infrastructure is used to decrypt the file system data.

[0118] S3b: These deltas 414 are uploaded to the object store 430 in the target (B) region (the data may be compressed and / or deduplicated during the copy). The upload may be performed in parallel by multiple replicator threads 412.

[0119] Step S4: CP-A 410 notifies the target (B) control plane (CP-B) 450 that the upload is complete.

[0120] Step S5: CP-B 450 calls target replicator-B 452 (or downloader) to apply the delta:

[0121] S5a: Replicator-B 452 downloads data 454 from object repository 430 .

[0122] S5b: Replicator-B 452 applies these deltas to the target file system (B).

[0123] Step S6: After the incremental application is completed, CP-A 410 is notified that a new snapshot is now available on the target (B).

[0124] Step 7: Cross-region remote replication processing repeats steps S2 to S6.

[0125] Figure 5 is a simplified diagram illustrating the high-level concepts of a B-tree walk according to certain embodiments. The B-tree structure can be used for a file system. An incremental generator walks the B-tree and ensures the consistency of the walk. In other words, the walk ensures that the key values ​​are as expected at the end of the walk and captures all information between any two snapshots so that data corruption does not occur. The file system is a transactional type of file system that can be modified, and the user needs to be aware of the modifications and redo transactions because another user may update the same transaction or data.

[0126] Keys and snapshots are immutable (i.e., they cannot be modified unless the garbage collector can remove them). Figure 5As shown in , there are many snapshots (Snapshot 1-Snapshot N) in the file system. When the incremental generator is visiting the B-tree keys (510-560) in the source file system, snapshots may be removed because the garbage collector 580 may be involved to clear the keys of snapshots that are considered garbage. When the incremental generator visits the B-tree keys, it needs to ensure that the keys associated with the remaining snapshots (e.g., not removed by the garbage collector) are copied. When the garbage collector 580 removes keys (e.g., 540 and 550), the B-tree pages may shrink, such as from two pages before the garbage collection to one page after the garbage collection. The way that the incremental generator can ensure consistency when visiting the B-tree keys is to confirm that the garbage collector 580 has not modified or deleted any keys of the page (or the portion between two snapshots) that the incremental generator just visited (e.g., between two keys). Once consistency is confirmed, the incremental generator collects the keys and sends them to the replicator for processing and upload.

[0127] B-tree keys can give a picture of the changes that have occurred. The techniques disclosed in this disclosure can determine which B-tree keys are new and which have been updated between two snapshots. The incremental generator can collect metadata parts, keys and values, and associated data, and then send them to the target. The target can determine that the received information is between the two snapshot ranges and applies to the target file system. After the incremental generator (or incremental generator thread) visits the portion between two keys and confirms its consistency, it uses the last end key as the next start key for its next visit. This process is repeated until all keys have been checked and the incremental generator collects the associated data after each confirmation of consistency.

[0128] For example, in a file system, when a file is modified (e.g., created, deleted, and then recreated), the process creates several versions of the corresponding file directory entry. During the replication process, the garbage collector may clean up (or remove) versions of the file directory entry corresponding to the deleted file and cause a consistency problem known as whiteout. Whiteout occurs if there is an inconsistency between the source file system and the target file system because the target file system may not be able to reconstruct the original snapshot chain involving the modified file. The disclosed technology can ensure consistency between the source file system and the target file system by detecting whiteout files (i.e., modified files affected by the garbage collector) during a B-tree walk, retrieving unaffected versions of the modified files, and providing relevant information to the target file system during the same replication cycle to properly reconstruct the correct snapshot chain.

[0129] Fig. 6A and Figure 6Bis a diagram illustrating pipeline stages of cross-region replication according to certain embodiments. The cross-region replication of the source file system disclosed in the present disclosure has four pipeline stages, namely, initiating cross-region replication in the source file system, performing B-tree visits in the source file system (i.e., incremental generation pipeline stage), storage IO access for retrieving data (i.e., data reading pipeline stage), and uploading data to the object repository (i.e., data upload pipeline stage). The target file system has similar four pipeline stages, but in reverse order, namely, preparing for cross-region replication, downloading data from the object repository, performing incremental application in the target file system, and storage IO access for storing data. Fig. 6A The diagram shows four pipeline stages in the source file system, but similar concepts apply to the target file system. Figure 6B The diagram illustrates the interactions between the processes and components involved in the pipeline stages. All of these pipeline stages can operate in parallel. Each pipeline stage can operate independently and hand over information to the next pipeline stage when the processing in the current stage is completed. It is ensured that each pipeline stage shares the entire bandwidth and does not use more bandwidth than necessary. In other words, resources are fairly distributed among all jobs. If no other jobs are working in the system, then the job that is working can get as many resources as possible.

[0130] The threads in each pipeline stage also execute their tasks in parallel (or concurrently) and independently of each other in the same pipeline stage (i.e., if a thread fails, it will not affect other threads). In addition, the tasks (or duplicate jobs) executed by the threads in each pipeline stage are restartable, which means that when a thread fails, a new thread (also called a replacement thread) can take over the failed thread to continue the original task from the last successful point.

[0131] In some embodiments, a B-tree walk can be performed in the source file system 280 using parallel processing threads. The B-tree in the file system can be divided into multiple key ranges between the first key and the last key. The number of key ranges can be determined by the client. Multiple range threads (e.g., approximately 8 to 16) for each file system can be used for B-tree walks. A range thread can perform a B-tree walk for a key range, and all range threads operate concurrently and in parallel. The number of threads to be used depends on factors such as the size of the file system, resource availability, and bandwidth to balance resources and traffic congestion. The number of key ranges is typically greater than the number of available range threads to make full use of the range threads. Therefore, B-tree walks can be scalable and can be handled by concurrent parallel walks (e.g., using multiple threads).

[0132] If after the incremental generator visits the page, some keys are inconsistent because some keys do not exist, the system can abandon the ongoing and uncommitted transaction and return to the starting point to visit again. During repeated B-tree visits due to inconsistencies, the incremental generator can ignore these keys by not collecting missing keys and their associated data to minimize the amount of information to be processed or uploaded to the target side because these associated data are considered garbage. Therefore, B-tree visits and data transfers can be more efficient. In addition, the incremental generator does not need to wait for the garbage collector to remove the information to be deleted before visiting the B-tree keys. For example, the keys have dependencies on each other. If a key or iNode points to a block that has been deleted or should be deleted by the garbage collector, the system (or incremental generator) can determine on its own that the particular block is garbage, and the incremental generator does not need to carry it.

[0133] The incremental generator usually does not modify anything on the source side (for example, it does not delete keys or data blocks that are considered garbage), but simply does not copy them to the target side. The B-tree walk process and garbage collection are asynchronous processes. For example, when the data block pointed to by a key no longer exists, the file system can mark the key as garbage and indicate that it should not be modified (for example, immutable), but only the garbage collector can remove it. The incremental generator can continue to walk the next key without waiting for the garbage collector. In other words, the incremental generator and garbage collector can proceed at their own pace.

[0134] exist Fig. 6A In FIG. 6 , when a source region initiates a cross-region replication process that may involve many file systems, the main threads 610a-n take over the replication jobs, one job for each file system. The main thread (e.g., 610a or 610 used later) of the file system in the source region (i.e., the source file system) is connected to the delta generator 620 (e.g., Figure 6B 620) to obtain the number of key ranges requested by the client and update the corresponding record in SDB 622. Once the main thread 610 of the source file system determines the number of key ranges required, it further creates a set of range threads 612a-n based on the number of key ranges required. These range threads 612a-n are executed by the delta generator 620. They initialize their GETKEYVAL buffers 640 ( Figure 6B ), updates the checkpoint record 642 in its SDB 622 ( Figure 6B ), and performs storage IO access 644 by interacting with DASD IO threads 614a-n.

[0135] In some embodiments, each master thread 610 is responsible for supervising all range threads 612a-n that it has created. During the replication, the master thread 610 can generate a master manifest file that summarizes the entire replication. The range threads 612a-n generate a range manifest file that includes the number of key ranges (i.e., subdivisions of the entire replication), and then generate a checkpoint manifest (CM) file for each range to provide the target file system with updates on the number of blobs for each checkpoint, where a checkpoint is created during a B-tree walk. A checkpoint is created by a range thread 612. Once the master thread 610 determines that all range threads 612a-n have completed, it creates a final checkpoint manifest (CM) file with an end-of-file marker, and then uploads the CM file to the object repository to allow the target file system to determine progress in the source file system. The CM file contains a summary of all individual ranges, such as range counts, the final status of the checkpoint record, and other information.

[0136] Range threads 612a-n are used for parallel processing to significantly reduce the time of B-tree visits for large source file systems. In some embodiments, B-tree keys are partitioned into ranges of approximately equal size. A range thread can perform a B-tree visit for a key range. The number of range threads 612a-n to be used depends on factors such as the size of the file system, resource availability and bandwidth to balance resources, the amount of data to be generated, and traffic congestion. The number of key ranges is typically greater than the number of available range threads 612a-n (approximately 2 to 4 times the ratio) to fully utilize the range threads. Each of the range threads 612a-n has a dedicated buffer (GETKEYVAL) 640 containing available jobs to be worked on. Each range thread 612 operates independently of other range threads and periodically updates the checkpoint record 642 in its SDB 622.

[0137] As the range threads 612a-n are walking the B-tree (i.e., recursively visiting each node of the B-tree), they may need to collect file data associated with the B-tree key (e.g., FMAP) and request IO access to the storage device 644. These IO requests are queued by each range thread 612 to allow the DASD IO threads 614a-n (i.e., the data read pipeline stage) to work on them. These DASD IO threads 614a-n are common threads shared by all range threads 612a-n. After the DASD IO threads 614a-n obtain the requested data, the data is placed in the output buffer 646 to be serialized into a blob for the object threads 616a-n (i.e., the data upload pipeline stage) of the replicator to upload to the object storage repository located in the target area. Each object thread will pick up an upload job that may contain a portion of all the data to be uploaded, and all object threads perform the upload in parallel.

[0138] Figure 7 is a diagram illustrating a layered structure in the FSS data plane according to some embodiments. Figure 7 , the replicator queue 710 has four layers, namely, the job layer 712, the incremental generator client 714, the encryption / DASD IO 716, and the object 718. The replicator queue 710 is a single process responsible for interacting with the storage queue 720, the KMS 730, and the object repository 740. In some embodiments, the job layer 712 polls the SDB 704 to find the queued job 706, whether it is an upload job or a download job. The replicator queue 710 includes a VM (or thread) that picks up the queued replication job according to its maximum capacity. Sometimes, a replicator thread may own a part of the replication job, but it will cooperate with another replicator thread that owns the rest of the same replication job to complete the entire replication job concurrently. The replication job performed by the replicator queue 710 is restartable because if a replicator thread fails in the middle of replication, another replicator thread can take over and continue to complete the job originally owned by the failed replicator thread from the last successful point. If a stray replicator thread (eg, crashes and wakes up again) conflicts with another replicator thread, the FSS can use a mechanism called generation numbering to avoid the conflict by having the two replicator threads update different records.

[0139] The delta generator client layer 714 performs a B-tree walk by accessing the delta generator server 724 where the B-tree is located in the storage queue 720. The encryption / DASD IO layer 716 is responsible for security and storage access. After the B-tree walk, the replicator queue 710 can request IO access through the encryption / DASD IO layer 716 to access the DASD extension 722 to obtain the file data associated with the delta identified during the B-tree walk. Both the replicator queue 710 and the storage queue 720 periodically update their status (e.g., checkpoints and leases of the replicator queue 710) to the control API 702 through the SDB 704 to allow the control API 702 to trigger alarms or take actions when necessary.

[0140] The encryption / DASD IO layer 716 interacts with the KMS and FSK queue 730 on the target side to create session keys (or snapshot encryption keys) during the cross-region replication process and encrypt and decrypt the session keys using FSK. Finally, the object layer 718 is responsible for uploading delta and file data from the source file system to the object repository 740 and downloading them from the object repository 740 to the target file system.

[0141] The data plane of FSS is responsible for incremental generation. The data plane uses B-tree to store FSS data, and the B-tree has different types of key-value pairs, including but not limited to leader blocks, super blocks, iNodes, file name keys, cookie maps (cookies associated with directory entries), and block maps (for file content data, also known as FMAP).

[0142] These B-tree keys are processed jointly by the replicator and delta generator in the data plane. The algorithm used to calculate the key-value pairs that have changed between two given snapshots in the file system (i.e., part of the delta) can continuously read the keys and return the keys to the replicator using the transaction budget and ensure that the transaction is confirmed at the end to obtain consistent key-value pairs for processing.

[0143] In other embodiments, the delta generation and calculation can be scalable. A scalable method can utilize multiple threads to calculate the delta (i.e., the change in key-value pairs) between two snapshots by dividing the B-tree into multiple key ranges. A pool of threads (i.e., delta generators) can perform scans of the B-tree (i.e., walk the B-tree) and calculate deltas in parallel.

[0144] Figure 8Depicted is a simplified example binary large object (BLOB) format according to certain embodiments. A blob is a data type used to store information (e.g., binary data) in a database. The blob is generated by the source region during replication and uploaded to the object repository. The target region needs to download and apply the blob. Depending on the context, blob and object can be used interchangeably.

[0145] During the B-tree walk, when the delta generator encounters the iNode and its block map (also called FMAP, data associated with the B-tree key) for a given file (i.e., data content), the delta generator cooperates with the replicator to traverse all pages in the blocks (FMAP blocks) within the DASD range pointed to by the FMAP and read them into the data buffer, decrypt the data using the local encryption file key, and put it into the output buffer to serialize it into a blob for the replicator to upload to the object store. In other words, the delta generator needs to collect all the FMAPs of the identified deltas to obtain all the data related to the difference between the two snapshots.

[0146] The snapshot deltas stored in the object store may span many blobs (or objects if stored in an object store). The blob format for these blobs has a key, a value, and the data associated with the key (if any). For example, in Figure 8 , the snapshot increment 800 includes at least three blobs 802, 804, and 806. The first blob 802 has a prefix 810 indicating the key value type, key length, and value length, followed by its key 812 (key1) and value 814 (val1). The second blob 804 has a prefix 820 (key value type, key length, and value length), a key 822 (key2), a value 824 (val2), a data length 826, and data 828 (data2). In the prefix 820 of the second blob 804, its key value type is fmap because the blob has additional data 828 associated with the key 822. The third blob 830 has a similar format to the first blob 810, for example, a prefix 830, a key 832 (key3), and a value 834 (val3).

[0147] The data is decrypted, collected, and then written to a blob. All processing is performed in parallel. Multiple blobs can be processed and updated at the same time. Once all processing is complete, the data can be written to the blob format ( Figure 8 ), and then upload to the object repository using the format or path name ( Fig. 9 (see figure in the figure).

[0148] Fig. 9An example replication bucket format according to certain embodiments is depicted. A "bucket" may refer to a container that stores objects in a compartment within an object storage namespace. In certain embodiments, the source replicator uses buckets to store secure data using server-side encryption (SSE) technology, and the target replicator also uses buckets to download to apply changes to snapshots. The replication data of all file systems of a target region may share buckets in that region.

[0149] The data layout of a bucket in an object store has a directory structure that includes, but is not limited to, a file system ID (e.g., Oracle Cloud ID), an increment with a starting snapshot number and an ending snapshot number, a manifest describing the information content in the object layout, and a blob. For example, Fig. 9 The bucket in contains two objects 910 and 930. The first object 910 has two deltas 912 and 920. It starts with a path name 911 prefixed with the source file system ID (e.g., ocid1.filesystem.oc1.iad....), the first delta 912 is generated from snapshot 1 and snapshot 2, and the second snapshot 920 is generated from snapshot 2 and snapshot 3. Each delta has one or more blobs representing the content of the delta. For the first delta 912, it has two blobs 914 and 916 stored in the order in which they were generated. For the second delta 920, it has only one blob 922. Each delta also has a manifest describing the content of the information in the layout of the delta, for example, manifest 918 for the first delta 912 and manifest 924 for the second delta 920. The manifest in the bucket is the content that describes the delta (e.g., file system number and snapshot range, etc.). The manifest can be a master manifest, a range manifest, or a checkpoint manifest, depending on the stage of the replication process.

[0150] The second object 930 also contains two deltas 932 and 940 with a similar format, beginning with a path name 931. The two objects 910 and 930 in the bucket come from different source regions, object 910 is IAD, and object 930 is PHX. Once the blob is applied, the corresponding information in the layout can be removed to reduce space usage.

[0151] The final manifest object (i.e., checkpoint manifest, CM file) is uploaded from the source region to the object repository to indicate to the target region that the source file system has completed the snapshot incremental upload of a specific object. The source CP will communicate this event to the target CP, where the target CP can notify the target DP via SDB to trigger the target replicator to download the object.

[0152] The control plane in the source or target region coordinates all replication workflows and drives the replication of data. The control plane performs the following functions: 1) creates system snapshots that serve as the basis for creating deltas; 2) decides when such snapshots need to be created; 3) initiates replication based on snapshots; 4) monitors replication; 5) triggers the secondary (or target) side to download deltas; and 6) indicates to the primary (or source) side that the snapshot has arrived on the secondary side.

[0153] The file system has several operations to handle its resources, including but not limited to create, read, update, and delete (CRUD). These operations are usually synchronous within the same region and occupy the workflow when the file system gets an HTTPS request from the API server, makes changes in the backend to create resources, and returns responses to customers. Resources are split between the source and target regions. The state of the same resource is maintained between the source and target regions. Therefore, there is asynchronous communication between the source and target regions. Customers can contact the source region to create or update resources, which can be automatically reflected to secondary or auxiliary resources in the target region. The state machine in the control plane also covers many aspects of recovery, including but not limited to failures in queues, key management failures, disk failures, and object failures.

[0154] Turning to the application programming interface (API) in the control plane, there are different APIs for users to configure replication. The control API for any new resource only works in the region where the object is created. In the target file system, a field called "IsTargetable" in its API can be set to ensure that the target file system that is undergoing replication cannot be accidentally used by consumers. In other words, setting this field to false means that although consumers can see the target file system, no one can export the target file system or access any data in the live system. Any export may change the data because export is a read / write permission for exports, not a read-only permission. Therefore, exports are not allowed to prevent any changes to the target file system during the replication process. Consumers can only access data in old snapshots that have already been replicated. All newly created or cloned file systems can set this field to true. The reason is that the target can only get data from a single source. Otherwise, conflicts may occur when writing or deleting data. The system needs to know if the target file system being used is already part of some replication. The "true" setting of the "IsTargetable" field means that there is no ongoing replication, and the "false" setting means that the target file system cannot be used.

[0155] Regarding cross-region communication between control plane components, the primary resource on the source file system is called an application, and the backup (or secondary) source on the target file system is called an application target. When the source object and the target object are created, they have a single replication relationship. Both objects can only be updated from the source side, including changing compartments, editing, or deleting details. When the user wants to delete the target side, the replication can delete itself. For planned failover, the source side can be deleted, and both the source side and the target replication are deleted. For unplanned failover, the source side is unavailable, so only the target replication can be deleted. In other words, there are two resources for a single replication, and they should be kept in sync. There are various workflows for updating metadata on both the source and target sides. In addition, retries, fault handling, and cross-region APIs for failover are also part of the cross-region communication processing.

[0156] When the source creates the necessary security and other related artifacts, it uploads the security and artifacts to the object repository and initiates a job on the target (i.e., notifies the target that the job is available), and the target can begin downloading the artifacts (e.g., snapshots or deltas). Thereafter, the target continues to look for an end-of-file marker (also referred to herein as a checkpoint manifest (CM) file) in the object repository. The CM file is used as a mechanism for the source and target sides to communicate the completion of object uploads during the replication process. At each checkpoint, the source side uploads the CM file, which contains information (such as the number of blobs uploaded so far this checkpoint) so that the target side can download that number of blobs to apply to its current snapshot. The CM file is a mechanism for the source side to communicate to the target side that the upload of an object to the object repository is complete so that the target can begin working on the object. In other words, the target will continue downloading until there are no objects in the object storage device. Therefore, this scheme enables concurrent processing on the source and target sides.

[0157] Fig.10 is a flow chart illustrating a state machine for concurrent source upload and target download according to some embodiments. As previously discussed, both the source file system and the target system can perform replication concurrently and therefore have their own state machines. In some embodiments, each file system can have its own state machine while sharing some common job-level states. Fig.10 In the example, the source file system has states 1002 to 1018 for performing data uploads and states 1030 to 1034 for session key generation and transfer. The target file system has states 1050 to 1068 for data downloads. Session keys can be generated at any time in the source file system when uploading increments to the object storage device. Therefore, session key transfer has its own sequence of states 1030 to 1034. Fig.10In the example, the target file system can start the replication download process (i.e., Ready_to_Reconcile state 1050) only after it receives the following indications: at least one object has been uploaded to the object storage device by the source file system (i.e., Mainfest_Copied state 1014) and the session key is ready for its download (i.e., Copied_DTK state 1034).

[0158] In the source file system, several functional blocks such as snapshot generator, control API and incremental monitor are part of CP. The replicator queue is part of DP. The snapshot generator is responsible for periodically generating snapshots. The incremental monitor periodically monitors the progress of the replicator on replication-related tasks, including snapshot creation and replication scheduling. Once the incremental monitor detects that the replicator has completed the replication job, it moves the state to the copied state on the source side (e.g., the copied list state 1014) or the replicated state on the target side (e.g., the replicated (Replicated) state 1058). In some embodiments, several file systems can perform replication from the source area to the target area at the same time.

[0159] refer to Fig.10 In some embodiments, the source file system is in a concurrent mode state machine, and the snapshot generator sends a signal to the incremental monitor that the snapshot has been generated after creating the snapshot. The incremental monitor running the CP replication state (CpRpSt) workflow is responsible for initiating the upload of the snapshot metadata to the object repository on the target side. The snapshot metadata may include the snapshot type, snapshot identification information, snapshot time, etc. The CpRpSt workflow sets the Ready_to_Copy_Metadata state 1002 so that the replicator queue starts copying the metadata. When the replicator obtains the replication job, it makes copies of the snapshot metadata (i.e., the Snapshot_Metadata_Copying state 1004) and uploads these copies to the object repository. When all replicators complete the snapshot metadata upload, the state is set to the Snapshot_Metadata_Copied state 1006. The CpRpSt workflow then continues to poll the source SDB to obtain the session key.

[0160] The CpRtSt workflow now hands control back to the delta monitor to monitor the delta upload process, thereby entering the Ready_to_Copy state 1008, which indicates that the delta calculation has been scheduled. The source CP API then sends a request to the replicator to start the next stage of replication by making a copy of the manifest and uploading the delta. The replicator that takes over the replication job can start making a copy of the manifest (i.e., Mainfest_Copying state 1010). When the source file system completes the manifest copy, it moves to the Manifest_Copied state 1014, and notifies the target file system that it can start its internal state (Ready to Reconcile state 1050).

[0161] As discussed above, the source file system can generate a session key while data upload is in progress. The source file system's replicator communicates with the target KMS vault to obtain a master key (which can be provided by the customer) to create a session key (referred to herein as an incremental encryption key or DEK). The replicator then encrypts the session key (now becoming an encrypted DEK, also referred to herein as an incremental transfer key (DTK)) using the local file system key (FSK). The DTK is then stored in the SDB in the source region for reuse by the replicator thread during the replication cycle. The state machine moves to the Ready_to_Copy_DTK state 1030.

[0162] The source file system transmits the DTK and the resource identifier of the KMS to the target API, which then places them into the SDB in the target area. During this transfer process, the state machine is set to the Copying_DTK state 1032. When the CpRpSt workflow in the source file system completes polling the source SDB to obtain the session key, it sends a notification to the target side, signaling that the session key (DTK) is ready for the target file system to download and use it to decrypt its downloaded increments for application. The state machine then moves to the Copied_DTK state 1034. The target side replicator retrieves the DTK from its SDB and requests the KMS's API to decrypt it to become a plain text DEK (i.e., the decrypted session key).

[0163] When the source file system completes uploading data for a particular replication cycle (including session key transfer), its delta monitor notifies the target control API of the status such as verification information and enters the cross-region copy completed (X-region_Copied_Done) state 1016. This may occur before the target file system completes downloading and applying the data. The source file system also cleans up its memory and removes all keys. The source file system then enters the waiting target response (Awaiting_Target_Response) state 1018 to wait for a response from the target file system to start a new replication cycle.

[0164] As mentioned previously, the target file system can only start the copy download process after it receives an indication that the source file system has uploaded at least one object to the object storage device (i.e., the copied manifest state 1014) and the session key is ready for its download (i.e., the copied DTK state 1034). Once these two conditions are met, the state machine moves to the ready to reconcile state 1050. Then, at the reconciling state 1052, the target file system begins the reconciliation process with the source side, such as synchronizing snapshots of the source file system and the target file system, and performing some internal CP management work, including taking snapshots and generating statistics. This internal state involves communication between the target file system's internal delta monitor and the CP API.

[0165] After the reconciliation process is complete, the replication job is passed to the target replicator (i.e., Ready_to_Replicate state 1054). The target replicator monitors the checkpoint manifest (CM) file to be uploaded by the source file system. The CM file is marked by the target. The target replicator thread then starts downloading the manifest and applying the downloaded and decrypted deltas (i.e., Replicating state 1056). The target replicator thread also reads the FMAP data blocks from the blob downloaded from the object repository and communicates with the local FSK service to obtain the file system key FSK, which is used to re-encrypt each FMAP data block and store it in its local storage.

[0166] If the source file system has completed uploading the data, it will update the final CM file by setting the end of file (eof) field to true and upload it to the object repository. Once the target file system detects the final CM file, it will complete the download of the blobs, apply them, and the state machine moves to the copied state 1058.

[0167] After the target file system has applied all deltas (or blobs), it proceeds to download snapshot metadata from the object repository and populate the target file system's snapshot with information from the source file system's snapshot (i.e., the Snapshot_metadata_Populating state 1060). Once the target file system's snapshot is populated, the state machine moves to the Snapshot_Metadata_Populated state 1062.

[0168] In the Snapshot_Deleting state 1064, the target file system deletes all blobs in the object store that have been downloaded and applied to its latest snapshot. Once the blobs in the object store have been deleted, the target control API will notify the target delta monitor and proceed to the Snapshot_Deleted state 1066. The target file system will also clean up its storage and remove all keys. The FSS service will also release the KMS key.

[0169] When the target DP completes the incremental apply and cleanup, it verifies the status of the source file system with the target control API and whether it has received the cross-region copy completed (X-region_Copied_Done) notification from the source file system. If the notification has been received, the target incremental monitor enters the cross-region completed (X-region DONE) state 1068 and sends the cross-region completed notification to the source file system. In some embodiments, the target file system can also detect whether the source file system has completed the upload by checking whether the file end exists in all key ranges and all upload processing threads, because each object uploaded to the object repository has a special marker, such as the file end marker in the CM file.

[0170] Referring again to the source file system state machine, when the source file system is in the Waiting for Target Response state 1018, it checks whether the target CP's state has changed to Complete to indicate that the target has applied all downloaded deltas and the file data has been stored locally. If so, this ends the replication cycle.

[0171] The source and target sides operate asynchronously. When the source file system completes its replication upload, it notifies the target control API using a cross-region copy completion notification. When the target file system subsequently completes its replication process, its delta monitoring target communicates back to the source control API using a cross-region completion notification. The source file system returns the ready to copy metadata state 1002 to start another replication cycle.

[0172] Fig.111101 is an example flow chart illustrating the interaction between the data plane and the control plane in the source region according to some embodiments. The data plane components and the control plane components communicate with each other using a shared database (SDB) (e.g., 1106). The SDB is a key-value storage repository that both the control plane components and the data plane components can read and write. The data plane components include a replicator and an incremental generator. The interaction between components in the source region A 1101 and the target region B 1102 is also illustrated.

[0173] exist Fig.11 In step S1, the source control plane (CPa) 1103 requests the object repository in the target region B (OSb) 1112 to create a bucket. At step S2, the source replicator (replicator a) 1108 periodically updates its heartbeat status to the source SDB (SDBa) 1106. Heartbeat is a concept used to track the progress of replication performed by the replicator. It uses a mechanism called leasing, where the replicator can continuously update the heartbeat whenever it works on a job to allow the control plane to understand the entire lease information; for example, the byte count keeps moving on the job. If the replicator fails to work properly, the heartbeat may become stale, and then another replicator can detect and take over to continue working on the legacy job. Therefore, if the system crashes midway, the system can start accurately from the last point in time based on the checkpoint mechanism. Checkpoints help the system know where the last point of progress was, allowing it to continue from that point without having to re-execute the entire job.

[0174] At step S3, CPa 1103 also requests the file system service workflow (FSW_CPa) 1104 to create snapshots periodically, and at step S4, FSW_CPa 1104 notifies CPa 1103 of the new snapshot. At step S5, CPa 1103 then stores the snapshot information in SDBa1106. At step S6, replicator a 1108 polls SDB 1106 to find any changes to the existing snapshot, and retrieves the job specification at step S7 if a change is detected. At step S8, once replicator a 1108 detects a change to the snapshot, this will trigger the replication process. At step S8, replicator a 1108 provides information about the two snapshots (SNa and SNb) and the changes between them to the incremental generator (DGa) 1110. At step S9, replicator a 1108 puts work item information (such as the number of key ranges) into SDBa1106. At step 10, replicator a 1108 checks the replication job queue in SDBa 1106 for work items, and assigns them to the delta generator (DGa) 1110 to scan the B-tree keys of the snapshot (i.e., walk the B-tree) to calculate the deltas and corresponding key-value pairs at step S11. At step 12, replicator a 1108 decrypts the file data associated with the identified B-tree keys and packages them into blobs along with the key-value pairs. At step 13, replicator a 1108 encrypts the blobs using the session key and uploads them as objects to OSb 1112. At step S14, replicator a performs a checkpoint and stores the checkpoint record in SDBa 1106. This replication process (S8 to S14) repeats (as a loop) until all deltas have been identified and the data uploaded to OSb 1112. The replicator a 1108 then notifies the SDBa 1106 of the replication job details at step S15, which are then passed to the CPa 1103 at step S16 and further relayed as a final CM file to the CPb 1114 at step S17. The CPb 1114 stores the job details in the SDBb 1116 at step S18.

[0175] The interaction between the data plane and the control plane in the target region B is similar. At the end of applying the delta to the target file system, the control plane in the target region B notifies the control plane in the source region A that the snapshot has been successfully applied. This enables the control plane in the source region A to start over with the new snapshot.

[0176] Authentication is performed on each component. From the replicator to the file system key (FSK), there is an authentication mechanism that uses the replication ID and the file system number. The key can be provided to the replicator only when the replicator provides the correct content. Therefore, the authentication mechanism can prevent imposters from obtaining decryption keys. Other security mechanisms include shielding network ports. A component called the File System Key Server (FSKS) is a gatekeeper for checking the occupant requester by checking metadata (such as the job and other information that the requester will perform). For example, suppose a replicator tries to request a key for a file system. In this case, the FSKS can check whether the replicator is associated with a specific job (for example, a replication that is actually associated with the file system) to verify the requester.

[0177] Availability addresses situations where a machine can automatically restart after an outage or where services continue to be available while software deployments are in progress. For example, all replicators are stateless, so losing a replicator is transparent to the client because another replicator can take over and continue working on the job. The state of the job is saved in a shared database and other reliable locations, not locally. The shared database is a database-like service used by the control plane to keep information about the file system, and is based on B-trees.

[0178] The storage availability in the FSS of the present disclosure is high because the system has thousands of storage nodes to allow any storage node to perform incremental replication. The control plane availability is high by utilizing many machines that can take over each other in the event of any failure. For example, the replication progress will not be hindered simply because of the failure of one control plane. Therefore, there is no single point of failure. Network access availability utilizes congestion management involving various types of throttling to ensure that the source node is not overloaded.

[0179] Replication achieves durability by leveraging checkpoints, where the replication state is written to a shared database, and the replicator is stateless. The replication process is idempotent. Idempotence can refer to deterministic reapply, i.e., when an operation fails, a retry of the same operation should work and lead to the same result, using, for example, the same key, upload process, or walk process.

[0180] Operations in several areas are idempotent. In the control plane, there is a need to remember actions that have been taken. For example, if an HTTP request repeats itself, an idempotent cache can help remember that a particular operation has been performed and is the same operation. In the data plane, for example, when a block is allocated, the block and the file system file mapping key are written together. Therefore, when the block is allocated again, it can be identified. If the block has been sealed, the write operation will fail. The idempotent mechanism can know that the block has been sealed in the past and the write operation does not need to be redone. In yet another example, the idempotent mechanism remembers the chain of steps that need to be performed for a particular key value processing. In other words, the idempotent mechanism allows each operation to be checked to see if it is in the correct state. Therefore, the system can move directly to the next step without repeating.

[0181] When a snapshot is rolled back from snapshot 10 to snapshot 5, atomic replay allows the application of deltas to begin as soon as the first delta object arrives at the object store. To make the replay atomic, the entire delta needs to be kept in the object store before it can be applied.

[0182] With respect to scaling of replicators, the FSS of the present disclosure allows as many replication machines (e.g., replicator virtual machines ("VMs")) to be added as needed to support many file systems. The number of replicators can be dynamically increased or decreased, taking into account bandwidth requirements and resource availability. With respect to scaling of storage, thousands of storage devices can be used to parallelize processing and increase work speed. With respect to inter-region bandwidth, bandwidth rationing ensures that each workload does not overuse or exceed its predefined throughput limit through automatic throttling (such as throttling all inter-region bandwidth by determining latency increases and slowing down requests). All replicator processors (or threads) have this capability.

[0183] For the checkpoint storage extension, the uploader and downloader record their progress as checkpoints to persistent storage, and the shared storage is used as a work queue for splitting key ranges. If the checkpoint workload overwhelms the shared database, then the checkpoint storage capability can be added to the incremental generator for scaling purposes. Current shared database workloads may consume less than 10 IOPs.

[0184] End-to-end restartability of cross-region replication

[0185] Synchronization between source and target zones

[0186] In cross-region replication, the source file system and the target file system operate asynchronously by uploading data from the source FS to the object repository and downloading data from the object repository to the target FS. In addition, the upload and download operations are performed by threads running asynchronously and in parallel. The technology disclosed in the present disclosure attempts to synchronize these asynchronous replication related operations, such as incremental generation, upload, download, incremental application, and resource cleanup, by using two sets of states in two state machines. In some embodiments, cross-region APIs and state machines in both the source region and the target region are used to ensure synchronization between the two regions. Fig.10 The state machine flow diagram described in is for concurrent source region uploads and target region downloads during normal cross-region operations. Fig.10 The state machine described in is called the incremental state machine. The incremental state machine is an internal FSS construct that is not visible to the customer and is used for functions such as job ownership between multiple microservices CPs and DPs (excluding object repositories that are considered resources) and the sequence of actions taken for jobs related to incremental applications / incremental applications in both the source file system and the target file system. Another state machine called the lifecycle state machine is a resource-level construct visible to the customer, such as resource management and resource utilization, including creating, deleting, and pausing resources. Each resource of a cloud infrastructure (such as Oracle Cloud Infrastructure (OCI)) may have the same standard lifecycle state. Only the CP of a region (or file system) maintains this lifecycle state machine.

[0187] Fig.12 is a flow chart illustrating a state machine of a control plane of a file system according to some embodiments. Fig.12 , a client 1202 may issue a request 1240 to create a cross-region replication between a source file system and a target file system, which triggers the lifecycle state to enter the CREATING state 1204. The FSS may begin replication creation processing 1242, including allocating spare resources in the target region to create the target file system. Once the resource allocation in the target region is complete and the FSS can perform the cross-region replication, the state changes to the ACTIVE state 1212. In some embodiments, during the replication creation process, if the source file system and the target file system cannot recognize a common snapshot (e.g., 1244) as a base snapshot and the target file system is not empty, the replication creation process may not be able to proceed. In the source file system, the state may change from CREATING to FAILED 1210.

[0188] In some embodiments, during cross-region replication, if any problems (e.g., 1250) occur during replication, such as cross-region connectivity problems, the FSS may change to the NEED_ATTENTION state 1214. Once the problem has been resolved, the state may transition back to the active state 1212.

[0189] In some embodiments, if the replication process stops for some reason (e.g., 1252) and cannot proceed, the lifecycle state can change from active state 1212 to failed state 1210. In the source region, this may occur when the target file system deletes the cross-region replication (i.e., replication deletion). Therefore, the customer may need to clean up the source file system accordingly, and the source file system can change its state to failed. In another embodiment, if the customer disables its KMS key in the vault, the source file system can also set its state to failed.

[0190] In some embodiments, when a customer requests to delete an existing cross-region replication of a file system in a particular region (e.g., 1260), the CP of the file system may transition to a DELETING state 1220. A replication deletion request for a file system in a source region may trigger resource cleanup in both the source and target regions. After the cleanup is complete (e.g., 1262), depending on the region involved, the lifecycle state of the affected file system in the region may change to a DELETED state 1222. If the source file system is currently in a failed state 1210, the customer may request to clean up resources in the source file system. As a result, the state may change from a failed state 1210 to a DELETING state 1220, and then to a DELETED state 1222 after the cleanup is complete.

[0191] Each region has CP, DP, checkpoints, and metadata. The CP and DP in a region may need to be synchronized first. The CP and DP can be synchronized by using a shared database (SDB). Fig.11 As shown in , the source CP (CPa or can also be expressed as a control API) and the source DP, including the replicator (replicator a) and the incremental generator (DGa), can communicate with each other through the source SDB (SDBa) to synchronize the replication progress, for example, the status of incremental generation and incremental upload. Similar mechanisms also apply to the target area, target CP and target DP. In other words, the target CP and the target DP can communicate with each other through the source SDB (SDBa) to synchronize the replication progress, for example, incremental application and incremental download.

[0192] Source ID

[0193] A technology called provenance ID can be used to efficiently identify common snapshots between the source file system and the target file system. Provenance ID is a special identifier that uniquely identifies a snapshot among regions, whether it is a system snapshot or a user snapshot. Assume that two file systems have the same provenance ID for a particular snapshot. In this case, this means that the snapshots in each of the two file systems are very similar up to that time, or have a common ancestor, or have the same known point in time, and can be used as the base snapshot for cross-region (or X-region) replication. Provenance ID applies to both system snapshots and user snapshots. Therefore, the provenance ID technology saves valuable cloud resources while reducing network and IO traffic for performing cross-region replication.

[0194] A snapshot is a point-in-time picture of a file system and is immutable (i.e., not writable). A snapshot can have two types of duplicates: a clone or a replica. A clone can be called a writable snapshot and is typically created in the same region. When a clone is created, each clone can be written to independently using its IO. All these clones have the same lineage. If a clone is created between two file systems, then both file systems share the same copy of the snapshot for reading. A separate copy is created only when one of the file systems needs to write to the clone. A replica is a duplicate snapshot created in a different region (i.e., across regions or different data centers) by the replication process.

[0195] Replicas and clones can differ in that replicas are implemented by first copying the full data from the source region to the target region, and then copying the deltas between snapshots. Clones, on the other hand, only copy the data needed to create a thin client. In-region cloning is much faster than cross-region replication because cloning does not involve additional encryption / decryption, object storage device transfers, and many pipeline stages required for replication. Once a clone is created, it does not receive more changes in the future, so it only gets a point-in-time snapshot.

[0196] In some embodiments, each snapshot may have three pieces of information associated with the snapshot, namely, a snapshot number (snapNum), a provenance ID (ProvID or PID), and a resource ID (e.g., OCID). The resource ID is a globally unique ID used to identify a resource because snapshots consume resources. The snapshot number is used for internal management purposes and for tracking purposes in the file system. The provenance ID is used for external purposes and is unique between all snapshots (in a region or across regions). The provenance ID is set at the time the snapshot is created and does not change when the snapshot is cloned or copied. Together, these three pieces of information can uniquely identify the history of the snapshot (e.g., the parent-child relationship between all snapshots) and distinguish the snapshot from other resources in the cloud infrastructure. In addition, the file system number (FS#) helps track clones in a region and replicas across regions. Between different regions, the provenance ID helps track the history of snapshots by carrying the provenance ID of the original parent snapshot.

[0197] In some embodiments, before replication begins, the source FS and the target FS may compare the provenance IDs of their respective snapshots to find a matching pair of snapshots. If a particular pair of snapshots has the same provenance ID, the source FS and the target FS may start replication from the identified pair without transferring the entire base snapshot copy from the source FS to the target FS when replication begins. As a result, this saves resources and avoids traffic associated with data transfer. For example, assume that the previous replication between the source FS and the target FS has replicated snapshots S1 to S100 and then stopped. After a while, the two file systems plan to perform another replication, and they need to calculate the starting point of this new replication. Assume that the source FS is already in snapshot S200. In this case, it can compare the provenance ID of its snapshot from S200 to S1 in reverse with the provenance ID of the last snapshot of the target FS (the comparison process is also referred to as tracing in this article), and find that S100 in both the source FS and the target FS is a matching pair. At this point, S100 can be used as the starting point (i.e., the base snapshot) for the new replication process in the source file system and the target file system. The source FS can calculate the delta between snapshot S100 (i.e., base snapshot) and snapshot 200 (i.e., new snapshot), and then transfer the delta to the target FS, which can apply them to its S100 to create S200 in the target FS. The source FS does not need to transfer snapshot 100 again to the target FS as a base snapshot copy for the replication process to start. This saves a lot of data and IO transfers.

[0198] In some embodiments, if the snapshot to be copied from the source region already exists in the target region but not in the target FS, the provenance ID can be useful to all file systems in the same region by cloning the snapshot from another file system to the target FS in the same target region. This can be done in Fig.13Shown in.

[0199] Fig.13 is a diagram illustrating an example use of a provenance ID according to some embodiments. Fig.13 In step 1310, FSS creates clones for the three snapshots snapNum1 / ProvID S1 / OCID S1, snapNum 2 / ProvID S2 / OCID S2, and snapNum3 / ProvID S3 / OCID S3 of the file system FS1 in the same zone 1 to become snapshots snapNum 1 / ProvID S1 / OCID K1, snapNum 2 / ProvID S2 / OCID K2, and snapNum 3 / ProvID S3 / OCID K3 of the file system FS2. In addition, a new snapshot snapNum 5 / ProvID K5 / OCID K5 is created in FS2. The clones in FS2 have different resource IDs (S* becomes K*) because they use different resources in the same zone. Note that snapshot 4 of FS1 is not cloned.

[0200] FSS then creates replicas for snapshots 1, 2, 3, and 5 of file system FS2 (i.e., step 1320) to become snapNum 1 / ProvID S1 / OCID M1, snapNum 2 / ProvID S2 / OCID M2, snapNum 3 / ProvID S3 / OCID M3, and snapNum 5 / ProvID K5 / OCID M5 of file system FS3 in region 2. Thereafter, the replica is deleted after snapNum5 is replicated (i.e., step 1322), meaning that region 1 and region 2 are no longer communicating. In addition, snapshots snapNum6 / ProvID G6 / OCID M6 and snapNum 7 / ProvID G7 / OCID M7 are subsequently created in FS3 in region 2.

[0201] Some time later, FSS attempts to perform a copy of snapshots 1, 2, 3, and 7 of FS3 in region 2 to FS4 in region 1 (i.e., creating a replica at step 1330). Since FS4 (i.e., the target FS) does not exist in region 1, but FS1 (i.e., the non-target FS) already exists in the same region, before the copy, FS3 in region 2 and FS1 in region 1 compare the provenance IDs of their snapshots (i.e., step 1340). The comparison may find that snapshots 1, 2, and 3 of FS3 have the same provenance IDs (S1, S2, and S3) as snapshots 1, 2, and 3 of FS1 in region 1. Therefore, in order to save resources and network bandwidth, FS1 located in the same area 1 as FS4 can first create clones of snapshots 1, 2 and 3 (snapNum 1 / ProvID S1 / OCID S1, snapNum 2 / ProvIDS2 / OCID S2, and snapNum 3 / ProvID S3 / OCID S3) of FS1 (i.e., step 1342) to become the base copies of snapshots (snapNum 1 / ProvID S1 / OCID P1, snapNum 2 / ProvID S2 / OCID P2, and snapNum 3 / ProvID S3 / OCID P3) of FS4 in the same area 1. Thereafter, FS3 only needs to replicate (i.e., step 1344) snapshot 7 (snapNum 7 / ProvID G7 / OCID M7) of FS3 in region 2 to become snapshot 7 (snapNum 7 / ProvID G7 / OCID P4) of FS4 in region 1 by transferring the delta between snapshot 3 (ProvID S3) and snapshot 7 (ProvID G7). In other words, the conventional cross-region replication of four snapshots 1, 2, 3, and 7 from FS3 in region 2 to FS4 in region 1 can be simplified to three region clones of snapshots 1, 2, and 3 between FS1 and FS4 in the same region, plus the cross-region replication of snapshot 7 between FS3 in region 2 and FS4 in region 1. As a result, the use of provenance IDs saves resources, traffic (i.e., network or IO traffic) and time for data transfer.

[0202] Fig.14 is a flow chart illustrating a process of using a provenance ID to identify a base snapshot for cross-region replication according to certain embodiments. Fig.14As shown in , at step 1401, the source FS in the source area can generate system snapshots periodically, and also generate user snapshots according to user requests. At step 1402, each snapshot can be assigned a unique provenance ID and other identifiers (e.g., snapshot ID and resource ID). At step 1404, either due to an interruption or due to a planned failover, the source FS can receive a request to perform a cross-region replication between the source FS and the target FS. At step 1408, as discussed above, in some embodiments, both the source FS in the source area and the file system in the target area can compare the provenance IDs of their respective snapshots to identify the base snapshot (i.e., a matching snapshot with the same provenance ID or a matching provenance ID) for the purpose of cross-region replication or in response to a request to perform cross-region replication. For example, in Fig.13 , FS3 (i.e., source FS) in source region 2 compares the provenance ID of its snapshot with the provenance IDs of the snapshots of both the target FS (i.e., FS4) and the non-target FS (i.e., FS1) (i.e., step 1340). In other embodiments, a provenance ID comparison may be first performed between the source FS and the target FS in the target region. If no match is found, the source FS may perform a provenance ID comparison with the non-target FS in the target region.

[0203] At step 1410, if a matching provenance ID is not found between the source FS and the file system in the target region, then at step 1412, the cross-region replication process may use the latest snapshot of the source FS as the selected base snapshot. In other words, the source FS may need to transfer the entire base snapshot copy (i.e., the selected base snapshot) to the target FS, as indicated in step 1420, and then subsequently perform any necessary incremental transfers to the target FS. At step 1410, if a matching provenance ID is found between the source FS and the file system in the target region, then at step 1414, the process further determines whether the matching provenance ID belongs to a snapshot of the target FS in the target region or a snapshot of a non-target FS.

[0204] At step 1414, if the matching provenance ID (i.e., the matching snapshot with the same provenance ID) does not belong to a snapshot of the target FS (i.e., belongs to a snapshot of a non-target FS), then at step 1416, the non-target FS can perform a clone of the snapshot with the matching provenance ID into the region of the target FS to create a base snapshot. Then, at 1420, cross-region replication can use the cloned base snapshot of the target FS as the selected base snapshot. In other words, the source FS can generate the delta between its latest snapshot and the selected base snapshot with the matching provenance ID, and transfer only the delta to the target FS via the object repository. This eliminates the need to transfer a full base snapshot copy. For example, in Fig.13In the example, non-target FS1 can clone snapshots S1, S2, and S3 to target FS4 in the same region 1 (i.e., step 1342). Since the three snapshots (S1, S2, and S3) have matching provenance IDs, all three snapshots can be used as base snapshots. In some embodiments, the source FS can use the latest snapshot (i.e., S3) among the three snapshots as the selected base snapshot to generate the delta between snapshots S3 and G7 for cross-region replication (i.e., step 1344).

[0205] At step 1414, if the matching provenance ID belongs to a snapshot of the target FS, then both the source FS and the target FS use the snapshot of the matching provenance ID as the selected base snapshot at step 1418. At step 1420, the source FS may generate a delta between its latest snapshot and the selected base snapshot, and transfer the delta to the target FS for delta application during cross-region replication.

[0206] In addition to selecting a base snapshot for cross-region replication, in some embodiments, the provenance ID can also facilitate recoverability when replication fails or is accidentally deleted. For example, as discussed above, multiple cross-region replications may occur between regions. If a cross-region replication fails during its replication process, the corresponding source and target file systems can use the provenance ID to search for and find a snapshot of the target file system or non-target file system in the target region to use as a base snapshot to continue its cross-region replication. Because FSS uses incremental increments to perform replication, the easier and faster FSS can identify a unique common starting point for both the source file system and the target file system, the better FSS can continue the replication process and recover from failures. The provenance ID avoids the need for a complete base copy every time a failure occurs.

[0207] Area lock

[0208] For deleting and updating resources in the source or target region, a regional lock mechanism can be used to ensure that no one else can enter to delete or use or update the resource during the deletion or update to avoid damage. Consider a scenario where two different users of a customer simultaneously issue a delete request to the source and target regions, which may lead to race conditions in the two regions. For example, user 1 issues a delete request to the source region that may affect the target region. User 2 also issues a delete request directly to the target region. In some embodiments, FSS can first resolve which region received the request first. If the target region first receives a delete request for its region, it can set a regional lock on the target resource. The source region that also receives a delete request from another user can forward the request to the target region through the cross-region API, but the source region will receive a response (or error message) from the target region indicating that its resources cannot be locked for deletion because the target region is already in the Deleting state of the lifecycle state machine.

[0209] Region locking can help isolate the target region from duplicate requests from the source region to avoid inconsistencies and race conditions. Thereafter, when the target region changes from the deleting state to the deleted state after executing the delete request it received earlier, the target region informs the source region of its state change. As a result, the source region can receive two notifications from the target region for cross-region synchronization purposes. One notification (i.e., an error message) indicates that the delete request from the source region cannot be executed in the target region. The other notification indicates that the target region has completed the delete request. These notifications help the source region understand potential race conditions caused by duplicate requests, and the source region can continue to process appropriately.

[0210] If the target region first receives a delete request from the source region, a regional lock can be placed on the target resource based on the request to prevent another duplicate request. After executing the delete request initiated by the source region, the target region can notify the source region of the completion of the target's request, as mentioned above regarding cross-region synchronization. In some embodiments, regardless of whether the target region first receives a request from user 1 or user 2, the source region can change its CP state from an active state to a deleting state after receiving the request from user 1, and stay in the deleting state until it receives a cross-region synchronization notification from the target region. After receiving the notification, the source region can change its CP state from a deleting state to a deleted state and notify user 1 of the completion of the request. The cross-region synchronization process may take some time, depending on IO or network traffic, because the databases of the source and target regions exist in different regions that may be far apart.

[0211] Copy Create

[0212] Fig.15 is a flow chart illustrating a replication creation process according to certain embodiments. In order to create a replication that can allow a file system in a source zone (referred to as a source file system) to replicate across zones with a file system in a target zone (referred to as a target file system), the FSS may need to allocate spare resources (or objects) in the target zone. The spare objects may be information in the target file system that needs to be synchronized with any changes in the source file system, such as the last applied snapshot, the name of the resource, etc.

[0213] exist Fig.15 In some embodiments, at step S1, a customer may issue a create replication request to a source control API 1580. At step S2, the source identity and key management service (KMS) related components 1516 may verify user permissions and security. At step S3, the source SDB 1514 may check whether the customer's request contains a tag indicating that the same request has been received earlier, because the same request may not be executed again to avoid duplicate execution. The FSS may return the status of the previous request. At step S4, once the user's identity and security are verified, the control API may enter a success state and change its lifecycle state to a CREATING state.

[0214] In the next few steps, in some embodiments, the source region and the target region may attempt to identify a common snapshot that the two regions can use as a starting point for cross-region replication. At step S5, the source control API 1510 may communicate with the target control API 1530 through a cross-region API call to obtain the provenance ID of the latest snapshot in the target file system. The target control API may also ensure that the target file system has not been previously exported for reading or writing by other parties other than the source file system. Otherwise, the replication creation between the source file system and the target file system may be unreliable. At step S6, the target control API may check with the target KMS to verify the source KMS key for security purposes. At step S7, once the security verification is passed for the source request, the target file system may return the provenance ID of its latest snapshot requested to the source control API. At step S8, the source control API may check its provenance ID information in the source SDB to see if it has a snapshot with the same provenance ID from the target file system. Based on the results of the search, the FSS may proceed to step S9 or S11.

[0215] If the target provenance ID does not exist in the source file system, the FSS may proceed to step S9, and the source control API 1510 may notify the client of the failure. At step S10, the source control API may set its lifecycle state to FAILED in the source SDB. As a result, the FSS may need to perform a basic snapshot copy from the source FS to the target FS.

[0216] If the source file system identifies a snapshot with the same provenance ID from the target file system, the FSS may proceed to step S11 to inform the target control API 1530 to create a standby replica object in the target region. At step S12, the target control API may place a job for creating the standby object into a job queue in the target SDB. At step S13, the target control API may respond to the source control API 1510 with a resource identifier that references the newly created standby object in the target region. At step S14, the source control API may change its lifecycle state to ACTIVE in the source SDB.

[0217] Copy Delete

[0218] Sometimes, a customer may want to switch their cross-replication to a different region, either the source or the target region, or to two different source and target regions. As a result, the customer may need to terminate and exit the current replication to start a new cross-region replication to achieve this purpose. FSS can perform replication deletion for this purpose. On the other hand, if the current replication has a failure and the failure is permanent, for example, when an incremental application job in the target region is stuck and retried for a long period of time, then FSS can mark such a failure as a system failure that requires operator attention to identify the root cause. Another potential permanent failure may include the source region of the failure. Once the permanent failure is resolved, the file system may also need to perform replication deletion before starting a new replication with a fresh start.

[0219] The replication deletion process may be initiated from the source FS in the source region (also referred to herein as a source-initiated termination request) or from the target FS in the target region (also referred to herein as a target-initiated termination request). For example, when a permanent failure occurs in the target region (e.g., an incremental apply job is stalled), it may be appropriate to initiate the replication deletion from the source region. When a permanent failure occurs in the source region (e.g., the source region is unresponsive), it may be appropriate to initiate the replication deletion from the target region.

[0220] As discussed above with respect to the incremental state machine, in some embodiments, in addition to Fig.10In addition to the states described in , the replication deletion process may also have other incremental states. Additional incremental states may include, but are not limited to, the ABORT_COPY state and the SNAPSHOT_METADATA_DELETE state for the source region only, the ABORT_REPLICATION state for the target region only, and the TERMINATE state for both the source and target regions.

[0221] The incremental state Abort Copy may indicate that the source CP of the source file system attempts to stop the incremental generation and upload process, followed by resource cleanup. The snapshot metadata delete state may indicate that the source file system in the source region attempts to delete the snapshot metadata stored in the source SDB and object storage device. The Abort Copy state may indicate that the target CP of the target region attempts to stop the incremental application and download process, followed by resource cleanup.

[0222] Finally, incremental state termination can be used in either the source or target region, and then trigger a cross-region call to another region. For the source region, the termination state can indicate that the source file system attempts to delete the unused recently created system snapshot, and then notifies the target file system to change its state accordingly (e.g., the lifecycle state changes from deleting to deleted). For the target region, the termination state can indicate that the target region attempts to terminate its replication processing by converting the last snapshot to a user snapshot (if the last snapshot was a system snapshot), performing cleanup (e.g., the contents of various job / processing queues, incremental monitor queue (DMQ) entries, etc.), and then notifies the source file system to change its state accordingly (e.g., the lifecycle state changes from active to failed). System snapshots are generated periodically by FSS and may not be deleted by customers. However, user snapshots are created by users and can be deleted at any time.

[0223] Although the incremental states Abort Copy and Terminate can perform similar cleanup functions in the target region, different incremental state names help the source region distinguish whether the cleanup operation of the target is initiated (or induced) by the source region or the target region. The incremental state Abort Copy in the target region is used for source-initiated copy deletions, and can trigger the source region to change the final lifecycle state of the source to a deleted state. On the other hand, the incremental state Terminate in the target region is used for target-initiated copy deletions, and can trigger the source region to change the final lifecycle state of the source to a failed state. In other words, source-initiated copy deletions (or termination requests) and target-initiated copy deletions can use the same set of lifecycle states (also referred to as the first set of states), but use different subsets of incremental states (also referred to as the second set of states). For example, a subset of incremental states (such as Abort Copy and Abort Copy) is used for source-initiated copy deletions, while another subset of incremental states (such as Terminate) is used for target-initiated copy deletions.

[0224] Fig.16 16 is a flowchart illustrating a source-initiated replication deletion process according to certain embodiments. The components involved in the snapshot deletion process initiated by the source region are the control API 1610, the incremental monitor 1612, and the replicator 1614 in the source region, and the control API 1624, the incremental monitor 1622, and the replicator 1620 in the target region. As mentioned earlier, the control API (1610 and 1624) can be a set of hosts in the CP responsible for passing status information between different regions. The incremental monitor (DM, 1612 and 1622) can be a thread in the control plane API (control API) service that wakes up periodically to monitor the progress of the replication, including snapshot creation and scheduled replication jobs. The DM also records metadata of the snapshot, such as name, status, and tags. The incremental monitor has a incremental monitor queue (DMQ), where each replicator thread can work on a single DMQ entry at a time. The DMQ entries can be cleaned up at the end of the cleanup process in the source file system or the target file system. The replicators (1614 and 1620) including the delta generator may be responsible for delta generation and upload in the source region, delta download and application in the target region.

[0225] exist Fig.16 In step S1, depending on the current stage of cross-region replication, the target FS may be idle before the source FS has uploaded any deltas or performed a download of manifest files and deltas from the object repository and applied the deltas. At step S2, the client may request replication deletion from the source control API 1610. At step S3, the source control API host receives a request from the client to delete an existing replication process. After verification, the source CP may set its lifecycle state to deleting and respond to the client ( Fig.16). The source CP (including the control API) may send a cross-region (X-region) request to the target CP (including the control API) to abort the current replication (i.e., stop the incremental application). If the target FS is performing incremental application, the target FS may wait until the current incremental application is completed before taking action on the replication deletion request.

[0226] At step S4, the target CP may change its internal state to the Abort_Replication state and notify the target incremental monitor to stop replication. At step S5, when the target replicator detects a state change through the target incremental monitor, it may perform some cleanup in the target area, such as records related to the purpose of the checkpoint operation, file data associated with the B-tree key, and the contents of various job / processing queues for incremental applications. In an alternative embodiment, blob cleanup may be performed asynchronously at fixed intervals after each checkpoint to reduce the time for cleanup when necessary in the future. The target replicator may also clean up blobs stored in the object repository, for example, the object storage path storing objects uploaded by the source FS for all key ranges. At step S6, the target replicator may notify the incremental monitor residing in the target SDB to set the incremental state to the Abort_Replication_Done state after the cleanup is successfully completed (including DMQ cleanup in the incremental monitor). The lifecycle state may also be changed to a deleted state.

[0227] At step S7, the target CP (including both the incremental monitor 1622 and the control API 1624) can then notify the source CP of the cleanup status of the target through a cross-region API call so that the source file system starts to perform cleanup using snapshot metadata (such as provenance ID, snapshot type, and snapshot time). At step S8, the control API sets the incremental state in the source incremental monitor to the snapshot metadata deletion (Snapshot_Metadata_Delete) state. The source control CP can perform snapshot metadata deletion. At step S9, the source incremental monitor can call a workflow to delete the replication snapshot, and perform a cleanup task to delete the replication snapshot that is no longer needed when the replication cycle ends (i.e., the incremental generation in the source FS and the incremental application in the target FS are completed). At step S10, the workflow can perform cleanup to delete the snapshot and its associated metadata.

[0228] At step S11, after the source area completes the metadata deletion, the source control API can change the incremental state in the source incremental monitor residing in the source SDB to abort copy (Abort_Copy). At step S12, once the source replicator detects that the incremental state has changed to abort copy, the source replicator performs cleanup on records related to the purpose of the checkpoint operation, snapshots of file data associated with the B-tree key, and the contents of various job / processing queues for incremental generation. At step S13, after the source replicator successfully completes the cleanup, it can notify the source CP by changing the incremental state in the incremental monitor to abort copy completion (Abort_Copy_Done) and changing the life cycle state to deleted. At step S14, the incremental monitor can record in the source SDB that the requested cleanup transaction has been completed. Cleanup in the source FS, target FS, and object repository is important for avoiding data corruption of the file system at the beginning of a new copy.

[0229] Although Fig.16 It is shown that the source FS does not start its cleanup process until the cleanup process of the target is completed, but the source cleanup process can be performed in parallel or simultaneously with the target cleanup process, depending on the stage of the existing cross-region replication process. In other words, after receiving the customer's request to delete the current replication, both the source FS and the target FS may be suspended at the same time. The cross-region replication process can have three possible scenarios (or stages) involving the interaction between the source FS and the target FS when receiving the customer's request - 1) Both the source FS and the target FS are idle; 2) The source FS is performing an incremental build and the target FS is idle; and 3) The source FS is performing an incremental build and the target FS is performing an incremental apply.

[0230] In the first scenario, when both file systems are idle, after receiving the client's request for replication deletion, the source FS can request the target FS to abort its replication process, and then the source FS can also abort immediately afterwards. The source FS and the target FS can perform their respective cleanup processes simultaneously or in parallel. In the second scenario, when the source FS is performing incremental generation but the target FS is idle, after the source FS notifies the target FS to abort its replication process, the source FS can abort after its replication process reaches a safe point (for example, a checkpoint is completed). The cleanup processes of both the source FS and the target FS can overlap. In the third scenario, when both file systems are performing replication, the target FS can not abort until it has completed the incremental application. The source FS can wait for the target file system's notification about the target's completion of the cleanup process to abort, such as Fig.16 As indicated in .

[0231] After the replication deletion process is complete, the client may need to request Fig.15, so that a new cross-region replication can be started after the customer selects a valid source file system and a target file system. The valid source file system and the target file system can be the same as the original source file system and the original target file system, or can be different from either of the original source file system and the original target file system. The source FS in the source region can create a system snapshot and follow Fig.10 The new replication processing is described in the concurrent mode state machine. In the incremental state reconciling ( Fig.10 During 1052), both the source and target regions may cross-check and identify any common provenance IDs, reconcile snapshots to begin a new replication process.

[0232] Fig.17 is a flow chart illustrating a target-initiated copy deletion process according to certain embodiments. As mentioned above, the copy deletion process may also be initiated by the target region. The components used in the source-initiated copy deletion process are also applicable to the target-initiated copy deletion process. In some embodiments, the target-initiated copy deletion process may be performed only when the target FS is idle. If the target FS is executing an incremental apply when a client requests a copy deletion from the target FS, the target FS may respond to the client with a conflict signal.

[0233] exist Fig.17 In step S1, when the target FS is idle, the client can send a replication deletion request to the target control API 1724. At step S2, the control API can set the life cycle state to deleting and the incremental state to terminated, which is reflected in the target incremental monitor. The "terminated" incremental state can trigger the target file system to terminate its replication processing and also convert the last snapshot into a user snapshot for deletion. At step S3, when the target replicator detects a state change through the target incremental monitor, it can perform cleanup in the target area, such as records related to the purpose of the checkpoint operation, file data associated with the B-tree key, and the contents of various job / processing queues for incremental applications. At step S6, the target replicator can notify the incremental monitor residing in the target SDB to set the life cycle state to deleted after the cleanup is successfully completed (including DMQ cleanup in the incremental monitor). The incremental state remains in the terminated state.

[0234] At step S7, the target incremental monitor of the target CP may notify the source incremental monitor of the source CP through a cross-region API call that the status of the target file system has changed and the target file system has terminated its replication processing, so that the replication processing in the source file system may fail because the target file system may not be able to download the incremental uploaded by the source file system. At this time, the lifecycle state of the source may still be active. At step S8, the source FS may delete its previous and any unused replication snapshots. At step S9, the source CP (DM and control API) may change its incremental state to terminated and the lifecycle state to failed to reflect that its replication processing may fail due to the status of the target file system, because the replication processing in the source FS may fail when the target FS is detached (i.e., resources have been cleaned up and cannot accept incrementals from the source FS). This lifecycle state change in the source FS may alert the customer who owns the source file system.

[0235] Return to reference Fig.17 , at step S10, after receiving a notification from the source FS indicating that its lifecycle state has changed to a failed state, the client may need to issue a delete request to clean up the resources in the source FS. At step S11, the source control API can change the source lifecycle state to deleting in the incremental monitor. At step S12, once the source replicator detects that the lifecycle state has changed to deleting, the source replicator performs cleanup of records related to the purpose of the checkpoint operation, including snapshots of file data associated with B-tree keys, and the contents of various job / processing queues used for incremental generation. At step S13, after the source replicator completes the cleanup, it can notify the source CP by changing the lifecycle state to deleted and the incremental state to TERMINATED, indicating that this is a replication deletion process initiated by the target.

[0236] After the replication deletion process is complete, the client may need to request a replication creation, such as Fig.15 As described in , after the customer selects a valid source file system and target file system, a new cross-region replication can be started. The source FS in the source region can create a system snapshot and follow Fig.10 The concurrent mode state machine for the new replication processing described in .

[0237] Fig.18 is a flow chart illustrating a high-level process flow for copy deletion according to some embodiments. Fig.18In step 1810, the FSS may receive a request for cross-region file system replication between a source file system and a target file system, the source file system and the target file system being in different regions. At step 1812, the FSS performs the requested cross-region replication between the source file system and the target file system. At step 1820, the FSS may receive a request to terminate the current cross-region replication between the source file system and the target file system and then restart with a brand new cross-region replication. In some embodiments, a request to terminate the current cross-region replication (i.e., to start replication deletion processing) may be sent / issued to the source file system or the target file system or received by the source file system or the target file system, but not sent / issued to both the source file system and the target file system or received by both the source file system and the target file system. In other embodiments, if two requests to terminate the current cross-region replication are respectively issued to both the source file system and the target file system, the file system that first receives the request may obtain and set a regional lock so that only one file system can initiate replication deletion processing.

[0238] At step 1822, both the source FS and the target FS may synchronize their operations by using at least two groups of states belonging to two or more state machines, respectively. For example, one group of states may be life cycle states (or first group of states), and the other group of states may be incremental states (or second group of states), as described above. The operations may include, but are not limited to, resource cleanup in both the source FS and the target FS.

[0239] At step 1824, each file system may perform resource cleanup in its area depending on whether the replication deletion process was initiated by the source FS or the target FS. For example, the cleanup order may be different for source-initiated processing or target-initiated processing. In source-initiated replication deletion processing, the cleanup operations may be performed in parallel or simultaneously for both the source file system and the target file system. However, in target-initiated replication deletion processing, the cleanup operations in the target FS may be performed before the cleanup operations in the source FS. The cleanup operations in the source file system may include deleting checkpoint records, file data, contents of various processing queues for incremental generation, and metadata, as described above with respect to Fig.16 and Fig.17 The cleanup operation in the target file system may include deleting checkpoint records, file data, the contents of various processing queues for incremental applications, and metadata, as described above with respect to Fig.16 and Fig.17 described.

[0240] After the replication deletion process is completed, at step 1826, the client can request to start a new cross-region replication between the source FS and the target FS or between different pairs of source FS and target FS, as described above. Fig.15 , Fig.16 and Fig.17 described.

[0241] Copy the previous snapshot to restart

[0242] Sometimes, customers may want to restart cross-region replication without a complete resource cleanup of the source or target regions, but instead continue from an earlier (or previous) common snapshot between the source file system and the target file system with the same provenance ID. This restart process without a complete resource cleanup may be referred to as a Replication Prior-snapshot Restart. In some embodiments, the Replication Prior-snapshot Restart process may continue the data flow direction as currently replicated. In another embodiment, the Replication Prior-snapshot Restart process may reverse the data flow direction of the current replication.

[0243] Restarting a replication from a previous snapshot with the same data stream can be initiated by the operator or the customer. An operator-initiated restart can occur when a software error causes a problem with the current snapshot of the replication process (i.e., the snapshot that is undergoing incremental builds and incremental applies), or a customer error occurs (such as accidentally disabling a KMS key). When a customer accidentally disables one or more KMS keys, the source FS or target FS associated with the key may become unavailable for reading or writing. Subsequently, the replication process cannot proceed even after retries, and the lifecycle state may change from active to failed to alert the customer. As a result of both of these scenarios (i.e., software error or customer error), the operator may need to abandon the current snapshot of the replication and restart from a previous good snapshot that successfully completed replication.

[0244] On the other hand, customer-initiated restart with the same data stream can occur at any time when the customer wants to restart from an earlier snapshot. For example, the customer may accidentally delete an application or create a software bug that corrupts the current snapshot, and needs to find a good snapshot while transferring content using the same source FS and target FS without going through a completely new cross-region replication (i.e., copying the base snapshot from the source FS to the target FS) again. Restarting with a previous snapshot of the replication with the same data stream helps customers save a lot of resources (e.g., bandwidth, computing power) and costs.

[0245] Regarding replication with reverse data flow, a customer may want to use the original source file system again after cross-region replication between the source file system and the target file system (i.e., failover to the target file system). For example, the original source file system (primary site) may have only been down for a period of time after an outage, or the original source file system may have lower operating costs than the target file system (secondary site). These may be potential reasons for a customer to want to return to the original source file system and use the source region as the primary region.

[0246] Restarting with a previous snapshot of replication with reverse data flow can be called failover mode. There are two options: the last point in time in the source file system before the triggering event of the failover, or the latest changes in the target file system. These two options will be discussed in more detail later.

[0247] Fig.19 19 is a flow chart illustrating a high-level process flow of a replication previous snapshot restart process with the same data flow as an existing cross-region replication according to some embodiments. At step 1910, a source FS in a source region and a target FS in a target region may perform a cross-region replication. At step 1912, the source FS may receive a request from an operator or customer to restart the current cross-region replication from an earlier common snapshot to continue the same data flow direction.

[0248] At step 1920, the source FS and the target FS may perform a provenance ID comparison between the snapshots in the source FS and the snapshots in the target FS to find a matching provenance ID. The comparison may start from the latest snapshot in the target FS and backtrack to older snapshots. If no matching provenance ID is found between the snapshots of both the source file system and the target file system, then the process may proceed to step 1924 and abort the restart process. The target FS may be in two situations, a non-empty target FS or an empty target FS. If the target FS is not empty, this means that the target FS may be cloned from another file system, so it is unsafe to copy any content from the source FS to the target FS to avoid damaging the target FS. In this case, copy deletion may be a better option. If the target FS is empty, then the source FS may need to copy the base snapshot to the target FS. This basic snapshot copy process may take much longer than a simple previous snapshot restart process.

[0249] If one or more matching provenance IDs are found between the snapshots of both the source file system and the target file system, the process can proceed to step 1926. At step 1926, the two file systems can use the latest snapshot of the matching provenance ID in the target FS as the base snapshot to continue the current cross-region replication.

[0250] Go to the previous snapshot of replication with reverse data flow to restart, Fig. 20 is a simplified diagram illustrating a failover mode according to some embodiments. The failover mode allows the primary / source side to be restored to become the primary / source again before the failover. Fig. 20 As shown in FIG. 2 , a primary availability domain (AD) 2002 includes a source file system 2006, and a secondary AD 2004 includes a target file system 2008. The secondary AD 2004 can be located in the same region as the primary AD 2002 or in a different region.

[0251] exist Fig. 20 , Snapshot 1 2020 and Snapshot 2 2022 in the source file system 2006 existed before the failover due to the outage event. Similarly, Snapshot 1 2040 and Snapshot 2 2042 in the target file system 2008 existed before the failover. When the primary AD 2002 was outaged at Snapshot 3 2024, the FSS performed an unplanned failover 2050, and Snapshot 3 2024 in the source file system 2006 was copied to the target file system 2008 to become a new Snapshot 3 2044 (i.e., a replica of Snapshot 3 2024). After the target file system 2008 is online, the customer may make changes to the target file system 2008, which creates Snapshot 4 2046.

[0252] If the customer decides to use the source file system again, the FSS service can perform a failback. The customer has two options: 1) failback only 2051 by using the last point in time in the source file system before the triggering event; or 2) failback with reverse replication 2052 by using the latest changes in the target file system.

[0253] For the first option (failback only), the user can continue from the last point in time in the source file system 2006 before the triggering event (i.e., snapshot 3 2024). In other words, snapshot 3 2024 will be the snapshot to be used after failback because it has previously been successfully failed over to the target file system 2008. In order to perform failback 2051, the state of the source file system 2006 is changed to inaccessible. Then, the FSS service identifies the last point in time in the source file system 2006 before the successful failover 2050, i.e., snapshot 3 2024. A successful failover can refer to the completion of incremental generation in the source FS based on, for example, source snapshot 3 2024 and source snapshot 2 2022, and the completion of incremental application in the target FS to create a replica of source snapshot 3 2024 (i.e., target snapshot 3 2044). FSS can perform a clone of source snapshot 3 2024 in the primary AD 2002 (i.e., a copy in the same area). Now, the primary AD 2002 is back to its original settings before the outage, and the user can once again reuse the source file system 2006. Since snapshot 3 2024 is already in the file system to be used, there is no need to transfer data from the secondary AD 2004 to the primary AD 2002.

[0254] For the second option (failback with reverse replication), the user wants to reuse the source file system 2006 with the latest changes in the target file system 2008. In other words, the target snapshot 4 2046 in the target file system 2008 will be the snapshot to be used after the failback because it is the latest change in the target file system 2008. The failback process 2052 for this option involves reverse replication (i.e., reversing the roles of the source file system and the target file system for the replication process), and FSS performs the following steps:

[0255] Step 1. The state of the source file system 2006 is changed to inaccessible.

[0256] Step 2. Then, the FSS service identifies the latest snapshot in the target file system 2008 that has been successfully replicated, for example, target snapshot 3 2044 .

[0257] Step 3. The FSS service also finds the corresponding source snapshot 3 2024 in the source file system 2006 and performs a clone (ie, a copy in the same area).

[0258] Step 4. FSS service to communicate with Figure 4A similar cross-region replication process as discussed (but in the opposite direction) begins the reverse replication 2052. In other words, both the source file system 2006 and the target file system 2008 need to be synchronized, and then the target file system 2008 can upload the delta to the object store in the primary AD 2002 (i.e., the original source region). The source file system 2006 can download the delta from the object store to complete the application of source snapshot 3 2024, thereby creating a new source snapshot 4 2026, which is a replica of target snapshot 4 2046 (in the target file system).

[0259] Now the primary AD 2002 has returned to its original settings before the outage, and the user can reuse the source file system 2006 again without transferring existing data in both the source file system 2006 and the target file system 2008, e.g., snapshots 1-3 (2020-2024) in the source file system 2006. This saves time and avoids unnecessary bandwidth.

[0260] Fig.21 is a flow chart illustrating the process flow of a failover mode according to some embodiments. Fig.21 In step 2110, the FSS may receive a request from a customer to reuse the source FS as a primary region (i.e., part of a primary AD) after failover (i.e., cross-region replication) to the target FS. At step 2112, the FSS may determine which of the two options, failover only or failover with reverse replication, is specified in the customer's request. If the request is for failover only, the process may proceed to step 2120. If the request is for failover with reverse replication, the process may proceed to step 2130.

[0261] At step 2120, the source FS may identify the last point-in-time snapshot in the source FS before the successful failover, which is a snapshot that has been copied from the source FS to the target FS (i.e., completing the incremental generation in the source FS and the incremental application in the target FS). In some embodiments, identifying the last point-in-time snapshot in the source FS may involve, for example, checking the replication identification (replication ID or ID of the job running the replication) of the successful cross-region replication and the provenance ID of the snapshot associated with the replication ID in the source FS and the target FS. The replication ID may be used to identify a specific replication job between the source FS and the target FS. For example, source snapshot 3 2024 in the source FS may be associated with replication job 2050 (i.e., failover from the source FS to the target FS) that can be identified by a specific replication ID. Similarly, target snapshot 3 2044 in the target FS may be associated with replication job 2050. Since snapshot 3 2044 in the target FS is a replica of snapshot 3 2024 in the source FS, they should have the same provenance ID (i.e., the unique identifier of the snapshot). Since snapshot 3 2044 in the target FS has been successfully created by the replication job 2050, snapshot 3 2024 in the source FS may be used as the last point-in-time snapshot in the source FS for failure recovery purposes.

[0262] At step 2122, the source FS may perform a clone of the last point-in-time snapshot in the source region. A clone may be referred to as a writable snapshot and is typically created in the same region. At step 2124, the source FS may use the cloned snapshot to perform normal operations without the need for a target FS.

[0263] At step 2130, for a client request for failback with reverse replication, the FSS may identify the latest common snapshot between the source file system and the target file system that has the same provenance ID (provID). In other words, in some embodiments, the source FS may request the provenance IDs from the target FS and compare them with the provenance IDs of the source FS, starting from the latest snapshot in each of the two file systems. For example, in Fig. 20, the source FS can compare the provID of its latest snapshot (source snapshot 3 2024) with the provID of the latest snapshot of the target file system (target snapshot 4 2046). Since snapshot 4 2046 of the target FS contains new updates, no match is found. Next, the source FS can compare the provID of its latest snapshot (source snapshot 3 2024) with the provID of snapshot 3 2044 of another target. Since snapshot 3 2044 of the target is copied (or is a replica) from snapshot 3 2024 of the source, a match is found. Therefore, snapshot 3 2024 of the source is the latest public snapshot on the source side, and snapshot 3 2044 of the target is the latest public snapshot on the target side. The two public snapshots should be the same.

[0264] Once the latest public snapshot with the same provenance ID is found, at step 2132, reverse cross-region replication can be performed by reversing the roles of the original source FS and the target FS (from step 2132 to step 2138). In some embodiments, the source FS can clone the identified public snapshot for reverse cross-region replication purposes.

[0265] As part of the reverse replication process, at step 2134, the target FS may be in its latest new snapshot (e.g., Fig. 20 2046) and the latest public snapshot identified (e.g. Fig. 20 Incremental generation is performed between snapshot 3 (2044 in the source FS). In some embodiments, the identified public snapshot may not be the latest public snapshot in each file system. For example, snapshot 2 (2022 in the source FS) and snapshot 2 (2042 in the target FS) may exist based on an earlier replication between the two file systems. The latest new snapshot of the target may contain new changes that are not available in the source FS after the current cross-region replication. At step 2136, the target FS may transmit the generated delta and other replication-related information (e.g., manifest files, metadata) to the source FS via an object repository located in the source region. At step 2138, the source FS may download the delta and apply the delta to the identified latest public snapshot to create a new snapshot (e.g., Fig. 20 At step 2140, the source FS may perform normal operations using the new snapshot without requiring or relying on the target FS.

[0266] Fig. 2222 is a flow chart illustrating a high-level process flow of a replication previous snapshot restart process with reverse data flow according to certain embodiments. At step 2210, the FSS may perform cross-region replication (i.e., failover) between a source FS (in a source region) and a target FS (in a target region) after encountering a triggering event (such as an outage or system failure). The source region and the target region are different regions. The cross-region replicated data flow may generate deltas in the source FS, which are then transferred from the source FS to the target FS via an object repository located in the target region, and finally the deltas are applied in the target FS.

[0267] At step 2212, the FSS may receive a request from a client to reuse the source FS as a primary region after completing cross-region replication (i.e., failover). The primary region is the operating region before the triggering event that triggered the failover. At step 2214, both the source FS and the target FS may communicate replication-related information to each other for restart purposes. The replication-related information may include, but is not limited to, an identifier of a job running cross-region replication (replication ID or cross-region replication identifier), a provenance ID of a snapshot in the source FS, and a provenance ID of a snapshot in the target FS.

[0268] At step 2220, the FSS may identify a restartable base snapshot in the source FS, wherein the restartable base snapshot may allow the source FS to operate properly after the triggering event. In other words, the source FS may continue to perform its normal operations, such as accessing information from the restartable base snapshot and updating information to the restartable base snapshot, without relying on the target FS.

[0269] At step 2222, the FSS may need to determine the type of base snapshot that can be restarted: the last point-in-time snapshot in the source FS before the successful failover to the target FS (e.g., Fig. 20 2024 in the source FS) (i.e., failover option only), or a replica in the source FS created through reverse cross-region replication between the source FS and the target file FS (e.g., Fig. 20 2026 in) (i.e., a failover option with reverse replication). Reverse data flow means that instead of trying to make the target region the new primary region after cross-region replication, FSS will move the new primary region back to the original source region (i.e., the original primary region).

[0270] At step 2224, if the type of the restartable base snapshot is determined to be the last point-in-time snapshot in the source FS, the FSS may perform Fig.21 The failover process described in steps 2120-2124 of 2120.2124.2126.2127.2128.2129.2130.2141.2150.2161.2172.2183.2194.2195.2196.2197.2198.2199.2200.2198.2199.221 Fig. 202026), then FSS can execute Fig.21 The failover process with reverse replication described in steps 2130-2138 of in is performed to prepare a restartable base snapshot for use.Finally, at step 2226, the source FS can operate independently (ie, without relying on the target area) using the restartable base snapshot.

[0271] Example cloud architecture

[0272] As noted above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provide various services to accompany these infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, clustering software, etc.). Therefore, since these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain the availability and performance of applications.

[0273] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create a virtual machine (VM), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into that VM. The customer can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and more.

[0274] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider may, but need not, specialize in providing (e.g., provisioning, renting, selling) third-party IaaS services. An entity may also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

[0275] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and / or application deployment (e.g., on a self-service virtual machine (e.g., that can be started on demand), etc.).

[0276] In some examples, IaaS provisioning can refer to obtaining computers or virtual hosts for use, and even installing required libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0277] In some cases, there are two different challenges with IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both of these challenges can be addressed by enabling configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources, and how they work together) can be described in a declarative manner. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0278] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, one or more inbound / outbound traffic group rules can also be supplied to define how to set up inbound / outbound traffic for the network and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., can also be supplied. The infrastructure can evolve gradually as more and more infrastructure elements are desired and / or added.

[0279] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. In addition, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more but typically many different production environments (e.g., across various different geographic locations, sometimes across the world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using a provisioning tool, and / or code can be deployed using a deployment tool once the infrastructure is provisioned.

[0280] Fig.23 23 is a block diagram 2300 illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 2302 can be communicatively coupled to a secure host lease 2304 that can include a virtual cloud network (VCN) 2306 and a secure host subnet 2308. In some examples, the service operator 2302 can use one or more client computing devices, which can be portable handheld devices (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display), running software (such as Microsoft Windows ) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supports Internet, email, short message service (SMS), or other communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, including, for example, a computer running various versions of Microsoft Apple The client computing device may be a personal computer and / or laptop computer running various commercially available The client computing device may be a workstation computer running any of a variety of GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without A Microsoft Xbox gaming console with a gesture input device), and / or a personal messaging device capable of communicating over a network that can access VCN2306 and / or the Internet.

[0281] VCN 2306 may include a local peer gateway (LPG) 2310, which may be communicatively coupled to a secure shell (SSH) VCN 2312 via LPG 2310 contained in SSH VCN 2312. SSH VCN 2312 may include an SSH subnet 2314, and SSH VCN 2312 may be communicatively coupled to control plane VCN 2316 via LPG 2310 contained in control plane VCN 2316. In addition, SSH VCN 2312 may be communicatively coupled to data plane VCN 2318 via LPG 2310. Control plane VCN 2316 and data plane VCN 2318 may be contained in a service lease 2319, which may be owned and / or operated by an IaaS provider.

[0282] The control plane VCN 2316 may include a control plane demilitarized zone (DMZ) layer 2320 that acts as a perimeter network (e.g., a portion of a corporate network between a corporate intranet and an external network). DMZ-based servers may have limited liability and help control vulnerabilities. In addition, the DMZ layer 2320 may include one or more load balancer (LB) subnets 2322, a control plane application layer 2324 that may include (one or more) application subnets 2326, and a control plane data layer 2328 that may include (one or more) database (DB) subnets 2330 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 2322 included in the control plane DMZ layer 2320 may be communicatively coupled to the application subnet(s) 2326 included in the control plane application layer 2324 and the Internet gateway 2334 that may be included in the control plane VCN 2316, and the application subnet(s) 2326 may be communicatively coupled to the DB subnet(s) 2330 included in the control plane data layer 2328 and the service gateway 2336 and the network address translation (NAT) gateway 2338. The control plane VCN 2316 may include the service gateway 2336 and the NAT gateway 2338.

[0283] The control plane VCN 2316 may include a data plane mirror application layer 2340, which may include application subnet(s) 2326. The application subnet(s) 2326 included in the data plane mirror application layer 2340 may include a virtual network interface controller (VNIC) 2342 that may execute a compute instance 2344. The compute instance 2344 may communicatively couple the application subnet(s) 2326 of the data plane mirror application layer 2340 to the application subnet(s) 2326 that may be included in the data plane application layer 2346.

[0284] The data plane VCN 2318 may include a data plane application layer 2346, a data plane DMZ layer 2348, and a data plane data layer 2350. The data plane DMZ layer 2348 may include (one or more) LB subnets 2322, which may be communicatively coupled to (one or more) application subnets 2326 of the data plane application layer 2346 and an internet gateway 2334 of the data plane VCN 2318. The (one or more) application subnets 2326 may be communicatively coupled to a service gateway 2336 of the data plane VCN 2318 and a NAT gateway 2338 of the data plane VCN 2318. The data plane data layer 2350 may also include (one or more) DB subnets 2330, which may be communicatively coupled to (one or more) application subnets 2326 of the data plane application layer 2346.

[0285] The internet gateway 2334 of the control plane VCN 2316 and the data plane VCN 2318 can be communicatively coupled to the metadata management service 2352, which can be communicatively coupled to the public Internet 2354. The public Internet 2354 can be communicatively coupled to the NAT gateway 2338 of the control plane VCN 2316 and the data plane VCN 2318. The service gateway 2336 of the control plane VCN 2316 and the data plane VCN 2318 can be communicatively coupled to the cloud service 2356.

[0286] In some examples, a service gateway 2336 of a control plane VCN 2316 or a data plane VCN 2318 can make application programming interface (API) calls to cloud services 2356 without going through public internet 2354. API calls from service gateway 2336 to cloud services 2356 can be one-way: service gateway 2336 can make API calls to cloud services 2356, and cloud services 2356 can send requested data to service gateway 2336. However, cloud services 2356 may not initiate API calls to service gateway 2336.

[0287] In some examples, secure host lease 2304 can be directly connected to service lease 2319, which can otherwise be isolated. Secure host subnet 2308 can communicate with SSH subnet 2314 through LPG 2310, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 2308 to SSH subnet 2314 can enable secure host subnet 2308 to access other entities within service lease 2319.

[0288] Control plane VCN 2316 may allow a user of service lease 2319 to set up or otherwise provision desired resources. Desired resources provisioned in control plane VCN 2316 may be deployed or otherwise used in data plane VCN 2318. In some examples, control plane VCN 2316 may be isolated from data plane VCN 2318, and a data plane mirror application layer 2340 of control plane VCN 2316 may communicate with a data plane application layer 2346 of data plane VCN 2318 via a VNIC 2342, which may be included in both the data plane mirror application layer 2340 and the data plane application layer 2346.

[0289] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 2354 which may transmit the request to the metadata management service 2352. The metadata management service 2352 may transmit the request to the control plane VCN 2316 through the internet gateway 2334. The request may be received by the LB subnet(s) 2322 contained in the control plane DMZ layer 2320. The LB subnet(s) 2322 may determine that the request is valid, and in response to the determination, the LB subnet(s) 2322 may transmit the request to the application subnet(s) 2326 contained in the control plane application layer 2324. If the request is validated and a call to the public internet 2354 is required, the call to the public internet 2354 may be transmitted to the NAT gateway 2338 which may make the call to the public internet 2354. The metadata that the request may desire to be stored may be stored in the DB subnet(s) 2330.

[0290] In some examples, data plane mirror application layer 2340 may facilitate direct communication between control plane VCN 2316 and data plane VCN 2318. For example, it may be desirable to apply changes, updates, or other appropriate modifications to the configuration to the resources contained in data plane VCN 2318. Control plane VCN 2316 may communicate directly with the resources contained in data plane VCN 2318 via VNIC 2342 and may thereby perform changes, updates, or other appropriate modifications to the configuration.

[0291] In some embodiments, control plane VCN 2316 and data plane VCN 2318 may be included in service lease 2319. In this case, a user or customer of the system may not own or operate control plane VCN 2316 or data plane VCN 2318. Alternatively, an IaaS provider may own or operate control plane VCN 2316 and data plane VCN 2318, both of which may be included in service lease 2319. This embodiment may enable isolation of networks that may prevent a user or customer from interacting with the resources of other users or other customers. In addition, this embodiment may allow a user or customer of the system to store databases privately without relying on the public Internet 2354 for storage, which may not have the desired level of threat prevention.

[0292] In other embodiments, the LB subnet(s) 2322 contained in the control plane VCN 2316 can be configured to receive signals from the service gateway 2336. In this embodiment, the control plane VCN 2316 and the data plane VCN 2318 can be configured to be called by customers of the IaaS provider without calling the public Internet 2354. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 2319, which may be isolated from the public Internet 2354.

[0293] Fig.24 2400 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2402 (e.g., Fig.23 The service operator 2302 of the embodiment may be communicatively coupled to the secure host lease 2404 (e.g., Fig.23 The secure host lease 2304 may include a virtual cloud network (VCN) 2406 (e.g., Fig.23 VCN 2306) and secure host subnet 2408 (e.g., Fig.23 The VCN 2406 may include a local peer gateway (LPG) 2410 (e.g., Fig.23 ), which may be communicatively coupled to a secure shell (SSH) VCN 2412 via an LPG 2310 contained in an SSH VCN 2412 (e.g., Fig.23 SSH VCN 2312). SSHVCN 2412 may include SSH subnet 2414 (e.g., Fig.23SSH subnet 2314 of the control plane VCN 2416), and SSH VCN 2412 can be communicatively coupled to control plane VCN 2416 via LPG 2410 contained in control plane VCN 2416 (e.g., Fig.23 The control plane VCN 2316). The control plane VCN 2416 may be included in a service lease 2419 (e.g., Fig.23 service lease 2319), and a data plane VCN 2418 (e.g., Fig.23 The data plane VCN 2318) may be contained in a customer lease 2421 which may be owned or operated by a user or customer of the system.

[0294] The control plane VCN 2416 may include a control plane DMZ layer 2420 (e.g., Fig.23 , which may include (one or more) LB subnets 2422 (e.g., Fig.23 (one or more) LB subnets 2322), may include (one or more) application subnets 2426 (e.g., Fig.23 (one or more) application subnets 2326) of the control plane application layer 2424 (e.g., Fig.23 control plane application layer 2324), may include (one or more) database (DB) subnet 2430 (e.g., similar to Fig.23 (one or more) DB subnets 2330) of the control plane data layer 2428 (e.g., Fig.23 The LB subnet(s) 2422 contained in the control plane DMZ layer 2420 may be communicatively coupled to the application subnet(s) 2426 contained in the control plane application layer 2424 and the Internet gateway 2434 (e.g., Fig.23 2434), and the application subnet(s) 2426 may be communicatively coupled to the DB subnet(s) 2430 and the service gateway 2436 (e.g., Fig.23 service gateway 2336) and network address translation (NAT) gateway 2438 (e.g., Fig.23 The control plane VCN 2416 may include a service gateway 2436 and a NAT gateway 2438.

[0295] The control plane VCN 2416 may include a data plane mirror application layer 2440 (e.g., Fig.23The data plane image application layer 2340). The (one or more) application subnets 2426 included in the data plane image application layer 2440 may include a computing instance 2444 (e.g., similar to Fig.23 The compute instance 2344 may be configured to include a virtual network interface controller (VNIC) 2442 (e.g., the VNIC of 2342) of the compute instance 2344. The compute instance 2444 may facilitate the application subnet(s) 2426 of the data plane mirroring application layer 2440 and the application subnets 2426 that may be included in the data plane application layer 2446 (e.g., Fig.23 Communication between (one or more) application subnets 2426 in the data plane application layer 2346) via the VNIC 2442 contained in the data plane mirror application layer 2440 and the VNIC 2442 contained in the data plane application layer 2446.

[0296] The Internet gateway 2434 included in the control plane VCN 2416 can be communicatively coupled to the metadata management service 2452 (e.g., Fig.23 2352), which can be communicatively coupled to the public Internet 2454 (e.g., Fig.23 The public Internet 2454 can be communicatively coupled to a NAT gateway 2438 included in the control plane VCN 2416. The service gateway 2436 included in the control plane VCN 2416 can be communicatively coupled to a cloud service 2456 (e.g., Fig.23 Cloud service 2356).

[0297] In some examples, the data plane VCN 2418 may be contained in a customer lease 2421. In this case, the IaaS provider may provide a control plane VCN 2416 for each customer, and the IaaS provider may provision each customer with a unique compute instance 2444 contained in a service lease 2419. Each compute instance 2444 may allow communication between a control plane VCN 2416 contained in a service lease 2419 and a data plane VCN 2418 contained in a customer lease 2421. The compute instance 2444 may allow resources provisioned in a control plane VCN 2416 contained in a service lease 2419 to be deployed or otherwise used in a data plane VCN 2418 contained in a customer lease 2421.

[0298] In other examples, a customer of the IaaS provider may have a database that exists in the customer tenancy 2421. In this example, the control plane VCN 2416 may include a data plane mirror application layer 2440, which may include (one or more) application subnets 2426. The data plane mirror application layer 2440 may reside in the data plane VCN 2418, but the data plane mirror application layer 2440 may not be in the data plane VCN 2418. That is, the data plane mirror application layer 2440 may access the customer tenancy 2421, but the data plane mirror application layer 2440 may not exist in the data plane VCN 2418 or be owned or operated by the customer of the IaaS provider. The data plane mirror application layer 2440 may be configured to make calls to the data plane VCN 2418, but may not be configured to make calls to any entity contained in the control plane VCN 2416. A customer may desire to deploy or otherwise use resources provisioned in control plane VCN 2416 in data plane VCN 2418, and data plane mirror application layer 2440 may facilitate the customer's desired deployment or other use of resources.

[0299] In some embodiments, a customer of an IaaS provider may apply filters to the data plane VCN 2418. In this embodiment, the customer may determine what the data plane VCN 2418 may access, and the customer may restrict access to the public Internet 2454 from the data plane VCN 2418. The IaaS provider may not apply filters or otherwise control access to any external network or database by the data plane VCN 2418. The customer applying filters and controls to the data plane VCN 2418 contained in the customer lease 2421 may help isolate the data plane VCN 2418 from other customers and the public Internet 2454.

[0300] In some embodiments, cloud services 2456 may be called by service gateway 2436 to access services that may not exist on public Internet 2454, control plane VCN 2416, or data plane VCN 2418. The connection between cloud services 2456 and control plane VCN 2416 or data plane VCN 2418 may not be real-time or continuous. Cloud services 2456 may exist on different networks owned or operated by IaaS providers. Cloud services 2456 may be configured to receive calls from service gateway 2436 and may be configured not to receive calls from public Internet 2454. Some cloud services 2456 may be isolated from other cloud services 2456, and control plane VCN 2416 may be isolated from cloud services 2456 that may not be in the same region as control plane VCN 2416. For example, control plane VCN 2416 may be located in "Region 1", and cloud service "Deployment 23" may be located in Region 1 and "Region 2". If a service gateway 2436 contained in a control plane VCN 2416 located in region 1 makes a call to deployment 23, the call may be transmitted to deployment 23 in region 1. In this example, control plane VCN 2416 or deployment 23 in region 1 may not be communicatively coupled or otherwise in communication with deployment 23 in region 2.

[0301] Fig.25 25 is a block diagram 2500 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2502 (e.g., Fig.23 The service operator 2302) can be communicatively coupled to the secure host lease 2504 (e.g., Fig.23 The secure host lease 2304 may include a virtual cloud network (VCN) 2506 (e.g., Fig.23 VCN 2306) and secure host subnet 2508 (e.g., Fig.23 VCN 2506 may include LPG 2510 (e.g., Fig.23 ), which may be communicatively coupled to the SSH VCN 2512 via the LPG 2510 contained in the SSH VCN 2512 (e.g., Fig.23 SSH VCN 2512 may include SSH subnet 2514 (e.g., Fig.23 SSH subnet 2314 of the control plane VCN 2514), and SSH VCN 2512 can be communicatively coupled to control plane VCN 2516 via LPG 2510 contained in control plane VCN 2516 (e.g., Fig.23The control plane VCN 2316 of FIG. 2514 is coupled to the data plane VCN 2518 via the LPG 2510 included in the data plane VCN 2518 (e.g., Fig.23 The control plane VCN 2516 and the data plane VCN 2518 may be included in a service lease 2519 (e.g., Fig.23 Service lease 2319).

[0302] The control plane VCN 2516 may include a subnet 2522 that may include (one or more) load balancers (LBs) (e.g., Fig.23 The control plane DMZ layer 2520 (e.g., Fig.23 The control plane DMZ layer 2320 may include (one or more) application subnets 2526 (e.g., similar to Fig.23 (one or more) application subnets 2326) of the control plane application layer 2524 (e.g., Fig.23 A control plane application layer 2324), a control plane data layer 2528 (e.g., Fig.23 The LB subnet(s) 2522 contained in the control plane DMZ layer 2520 may be communicatively coupled to the application subnet(s) 2526 contained in the control plane application layer 2524 and the Internet gateway 2534 (e.g., Fig.23 2334), and the application subnet(s) 2526 may be communicatively coupled to the DB subnet(s) 2530 and the service gateway 2536 (e.g., Fig.23 ) and a network address translation (NAT) gateway 2538 (e.g., Fig.23 The control plane VCN 2516 may include a service gateway 2536 and a NAT gateway 2538.

[0303] The data plane VCN 2518 may include a data plane application layer 2546 (e.g., Fig.23 Data plane application layer 2346), data plane DMZ layer 2548 (e.g., Fig.23 Data plane DMZ layer 2348), and data plane data layer 2550 (e.g., Fig.23The data plane DMZ layer 2548 may include the trusted application subnet(s) 2560 and the untrusted application subnet(s) 2562 that may be communicatively coupled to the data plane application layer 2546 and the LB subnet(s) 2522 of the Internet gateway 2534 included in the data plane VCN 2518. The trusted application subnet(s) 2560 may be communicatively coupled to the service gateway 2536 included in the data plane VCN 2518, the NAT gateway 2538 included in the data plane VCN 2518, and the DB subnet(s) 2530 included in the data plane data layer 2550. The untrusted application subnet(s) 2562 may be communicatively coupled to the service gateway 2536 included in the data plane VCN 2518 and the DB subnet(s) 2530 included in the data plane data layer 2550. Data plane data layer 2550 may include DB subnet(s) 2530 that may be communicatively coupled to a service gateway 2536 included in data plane VCN 2518 .

[0304] The untrusted application subnet(s) 2562 may include one or more primary VNICs 2564(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2566(1)-(N). Each tenant VM 2566(1)-(N) may be communicatively coupled to a respective application subnet 2567(1)-(N) that may be contained in a respective container egress VCN 2568(1)-(N), which may be contained in a respective customer tenancy 2570(1)-(N). A respective secondary VNIC 2572(1)-(N) may facilitate communications between the untrusted application subnet(s) 2562 contained in the data plane VCN 2518 and the application subnets contained in the container egress VCN 2568(1)-(N). Each container egress VCN 2568(1)-(N) may include a NAT gateway 2538 that may be communicatively coupled to the public Internet 2554 (e.g., Fig.23 of the public Internet 2354).

[0305] An internet gateway 2534 included in control plane VCN 2516 and included in data plane VCN 2518 may be communicatively coupled to a metadata management service 2552 (e.g., Fig.232554) can be communicatively coupled to a public Internet 2554. The public Internet 2554 can be communicatively coupled to a NAT gateway 2538 included in the control plane VCN 2516 and included in the data plane VCN 2518. A service gateway 2536 included in the control plane VCN 2516 and included in the data plane VCN 2518 can be communicatively coupled to a cloud service 2556.

[0306] In some embodiments, data plane VCN 2518 may be integrated with customer lease 2570. In some cases, such integration may be useful or desirable for customers of the IaaS provider, such as where support may be desired when executing code. A customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response to this, the IaaS provider may determine whether to run code given to the IaaS provider by the customer.

[0307] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request functionality attached to the data plane application layer 2546. Code running the functionality may be executed in a VM 2566(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 2518. Each VM 2566(1)-(N) may be connected to a customer lease 2570. The corresponding container 2571(1)-(N) contained in the VM 2566(1)-(N) may be configured to run the code. In this case, there may be double isolation (e.g., the container 2571(1)-(N) runs the code, where the container 2571(1)-(N) may be contained at least in a VM 2566(1)-(N) contained in (one or more) untrusted application subnets 2562), which may help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or damaging the network of a different customer. Containers 2571(1)-(N) may be communicatively coupled to customer lease 2570 and may be configured to transmit or receive data from customer lease 2570. Containers 2571(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 2518. After running the code is complete, the IaaS provider may terminate or otherwise dispose of containers 2571(1)-(N).

[0308] In some embodiments, the trusted application subnet(s) 2560 may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet(s) 2560 may be communicatively coupled to the DB subnet(s) 2530 and configured to perform CRUD operations in the DB subnet(s) 2530. The untrusted application subnet(s) 2562 may be communicatively coupled to the DB subnet(s) 2530, but in this embodiment, the untrusted application subnet(s) may be configured to perform read operations in the DB subnet(s) 2530. The containers 2571(1)-(N) that may be included in each customer's VM 2566(1)-(N) and that may run code from the customer may not be communicatively coupled to the DB subnet(s) 2530.

[0309] In other embodiments, the control plane VCN 2516 and the data plane VCN 2518 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 2516 and the data plane VCN 2518. However, communication may occur indirectly through at least one method. The LPG 2510 may be established by an IaaS provider, which may facilitate communication between the control plane VCN 2516 and the data plane VCN 2518. In another example, the control plane VCN 2516 or the data plane VCN 2518 may call the cloud service 2556 via the service gateway 2536. For example, the call from the control plane VCN 2516 to the cloud service 2556 may include a request for a service that can communicate with the data plane VCN 2518.

[0310] Fig.26 2600 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2602 (e.g., Fig.23 The service operator 2302) can be communicatively coupled to the secure host lease 2604 (e.g., Fig.23 The secure host lease 2304 may include a virtual cloud network (VCN) 2606 (e.g., Fig.23 VCN 2306) and secure host subnet 2608 (e.g., Fig.23 VCN 2606 may include LPG 2610 (e.g., Fig.23 LPG 2310), which LPG 2610 can be included in the SSH VCN 2612 (e.g., Fig.23LPG 2610 in SSH VCN 2312 of the present invention is communicatively coupled to SSH VCN 2612. SSH VCN 2612 may include SSH subnet 2614 (e.g., Fig.23 SSH subnet 2314 of the control plane VCN 2616), and SSH VCN 2612 can be communicatively coupled to control plane VCN 2616 via LPG 2610 contained in control plane VCN 2616 (e.g., Fig.23 The control plane VCN 2316 of FIG. 2614 is coupled to the data plane VCN 2618 via the LPG 2610 included in the data plane VCN 2618 (e.g., Fig.23 The control plane VCN 2616 and the data plane VCN 2618 may be included in a service lease 2619 (e.g., Fig.23 Service lease 2319).

[0311] The control plane VCN 2616 may include a LB subnet 2622 (e.g., Fig.23 The control plane DMZ layer 2620 (e.g., Fig.23 The control plane DMZ layer 2320 may include (one or more) application subnets 2626 (e.g., Fig.23 (one or more) application subnets 2326) of the control plane application layer 2624 (e.g., Fig.23 control plane application layer 2324), may include (one or more) DB subnets 2630 (e.g., Fig.25 (one or more) DB subnets 2530) of the control plane data layer 2628 (e.g., Fig.23 The LB subnet(s) 2622 contained in the control plane DMZ layer 2620 may be communicatively coupled to the application subnet(s) 2626 contained in the control plane application layer 2624 and the internet gateway 2634 (e.g., Fig.23 2634), and the application subnet(s) 2626 may be communicatively coupled to the DB subnet(s) 2630 and the service gateway 2636 (e.g., Fig.23 ) and a network address translation (NAT) gateway 2638 (e.g., Fig.23 The control plane VCN 2616 may include a service gateway 2636 and a NAT gateway 2638.

[0312] The data plane VCN 2618 may include a data plane application layer 2646 (e.g., Fig.23 Data plane application layer 2346), data plane DMZ layer 2648 (e.g., Fig.23 Data plane DMZ layer 2348)), and data plane data layer 2650 (e.g., Fig.23 The data plane DMZ layer 2648 may include (one or more) trusted application subnets 2660 (e.g., Fig.25 (one or more) trusted application subnets 2560) and (one or more) untrusted application subnets 2662 (e.g., Fig.25 The trusted application subnet(s) 2660 may be communicatively coupled to the service gateway 2636 contained in the data plane VCN 2618, the NAT gateway 2638 contained in the data plane VCN 2618, and the DB subnet(s) 2630 contained in the data plane data layer 2650. The untrusted application subnet(s) 2662 may be communicatively coupled to the service gateway 2636 contained in the data plane VCN 2618 and the DB subnet(s) 2630 contained in the data plane data layer 2650. The data plane data layer 2650 may include the DB subnet(s) 2630 that may be communicatively coupled to the service gateway 2636 contained in the data plane VCN 2618.

[0313] The untrusted application subnet(s) 2662 may include primary VNICs 2664(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2666(1)-(N) residing within the untrusted application subnet(s) 2662. Each tenant VM 2666(1)-(N) may run code in a corresponding container 2667(1)-(N) and may be communicatively coupled to an application subnet 2626 that may be contained in a data plane application layer 2646 contained in a container egress VCN 2668. Corresponding secondary VNICs 2672(1)-(N) may facilitate communications between the untrusted application subnet(s) 2662 contained in the data plane VCN 2618 and the application subnets contained in the container egress VCN 2668. The container egress VCN may include a primary VNIC that may be communicatively coupled to a public Internet 2654 (e.g., Fig.23 NAT gateway 2638 of the public Internet 2354).

[0314] The Internet gateway 2634 included in the control plane VCN 2616 and included in the data plane VCN 2618 can be communicatively coupled to the metadata management service 2652 (e.g., Fig.23 2654) can be communicatively coupled to a public Internet 2654. The public Internet 2654 can be communicatively coupled to a NAT gateway 2638 contained in the control plane VCN 2616 and contained in the data plane VCN 2618. A service gateway 2636 contained in the control plane VCN 2616 and contained in the data plane VCN 2618 can be communicatively coupled to a cloud service 2656.

[0315] In some examples, Fig.26 The architecture model shown in block diagram 2600 can be considered as Fig.25 2500 , and may be desired by customers of the IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., a disconnected region). The customer may have real-time access to the corresponding container 2667(1)-(N) contained in each customer's VM 2666(1)-(N). The container 2667(1)-(N) may be configured to make calls to the corresponding secondary VNIC 2672(1)-(N) contained in the (one or more) application subnets 2626 of the data plane application layer 2646, which may be contained in the container egress VCN 2668. The secondary VNIC 2672(1)-(N) may transmit the call to the NAT gateway 2638, which may transmit the call to the public Internet 2654. In this example, containers 2667(1)-(N), which may be accessed by customers in real time, may be isolated from control plane VCN 2616 and may be isolated from other entities contained in data plane VCN 2618. Containers 2667(1)-(N) may also be isolated from resources from other customers.

[0316] In other examples, a customer can use containers 2667(1)-(N) to call cloud service 2656. In this example, a customer can run code in container 2667(1)-(N) to request a service from cloud service 2656. Container 2667(1)-(N) can transmit the request to secondary VNIC 2672(1)-(N), which can transmit the request to a NAT gateway, which can transmit the request to public Internet 2654. Public Internet 2654 can transmit the request to LB subnet(s) 2622 contained in control plane VCN 2616 via Internet gateway 2634. In response to determining that the request is valid, LB subnet(s) can transmit the request to application subnet(s) 2626, which can transmit the request to cloud service 2656 via service gateway 2636.

[0317] It should be appreciated that the IaaS architectures 2300, 2400, 2500, 2600 depicted in the various figures may have other components in addition to those depicted. In addition, the embodiments shown in the various figures are merely some examples of cloud infrastructure systems that may be combined with embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the various figures, may combine two or more components, or may have a different configuration or component arrangement.

[0318] In certain embodiments, the IaaS system described herein may include application suites, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) provided by the assignee.

[0319] Fig. 27 An example computer system 2700 in which various embodiments may be implemented is illustrated. System 2700 may be used to implement any of the computer systems described above. As shown, computer system 2700 includes a processing unit 2704 that communicates with a plurality of peripheral subsystems via a bus subsystem 2702. These peripheral subsystems may include a processing acceleration unit 2706, an I / O subsystem 2708, a storage subsystem 2718, and a communication subsystem 2724. Storage subsystem 2718 includes a tangible computer-readable storage medium 2722 and a system memory 2710.

[0320] The bus subsystem 2702 provides a mechanism for allowing the various components and subsystems of the computer system 2700 to communicate with each other by intention. Although the bus subsystem 2702 is schematically shown as a single bus, an alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 2702 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus using any various bus architectures. For example, this architecture can include an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured by the IEEE P1386.1 standard.

[0321] The processing unit 2704, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 2700. One or more processors may be included in the processing unit 2704. These processors may include single-core or multi-core processors. In certain embodiments, the processing unit 2704 may be implemented as one or more independent processing units 2732 and / or 2734, wherein a single-core or multi-core processor is included in each processing unit. In other embodiments, the processing unit 2704 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0322] In various embodiments, the processing unit 2704 can execute various programs in response to the program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 2704 and / or in the storage subsystem 2718. Through appropriate programming, (one or more) processors 2704 can provide the various functions described above. The computer system 2700 can additionally include a processing acceleration unit 2706, which can include a digital signal processor (DSP), a special processor, and the like.

[0323] I / O subsystem 2708 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touch pad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keyboard, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices such as Microsoft Motion sensors that enable users to control apps such as Microsoft 360 game controller. The user interface input device may also include an eye gesture recognition device, such as detecting eye activity from the user (e.g., a "wink" when taking a picture and / or making a menu selection) and translating eye gestures to the input device (e.g., Google ) in Google In addition, the user interface input device may include a user interface that enables the user to communicate with the voice recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0324] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game panel and a drawing board, and audio / video equipment such as a speaker, a digital camera, a digital video camera, a portable media player, a webcam, an image scanner, a fingerprint scanner, a barcode reader 3D scanner, a 3D printer, a laser rangefinder, and a sight tracking device. In addition, the user interface input device may include, for example, a medical imaging input device such as a computer tomography, a magnetic resonance imaging, a positron emission tomography, a medical ultrasound device. The user interface input device may also include, for example, an audio input device such as a MIDI keyboard, a digital musical instrument, etc.

[0325] The user interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as using a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 2700 to a user or other computers. For example, the user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0326] Computer system 2700 may include a storage subsystem 2718 that provides a tangible, non-transitory computer-readable storage medium for storing software and data constructs that provide the functionality of the embodiments described in the present disclosure. Software may include programs, code modules, instructions, scripts, etc. that, when executed by one or more cores or processors of processing unit 2704, provide the above-described functionality. Storage subsystem 2718 may also provide a repository for storing data used in accordance with the present disclosure.

[0327] like Fig. 27 As shown in the example in , storage subsystem 2718 may include various components, including system memory 2710, computer-readable storage media 2722, and computer-readable storage media reader 2720. System memory 2710 may store program instructions that may be loaded and executed by processing unit 2704. System memory 2710 may also store data used during the execution of instructions and / or data generated during the execution of program instructions. Various different types of programs may be loaded into system memory 2710, including but not limited to client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0328] System memory 2710 may also store an operating system 2716. Examples of operating system 2716 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or such as iOS, Phone, OS, OS and In some embodiments where the computer system 2700 executes one or more virtual machines, the virtual machines and their guest operating systems (GOS) may be loaded into the system memory 2710 and executed by one or more processors or cores of the processing unit 2704.

[0329] The system memory 2710 can be configured in different ways, depending on the type of computer system 2700. For example, the system memory 2710 can be volatile memory, such as random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM), flash memory, etc. Different types of RAM configurations can be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), etc. In some implementations, the system memory 2710 can include a basic input / output system (BIOS), which contains the basic routines that help transfer information between elements within the computer system 2700, such as during startup.

[0330] Computer-readable storage media 2722 may represent remote, local, fixed and / or removable storage devices and storage media for temporarily and / or more permanently containing and storing computer-readable information for use by computer system 2700 (including instructions executable by processing unit 2704 of computer system 2700).

[0331] Computer readable storage media 2722 may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information. This may include tangible computer readable storage media, such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media.

[0332] As examples, computer-readable storage media 2722 may include a hard drive that reads from or writes to non-removable nonvolatile magnetic media, a magnetic disk drive that reads from or writes to removable nonvolatile magnetic disks, and a magnetic disk drive that reads from or writes to removable nonvolatile optical disks (such as CD ROMs, DVDs, and Blu-ray discs). Computer readable storage media 2722 may include, but are not limited to, The computer readable storage medium 2722 may include a solid-state drive (SSD) based on non-volatile memory (such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, etc.), a volatile memory-based SSD (such as a solid-state RAM, a dynamic RAM, a static RAM), a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of DRAM and flash memory-based SSDs. The disk drive and its associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 2700.

[0333] Machine-readable instructions executable by one or more processors or cores of processing unit 2704 may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium may include a physically tangible memory or storage device, including a volatile memory storage device and / or a non-volatile storage device. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM or flash memory, hard drives, floppy disk drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0334] The communication subsystem 2724 provides an interface to other computer systems and networks. The communication subsystem 2724 is used as an interface for receiving data from other systems and transmitting data from the computer system 2700 to other systems. For example, the communication subsystem 2724 can enable the computer system 2700 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 2724 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, advanced data network technology such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), a global positioning system (GPS) receiver component and / or other components. In some embodiments, as an addition or replacement of a wireless interface, the communication subsystem 2724 may provide a wired network connection (e.g., Ethernet).

[0335] In some embodiments, the communication subsystem 2724 may also receive input communications in the form of structured and / or unstructured data feeds 2726 , event streams 2728 , event updates 2730 , and the like on behalf of one or more users who may use the computer system 2700 .

[0336] As an example, the communication subsystem 2724 may be configured to receive data feeds 2726 in real time from users of a social network and / or other communication service, such as feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0337] Additionally, the communication subsystem 2724 may also be configured to receive data in the form of a continuous data stream, which may include event streams 2728 and / or event updates 2730, which may be continuous or unbounded in nature, real-time events without explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0338] The communication subsystem 2724 may also be configured to output structured and / or unstructured data feeds 2726, event streams 2728, event updates 2730, etc. to one or more databases, which may be in computer communication with one or more streaming data source computers coupled to the computer system 2700.

[0339] Computer system 2700 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g. Glass head mounted display), PC, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0340] Due to the ever-changing nature of computers and networks, the description of the computer system 2700 depicted in the figure is intended only as a specific example. Many other configurations with more or fewer components than the system depicted in the figure are possible. For example, customized hardware may also be used and / or specific elements may be implemented with hardware, firmware, software (including applets) or a combination thereof. In addition, connections to other computing devices such as network input / output devices may also be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0341] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are also included within the scope of this disclosure. Embodiments are not limited to operating within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although embodiments have been described using a specific series of transactions and steps, it should be clear to those skilled in the art that the scope of this disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments may be used alone or in combination.

[0342] In addition, although embodiments have been described using specific combinations of hardware and software, it should be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments may be implemented using only hardware, or only software, or using a combination thereof. The various processes described herein may be implemented in any combination on the same processor or on different processors. Accordingly, where a component or service is described as being configured to perform certain operations, such configuration may be accomplished by, for example, designing electronic circuits to perform the operations, by programming programmable electronic circuits (such as microprocessors) to perform the operations, or any combination thereof. Processes may communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0343] The embodiments may be implemented by using a computer program product comprising a computer program / instructions which, when executed by a processor, cause the processor to perform any of the methods described in the present disclosure.

[0344] Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive. However, it is apparent that additions, subtractions, deletions and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, although specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalent forms are within the scope of the following claims.

[0345] The use of the terms "one" and "an" and "the" and similar references in the context of describing the disclosed embodiments (especially in the context of the following claims) is to be interpreted as covering the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context. Unless otherwise stated, the terms "include", "have", "include" and "contain" are to be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" should be interpreted as being partially or completely contained in, attached to or connected together, even if there is something in the middle. Unless otherwise indicated herein, the enumeration of the value range herein is intended only to be used as a shorthand method for individually quoting each individual value falling within the range, and each individual value is incorporated into the specification as if it were individually listed herein. Unless otherwise indicated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments and is not intended to limit the scope of the present disclosure, unless otherwise stated. Any language in the specification should not be interpreted as indicating that any unclaimed element is essential to the practice of the present disclosure.

[0346] Disjunctive language, such as the phrase "at least one of X, Y, or Z," unless expressly stated otherwise, is intended to be understood in the context of being generally used to indicate that an item, term, etc. may be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present.

[0347] Preferred embodiments of the present disclosure are described herein, including the best mode known for implementing the present disclosure. Variations of those preferred embodiments will become apparent to those of ordinary skill in the art after reading the above description. Those of ordinary skill should be able to appropriately adopt such variations and may practice the present disclosure in a manner different from that specifically described herein. Accordingly, the present disclosure includes all modifications and equivalent forms of the subject matter recorded in the appended claims where permitted by applicable law. In addition, unless otherwise indicated herein, the present disclosure includes any combination of the above-mentioned elements in all possible variations thereof.

[0348] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0349] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but it will be appreciated by those skilled in the art that the present disclosure is not limited thereto. Each feature and aspect disclosed above can be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiments can be used in any number of environments and applications other than those described herein. Thus, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0350] Clause 1: A method comprising:

[0351] After encountering a trigger event, the computing system performs cross-region replication between a source file system in a source region and a target file system in a target region, where the source region and the target region are different regions;

[0352] receiving, by the computing system, a request to reuse a source file system as a primary region after cross-region replication, the primary region being an operating region before a triggering event occurs;

[0353] The computing system transmits replication related information between the source file system and the target file system;

[0354] identifying, by the computing system, a restartable base snapshot in the source file system, the restartable base snapshot being configured to allow the source file system to operate properly after the triggering event; and

[0355] Operations are performed by a source file system of the computing system using a restartable base snapshot without dependency on a target file system.

[0356] Clause 2: The method as described in Clause 1, wherein the replication-related information includes an identifier of the cross-region replication, a unique identifier of the snapshot in the source file system, and a unique identifier of the snapshot in the target file system.

[0357] Clause 3: The method of clause 1 or clause 2, wherein the restartable base snapshot in the source file system is a source snapshot that has been successfully replicated in the target file system through cross-region replication.

[0358] Clause 4: The method of clause 3, wherein the replica in the target file system has the same unique identifier as the source snapshot in the source file system.

[0359] Clause 5: The method of any preceding clause, wherein the restartable base snapshot in the source file system is a replica of the latest new snapshot in the target file system after reverse cross-region replication between the source file system and the target file system.

[0360] Clause 6: The method of clause 5, wherein reverse cross-region replication comprises:

[0361] identifying the most recent common snapshot between the source file system and the target file system;

[0362] generating, by the target file system, a delta based at least in part on a difference between a latest new snapshot and a latest common snapshot in the target file system;

[0363] transferring the delta from the target file system to the source file system; and

[0364] The delta is applied by the source file system to the latest common snapshot in the source file system to generate a restartable base snapshot in the source file system.

[0365] Clause 7: The method of clause 6, wherein transferring the delta from the target file system to the source file system further comprises uploading the delta from the target file system to an object storage device located in the source region, and downloading the delta from the object storage device to the source file system.

[0366] Clause 8: A non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a computing system, cause the one or more processors to perform operations comprising:

[0367] After encountering a trigger event, the computing system performs cross-region replication between a source file system in a source region and a target file system in a target region, where the source region and the target region are different regions;

[0368] receiving, by the computing system, a request to reuse a source file system as a primary region after cross-region replication, the primary region being an operating region before a triggering event occurs;

[0369] The computing system transmits replication related information between the source file system and the target file system;

[0370] identifying, by the computing system, a restartable base snapshot in the source file system, the restartable base snapshot being configured to allow the source file system to operate properly after the triggering event; and

[0371] Operations are performed by a source file system of the computing system using a restartable base snapshot without dependency on a target file system.

[0372] Clause 9: The non-transitory computer-readable medium of clause 8, wherein the replication-related information includes an identifier of the cross-region replication, a unique identifier of the snapshot in the source file system, and a unique identifier of the snapshot in the target file system.

[0373] Clause 10: The non-transitory computer-readable medium of clause 8 or clause 9, wherein the restartable base snapshot in the source file system is a source snapshot that has successfully created a replica in the target file system through cross-region replication.

[0374] Clause 11: The non-transitory computer-readable medium of Clause 10, wherein the replica in the target file system has the same unique identification as the source snapshot in the source file system.

[0375] Clause 12: The non-transitory computer-readable medium of any of clauses 8 to 11, wherein the restartable base snapshot in the source file system is a replica of the latest new snapshot in the target file system after reverse cross-region replication between the source file system and the target file system.

[0376] Clause 13: The non-transitory computer-readable medium of clause 12, wherein the reverse cross-region replication comprises:

[0377] identifying the most recent common snapshot between the source file system and the target file system;

[0378] generating, by the target file system, a delta based at least in part on a difference between a latest new snapshot and a latest common snapshot in the target file system;

[0379] transferring the delta from the target file system to the source file system; and

[0380] The delta is applied by the source file system to the latest common snapshot in the source file system to generate a restartable base snapshot in the source file system.

[0381] Clause 14: The non-transitory computer-readable medium of clause 13, wherein transferring the delta from the target file system to the source file system further comprises uploading the delta from the target file system to an object storage device located in the source region, and downloading the delta from the object storage device to the source file system.

[0382] Clause 15: A system comprising:

[0383] one or more processors; and

[0384] One or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to:

[0385] After encountering a triggering event, performing cross-region replication between a source file system in a source region and a target file system in a target region, the source region and the target region being different regions;

[0386] receiving a request to reuse a source file system as a primary region after cross-region replication, the primary region being an operational region before a triggering event occurs;

[0387] Transfer replication related information between source file system and target file system;

[0388] identifying a restartable base snapshot in the source file system, the restartable base snapshot configured to allow the source file system to operate properly after the triggering event; and

[0389] Operations are performed by the source file system using a restartable base snapshot, independent of the target file system.

[0390] Clause 16: The system of clause 15, wherein the replication-related information includes an identifier of the cross-region replication, a unique identifier of the snapshot in the source file system, and a unique identifier of the snapshot in the target file system.

[0391] Clause 17: The system of clause 15 or clause 16, wherein the restartable base snapshot in the source file system is a source snapshot that has successfully created a replica in the target file system through cross-region replication.

[0392] Clause 18: The system of any of Clauses 15 to 17, wherein the restartable base snapshot in the source file system is a replica of the latest new snapshot in the target file system after reverse cross-region replication between the source file system and the target file system.

[0393] Clause 19: The system of clause 18, wherein the reverse cross-region replication comprises:

[0394] identifying the most recent common snapshot between the source file system and the target file system;

[0395] generating, by the target file system, a delta based at least in part on a difference between a latest new snapshot and a latest common snapshot in the target file system;

[0396] transferring the delta from the target file system to the source file system; and

[0397] The delta is applied by the source file system to the latest common snapshot in the source file system to generate a restartable base snapshot in the source file system.

[0398] Clause 20: The system of clause 19, wherein transferring the delta from the target file system to the source file system further comprises uploading the delta from the target file system to an object storage device located in the source region, and downloading the delta from the object storage device to the source file system.

Claims

1. A method comprising: A computing system performs cross-region replication between a source file system and a target file system, the source file system and the target file system being in different regions; Receiving, by the computing system, a request to terminate cross-region replication between a source file system and a target file system; synchronizing, by the computing system, operations in the source file system and operations in the target file system by using the first set of states and the second set of states, the operations in the source file system including performing resource cleanup in the source file system, and the operations in the target file system including performing resource cleanup in the target file system; as well as A new cross-region replication between the source file system and the target file system is started by the computing system after resource cleanup in the source file system and resource cleanup in the target file system.

2. The method of claim 1, wherein the first set of states tracks resource management and utilization and is visible to the client.

3. The method of claim 1 or claim 2, wherein the second set of state tracks ownership of replication-related jobs of components of the source and target file systems and is not visible to the client.

4. A method as claimed in any one of the preceding claims, wherein performing resource cleanup in the source file system and the target file system uses a first set of states; and Wherein when the request to terminate the cross-region replication is initiated by the source file system, resource cleanup in the source file system and the target file system is performed using a first subset of the second set of states, and when the request to terminate the cross-region replication is initiated by the target file system, resource cleanup in the source file system and the target file system is performed using a second subset of the second set of states.

5. The method of any one of the preceding claims, wherein the request to terminate the cross-region replication is initiated by a source file system.

6. The method of claim 5, wherein resource cleanup in the source file system and resource cleanup in the target file system are performed simultaneously.

7. The method according to any one of claims 1 to 4, wherein the request to terminate the cross-region replication is initiated by the target file system.

8. The method of claim 7, wherein resource cleanup in the target file system is performed and completed before resource cleanup in the source file system begins.

9. A non-transitory computer readable medium storing computer executable instructions, which, when executed by one or more processors of a computing system, cause the one or more processors to perform operations comprising: A computing system performs cross-region replication between a source file system and a target file system, the source file system and the target file system being in different regions; Receiving, by the computing system, a request to terminate cross-region replication between a source file system and a target file system; synchronizing, by the computing system, operations in the source file system and operations in the target file system by using the first set of states and the second set of states, the operations in the source file system including performing resource cleanup in the source file system, and the operations in the target file system including performing resource cleanup in the target file system; as well as A new cross-region replication between the source file system and the target file system is started by the computing system after resource cleanup in the source file system and resource cleanup in the target file system.

10. The non-transitory computer readable medium of claim 9, wherein the first set of states tracks resource management and utilization and is visible to the client.

11. The non-transitory computer readable medium of claim 9 or claim 10, wherein the second set of state tracks ownership of replication-related jobs of components of the source and target file systems and is not visible to the client.

12. The non-transitory computer readable medium of any one of claims 9 to 11, wherein performing resource cleanup in the source file system and the target file system uses a first set of states; and Wherein when the request to terminate the cross-region replication is initiated by the source file system, resource cleanup in the source file system and the target file system is performed using a first subset of the second set of states, and when the request to terminate the cross-region replication is initiated by the target file system, resource cleanup in the source file system and the target file system is performed using a second subset of the second set of states.

13. The non-transitory computer-readable medium of any one of claims 9 to 12, wherein the request to terminate the cross-region replication is initiated by a source file system; and The resource cleanup in the source file system and the resource cleanup in the target file system are performed simultaneously.

14. The non-transitory computer readable medium of any one of claims 9 to 12, wherein the request to terminate the cross-region replication is initiated by the target file system; and The resource cleanup in the target file system is executed and completed before the resource cleanup in the source file system begins.

15. A system comprising: one or more processors; as well as one or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to: Perform cross-region replication between a source file system and a target file system, where the source file system and the target file system are in different regions; receiving a request to terminate cross-region replication between a source file system and a target file system; synchronizing operations in the source file system and operations in the target file system by using the first set of states and the second set of states, the operations in the source file system including performing resource cleanup in the source file system, and the operations in the target file system including performing resource cleanup in the target file system; and A new cross-region replication between the source file system and the target file system is started after resource cleanup in the source file system and resource cleanup in the target file system.

16. The system of claim 15, wherein the first set of states tracks resource management and utilization and is visible to the client.

17. A system as claimed in claim 15 or claim 16, wherein the second set of state tracks ownership of replication-related jobs of components of the source and target file systems and is not visible to the client.

18. A system as claimed in any one of claims 15 to 17, wherein performing resource cleanup in the source file system and the target file system uses a first set of states; and Wherein when the request to terminate the cross-region replication is initiated by the source file system, resource cleanup in the source file system and the target file system is performed using a first subset of the second set of states, and when the request to terminate the cross-region replication is initiated by the target file system, resource cleanup in the source file system and the target file system is performed using a second subset of the second set of states.

19. The system of any one of claims 15 to 18, The request to terminate the cross-region replication is initiated by the source file system; and The resource cleanup in the source file system and the resource cleanup in the target file system are performed simultaneously.

20. The system of any one of claims 15 to 18, wherein the request to terminate the cross-region replication is initiated by the target file system; and The resource cleanup in the target file system is executed and completed before the resource cleanup in the source file system begins.

Images