Efficient replication and recovery techniques

Abstract

Techniques are described for efficient replication and maintenance of snapshot data consistency during file storage replication between file systems in different cloud infrastructure regions. In some embodiments, the origin ID is used to efficiently identify the start point (e.g., base snapshot) of the cross-region replication process, conserving cloud resources, while reducing network and IO traffic. In some embodiments, snapshot creation and deletion requests that occur during cross-regional replication may be temporarily deducted until the appropriate time at which such requests are securely executed, depending on the temporal relationship between such requests and the cross-regional replication cycle.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Non-Provisional Application No. 18 / 169,121, filed on February 14, 2023, entitled “TECHNIQUES FOR EFFICIENT REPLICATION AND RECOVERY” and attorney docket number 088325-1342650 (347410US) and U.S. Non-Provisional Application No. 18 / 169,121, filed on February 14, 2023, entitled “TECHNIQUES FOR MAINTAINING SNAPSHOT DATA CONSISTENCY DURING FILE SYSTEM CROSS-REGION REPLICATION", U.S. Non-Provisional Application No. 18 / 169,124, filed on June 16, 2022, and U.S. Provisional Application No. 63 / 352,992, filed on June 30, 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, the disclosures of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] The present disclosure generally relates to file systems. More specifically, but not limited to, techniques are described for efficiently replicating and maintaining snapshot data consistency during file storage replication between file systems in different cloud infrastructure regions (e.g., data centers in a particular geographic region). Background Art

[0004] Enterprise business contains critical data. File system replication enhances the availability of critical data and provides fault tolerance. However, it is necessary to improve the efficiency of file system replication and the consistency of snapshot data during replication. Summary of the invention

[0005] The present disclosure generally relates to file systems. More specifically, but not limited to, techniques are described for efficiently replicating and maintaining snapshot data consistency during file storage replication between file systems in different cloud infrastructure regions (e.g., data centers in a particular geographic region).

[0006] In certain embodiments, a technique is provided that includes a method, the method comprising: generating, by a computing system, a first snapshot and a second snapshot in a source file system in a source region; assigning, by the computing system, a first provenance identifier for the first snapshot and a second provenance identifier for the second snapshot in the source file system, the first provenance identifier being unique among all snapshots in all regions, and the second provenance identifier being unique among all snapshots in all regions; receiving, by the computing system, a request to perform replication between a source file system in the source region and a target file system in a target region, the source region and the target region being located in different regions; comparing, by the computing system, the first provenance identifier in the source file system with provenance identifiers of existing snapshots in the target region in response to the request; identifying, by the computing system, a matching snapshot in the target region having the first provenance identifier to serve as a base snapshot for replication based at least in part on the comparison; and performing replication, by the computing system, using a delta between the second snapshot and the base snapshot in the source file system.

[0007] In yet another embodiment, the method further includes selecting the matching snapshot as the base snapshot in response to at least a matching snapshot having the first provenance identifier in the target area being located in the target file system.

[0008] In yet another embodiment, the target area includes a non-target file system having a snapshot associated with the first provenance identifier.

[0009] In another embodiment, the method further includes, at least in response to the fact that a matching snapshot with the first provenance identifier in the target region is not in the target file system, executing an in-region copy of the matching snapshot with the first provenance identifier from a non-target file system to a region (in-region) of the target file system; and selecting the in-region copy of the matching snapshot in the target file system as a base snapshot.

[0010] In yet another embodiment, the copy in the region of the matching snapshot in the target file system and the matching snapshot in the non-target file system have the same first provenance identifier, but have different resource identifiers.

[0011] In yet another embodiment, the method further includes selecting a first snapshot with the first provenance identifier in the source file system as the base snapshot at least in response to not finding a matching snapshot with the first provenance identifier in the target area.

[0012] In yet another embodiment, the method further includes performing a cross-region copy of the first snapshot having the first provenance identifier from the source file system to the target file system before generating a delta between the second snapshot and the base snapshot in the source file system.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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

[0017] 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.

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

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

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

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

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

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

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

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

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

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

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

[0029] 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.

[0030] Fig.12 is a simplified diagram illustrating a failback mode according to some embodiments.

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

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

[0033] Fig.15 is a diagram illustrating delayed snapshot deletion and replication for maintaining consistency between a source FS and a target FS according to certain embodiments.

[0034] Fig.16 is a flow diagram illustrating a process of delaying snapshot deletion and replication after detecting a snapshot deletion request in accordance with certain embodiments.

[0035] Fig.17 is a flow diagram illustrating a process for delaying snapshot deletion and replication after detecting a snapshot creation event, according to some embodiments.

[0036] Fig.18 is a flow diagram illustrating the control plane workflow of a source zone and a target zone according to certain embodiments.

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

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

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

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

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

[0042] 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 clear that various embodiments can be practiced without these specific details. The various figures and descriptions are not intended to be limiting.

[0043] Disclosed herein is a technique for a file system service (FSS) that utilizes snapshots and data models to create, process, and replicate snapshots and their associated data to ensure efficient replication, recovery, and consistency between a source file system (FS) and a target FS. The efficiency of replication and recovery utilizes a provenance ID to efficiently identify a starting point (e.g., a base snapshot) for a cross-region (or x-region) replication process.

[0044] The provenance ID is a special identifier that uniquely identifies a snapshot across regions, whether it is a system snapshot or a user snapshot. Before starting x-region replication, the source and target regions can compare the provenance IDs of existing snapshots in their respective regions. Once two snapshots with the same provenance ID are found in both the source file system in the source region and the target file system in the target region, these two snapshots can be used as base snapshots without copying the full base snapshot from the source file system to the target file system. During x-region replication, only the deltas between subsequent snapshots and the base snapshot in the source file system need to be transferred to the target file system. Therefore, the provenance ID technology saves valuable cloud resources while reducing network and IO traffic for performing x-region replication.

[0045] In some embodiments, if a snapshot with a matching provenance ID is located in a non-target file system in the target zone, the non-target file system can perform a zone clone of the snapshot with a matching provenance ID into the target FS to create a base snapshot. Thereafter, an x-zone copy can be performed between the source file system and the target file system. In-zone cloning also saves cloud resources because in-zone cloning does not involve additional encryption / decryption, data transfer through object storage devices, etc.

[0046] The provenance ID can also help with efficient recovery during replication failures by quickly identifying the common starting point between the source FS and the target FS in different regions, without requiring a full base copy to continue the failed replication. Finally, the control plane communication between the source FS and the target FS for snapshots and data models exchanges snapshot metadata information during the replication process to help achieve the goal of improving file system replication efficiency.

[0047] The snapshot data consistency technology disclosed herein can help protect data integrity when snapshot creation and deletion requests occur during cross-region replication by temporarily withholding certain requests until the appropriate time to safely execute such requests. The control plane communication between the source FS and the target FS for snapshots and data models exchanges snapshot metadata information during the replication process to help achieve the goal of maintaining snapshot data consistency during replication.

[0048] In some embodiments, system snapshots are created and deleted periodically by the FSS, while user snapshots can be created and deleted at any time by the user according to the scheduled snapshot policy. Depending on the request times of creation and deletion of user snapshots and the degree of overlap of these times with the cross-region replication cycle, several possibilities may arise and may potentially cause snapshot consistency issues between the source FS and the target FS. Snapshot deletion and replication may be delayed to ensure snapshot consistency.

[0049] In one embodiment, if a request to delete a user snapshot occurs during a replication cycle (e.g., replication cycle N), the FSS may withhold deletion until the replication cycle in the source FS (e.g., replication cycle N) ends and the next replication cycle in the target FS (e.g., replication cycle N+1) ends. In another embodiment, if a user snapshot is created and then requested to be deleted between two replication cycles (e.g., replication cycles N and N+1), the snapshot may not be replicated at all. However, in another embodiment, if a user snapshot is created during a replication cycle (e.g., replication cycle N), but deletion is not requested until more than one replication cycle later (e.g., after replication cycle N+1), replication of the user snapshot may be delayed by one cycle (i.e., occurs in replication cycle N+1).

[0050] Explanation of terms in certain embodiments

[0051] 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.

[0052] 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.

[0053] 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. A replicator 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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 required 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

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

[0065] The 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.

[0066] In the context of the cloud, a Realm refers to a logical collection of one or more regions. Realms 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 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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 1 As 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.

[0075] 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.

[0076] 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.

[0077] 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 are multiple file systems 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 the KMS 250, object repository 260, and data plane can be shared by many file systems in the same region.

[0078] 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.

[0079] 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).

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 2The 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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).

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] Figure 3 is 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).

[0104] 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.

[0105] 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.

[0106] 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.

[0107] 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.

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

[0109] 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.

[0110] 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.

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

[0112] 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.

[0113] 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.

[0114] Step S4: CP-A 410 notifies the target (B) control plane (CP-B) 450 of the upload completion.

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

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

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

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

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

[0120] 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.

[0121] Keys and snapshots are immutable (i.e., they cannot be modified unless the garbage collector can remove them). Figure 5 As 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.

[0122] 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.

[0123] 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.

[0124] Fig. 6A and Figure 6B is 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 6BThe 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.

[0125] 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.

[0126] 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).

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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 midway through 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, fails 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.

[0134] 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.

[0135] 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.

[0136] 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).

[0137] 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.

[0138] 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.

[0139] Figure 8 Depicted 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.

[0140] 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.

[0141] 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).

[0142] 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 completed, 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).

[0143] Fig. 9 An 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.

[0144] 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. 9The 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] The file system has several operations to handle its resources, including but not limited to create, read, update, and delete (CRUD). These operations are typically 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 clients. 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. Clients can contact the source region to create or update resources, which can be automatically reflected to secondary or backup 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.

[0149] 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.

[0150] 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.

[0151] 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.

[0152] 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.10, the target file system can initiate the copy 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).

[0153] 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.

[0154] 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.

[0155] The CpRtSt workflow now hands control back to the incremental monitor to monitor the incremental upload process, thereby entering the Ready_to_Copy state 1008, which indicates that the incremental 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 incremental. 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).

[0156] 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.

[0157] The source file system transmits the DTK and the resource identifiers 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., a decrypted session key).

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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 be accurately started 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.

[0169] At step S3, CPa 1103 also requests the file system service workflow (FSW_CPa) 1104 to periodically create snapshots, 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 SDBa 1106. 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 the work item information (such as the number of key ranges) into SDBa 1106. 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 (steps 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.

[0170] 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.

[0171] 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.

[0172] Availability addresses situations where a machine can be automatically restarted 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.

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] Fig.12 is a simplified diagram illustrating a failover mode according to some embodiments. The failover mode allows the primary / source side before the failover to be restored to become the primary / source again. Fig.12 As shown in FIG. 1 , the primary AD 1202 includes a source file system 1206, and the secondary AD 1204 includes a target file system 1208. The secondary AD 1204 may be located in the same region as the primary AD 1202 or in a different region.

[0180] exist Fig.12 , Snapshot 1 1220 and Snapshot 2 1222 in the source file system 1206 existed before the failover due to the outage event. Similarly, Snapshot 1 1240 and Snapshot 2 1242 in the target file system 1208 existed before the failover. When the primary AD 1202 was outaged at Snapshot 3 1224, the FSS performed an unplanned failover 1250, and Snapshot 3 1224 in the source file system 1206 was copied to the target file system 1208 to become the new Snapshot 3 1224. After the target file system 1208 is online, the customer may make changes to the target file system 1208, which creates Snapshot 4 1246.

[0181] If the customer decides to use the source file system again, the FSS service can perform a failover. The user has two options when performing a failover: 1) the last point in time in the source file system before the triggering event 1251, or 2) the latest changes in the target file system 1252.

[0182] For the first option, the user can recover from the last point in time in the source file system 1206 before the triggering event (i.e., snapshot 3 1224). In other words, snapshot 3 1224 will be the snapshot to be used after failback because it has previously been successfully failed over to the target file system 1208. In order to perform failback 1251, the state of the source file system 1206 is changed to inaccessible. The FSS service then identifies the last point in time in the source file system 1206 before the successful failover, which is snapshot 3 1224. The FSS can perform a clone of snapshot 3 1224 in the primary AD 1202 (i.e., a copy in the same area). Now, the primary AD 1202 is back to its initial settings before the interruption, and the user can reuse the source file system 1206 again. Since snapshot 3 1224 is already in the file system to be used, there is no need to transfer data from the secondary AD 1204 to the primary AD 1202.

[0183] For the second option, the user wants to reuse the source file system with the latest changes in the target file system 1208. In other words, snapshot 4 1246 in the target file system 1208 will be the snapshot to be used after failback because it is the latest change in the target file system 1208. The failback process 1252 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:

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

[0185] Step 2. The FSS service then identifies the latest snapshot in the target file system 1208 that has been successfully replicated, for example, snapshot 3 1244 .

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

[0187] Step 4. FSS service to communicate with Figure 4 A similar process (but in the opposite direction) discussed in 1250 initiates the reverse replication 1252. In other words, both the source file system 1206 and the target file system 1208 need to be synchronized, and then the target file system 1208 can upload the delta to the object store in the primary AD 1202. The source file system 1206 can download the delta from the object store to complete the application of snapshot 3 1224, thereby creating a new snapshot 4 1226.

[0188] Now the primary AD 1202 has returned to its original settings before the outage, and the user can reuse the source file system 1206 again without transferring existing data in both the source file system 1206 and the target file system 1208, e.g., snapshots 1-3 (1220-1224) in the source file system 1206. This saves time and avoids unnecessary bandwidth.

[0189] Snapshots and data models

[0190] Snapshot

[0191] In some embodiments, there are two types of snapshots, system snapshots and user (or customer) snapshots. System snapshots are controlled by the FSS, while user snapshots are controlled by customers. System snapshots are created periodically by the snapshot generator in the source FS and are cleaned up in the source and target file systems at the end of the replication cycle. Customers can also create user snapshots in the source area under a scheduled snapshot policy. Customers can distinguish between system snapshots and user snapshots based on their details (e.g., different names).

[0192] System snapshots can be used to specify the start of a replication cycle, so there is one system snapshot per replication cycle. On the other hand, user snapshots can be generated and deleted by the user at any time and cannot be used to specify the start of a replication cycle.

[0193] System snapshots cannot be modified or deleted by the client. However, the FSS can delete the system snapshot after the target FS successfully completes the incremental application. In some embodiments, at least one system snapshot is retained in both the source FS and the target FS. For example, when both the source FS and the target FS complete replication cycle N, both file systems can delete the system snapshot of replication cycle N-1 without immediately deleting the system snapshot of replication cycle N that they just completed.

[0194] The replication process identifies the changes (i.e., deltas) between two system snapshots. The replication process starts with the base snapshots (i.e., established as a starting point) of the source FS and the target FS. For example, if the base snapshot only exists in the source FS, then the FSS needs to create a copy of the base snapshot in the target FS by transferring the entire base snapshot from the source FS to the target FS. If the source FS and the target FS each already have the same base snapshot, then the replication process can start calculating the deltas in the source FS (i.e., the difference between the new snapshot and the base snapshot) and immediately transfer the deltas to the target FS.

[0195] Source ID

[0196] The technology disclosed in the File System Service (FSS) uses provenance ID to achieve efficient replication, including saving cloud resources and reducing network and IO traffic. The 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, it means that the snapshots in each of the two file systems are very similar so far, or have a common ancestor, or have the same known time point, and can be used as the base snapshot for cross-region (or x-region) replication. The provenance ID applies to both system snapshots and user snapshots.

[0197] 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 copies: clones or replicas. Clones can be called writable snapshots and are typically created in the same region. When clones are 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.

[0198] 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 will not receive further changes in the future, so it only gets a point-in-time snapshot.

[0199] 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 among 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 among 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.

[0200] 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 snapshot pair. 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. Therefore, 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 at snapshot S200. In this case, it can compare the provenance ID of its snapshots traced back from S200 to S1 with the provenance ID of the last snapshot of the target FS (the comparison process is also referred to as tracking in this article), and find that S100 in both the source FS and the target FS are matching pairs. 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., the base snapshot) and snapshot 200 (i.e., the new snapshot), and then transfer the delta to the target FS, which can apply the delta 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 start of the replication process. This saves a lot of data and IO transfers.

[0201] 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.13 Shown in.

[0202] 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.

[0203] 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.

[0204] 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 incremental replication 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 a regional clone of three snapshots 1, 2, and 3 between FS1 and FS4 in the same region, plus a cross-region replication of snapshot 7 between FS3 in region 2 and FS4 in region 1. Therefore, the use of provenance IDs saves resources, data transfer traffic (i.e., network or IO traffic), and time.

[0205] 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 based on 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 an x-zone copy between the source FS and the target FS. At step 1408, as discussed above, in some embodiments, the source FS in the source area and the file system in the target area can both 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 x-zone copy or in response to a request to perform x-zone copy. 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 snapshots of target FS (i.e., FS4) and 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.

[0206] At step 1410, if a matching provenance ID is not found between the source FS and the file system in the target zone, then at step 1412, the x-zone copy 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 zone, then at step 1414, the process further determines whether the matching provenance ID belongs to a snapshot of the target FS in the target zone or a snapshot of a non-target FS.

[0207] 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 may perform a clone of the snapshot with the matching provenance ID into a region of the target FS to create a base snapshot. Then, at 1420, the x-region replication may use the cloned base snapshot of the target FS as the selected base snapshot. In other words, the source FS may generate deltas between its latest snapshot and the selected base snapshot with a matching provenance ID, and transfer only the deltas 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 x-region replication (i.e., step 1344).

[0208] 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 applying the delta during the x-region copy.

[0209] In addition to selecting a base snapshot for cross-region replication, in some embodiments, the provenance ID can also help recover when a replication fails or is accidentally deleted. For example, as discussed above, multiple x-region replications may occur between regions. If an x-region replication fails during its replication process, the corresponding source file system and target file system 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 x-region replication. Because FSS uses incremental increments to perform replication, the easier and faster FSS identifies the unique common starting point of the source file system and the target file system, the easier it is for FSS to continue the replication process and recover from failures. The provenance ID avoids the need for a complete base copy every time a failure occurs.

[0210] Snapshot data consistency

[0211] Also disclosed in the present disclosure is a technique for maintaining snapshot consistency between a source FS and a target FS involving snapshot creation and deletion. The first aspect for maintaining snapshot consistency between a source FS and a target FS is the order in which snapshot keys and file data are processed. In some embodiments, the snapshot and data model of the FSS processes snapshot keys and file data in a specific order by first processing snapshot keys and then processing file data. A snapshot key (also referred to as a snapkey) is a B-tree key of a snapshot. Whenever a new snapshot is created in a source region, the source data plane performs incremental generation, involving identifying a new snapshot key for the new snapshot, transmitting to a target region, and the target FS applying and inserting the new snapshot key into its B-tree. Otherwise, the garbage collector in the source region may collect the new snapshot key. Before reading data blocks in the source region, the snapshot key needs to be processed first (i.e., identified and transmitted to the target region) because the snapshot key represents a snapshot and helps distinguish differences between snapshots. In addition, file data is associated with a B-tree key. Therefore, accessing file data before creating a B-tree key in the target FS may cause file system inconsistencies. Finally, in some embodiments, the snapshot key involves billing metering and needs to be established first.

[0212] The snapshot key is the tag key of the snapshot. When an epoch is created, the tag key is also created. Snapshot numbers are created based on epochs, which track the time of the file system. For example, when the epoch advances from N to N+1, the source file system is numbered N+1, and the source FS creates snapshot number N (for system snapshots or user snapshots).

[0213] The second aspect of maintaining snapshot consistency between the source FS and the target FS is handling snapshot deletions. In some embodiments, the FSS uses the data plane (DP) to handle snapshot creation and uses the CP to handle snapshot deletions. As discussed earlier, in addition to customer-generated user snapshots, the snapshot generator in the source DP also periodically generates system snapshots. The delta between two given system snapshots is calculated and copied from the source FS to the target FS. However, snapshots may be deleted during the replication process. Although system snapshots are retained in both the source FS and the target FS until the target FS completes its incremental application, user snapshots in the source area may be updated or deleted at any time during the replication process, but not in the target area. Both the source CP and the target CP need to track and enforce snapshot deletions according to the replication policy. Otherwise, improper handling of snapshot deletions may lead to inconsistencies between the source FS and the target FS.

[0214] Snapshots created in the source area may not be visible to the user until these snapshots are applied by the target file system. For example, if the source FS has three user snapshots S1, S2, and S3, the source CP and the target CP will not notify the user that snapshots S1, S2, and S3 are available in the target area until these snapshots have been recreated in the target FS. The purpose is to prevent users from cloning any of these snapshots when these snapshots in the target area are not ready. In some embodiments, several existing user snapshots (e.g., S1, S2, and S3) can be replicated multiple times from the source FS to one or more target file systems in different areas. Those existing user snapshots in the source FS may need to be copied to one or more target file systems. However, the source FS can create a new system snapshot (e.g., snapshot S4) as a base copy for initial synchronization between the source FS and one or more target file systems before performing the replication.

[0215] In some embodiments, the source CP tracks the deletion of snapshot keys and temporarily retains them in its persistent storage, which are then applied to the source FS and target FS at the end of the replication cycle. Temporary retention or withholding means that the deletion is not immediate, but is postponed for a short period of time depending on other factors. The reason is that if the deletion is applied immediately during the replication window / process, the garbage collector may interfere with the replication process by removing some snapshot keys before they are applied by the target FS, resulting in inconsistencies. In other words, if a file deletion occurs during the replication window, the deletion is temporarily blocked until the replication is completed and then applied to the source FS and target FS. Therefore, deletion application is the final step of the snapshot model. FSS utilizes a scheme called delayed snapshot deletion, which is applicable only to user snapshots.

[0216] Fig.15 is a diagram illustrating delayed snapshot deletion and replication for maintaining consistency between a source FS and a target FS according to some embodiments. Fig.15 In FIG. 1 , the FSS has three replication cycles, starting from a source FS 1510 and ending at a target FS 1530, where the source FS and the target FS are located in different areas. Replication cycle 1 includes source cycle 1 (1512) and target cycle 1 (1532). Replication cycle 2 includes source cycle 2 (1514) and target cycle 2 (1534). Replication cycle 3 includes source cycle 3 (1516) and target cycle 3 (1536). Each replication cycle starts with a system snapshot, such as system snapshot S10 of replication cycle 1, system snapshot S20 of replication cycle 2, and system snapshot S30 of replication cycle 3.

[0217] like Fig.15As shown in , in some embodiments, when a user snapshot is deleted, the source FS retains the snapshot deletion until it receives a notification from the target FS that the deleted snapshot has been applied by the target FS, usually at the end of the current replication cycle. However, the snapshot deletion will not take effect in the target FS until the end of the next replication cycle. This delayed deletion prevents uncertainty and ensures consistency between the source FS and the target FS.

[0218] For example, in Fig.15 In the example, source FS 1510 creates two user snapshots S5 and S7 (shown as "+" to indicate snapshot creation), and then creates system snapshot S10, which starts replication cycle 1 (1512) in the source region at 18:00 UTC. Some time later, snapshots S5, S7, and S10 (shown as +S5, +S7, and +S10) are applied by target FS 1530 during target cycle 1 (1532), starting at UTC 18:05 (when the target FS can download the increments) and ending at UTC 18:15 (i.e., when the incremental application of snapshots S5, S7, and S10 is completed). This (1512 and 1532) completes replication cycle 1 for the two file systems.

[0219] In some embodiments, during replication cycle 1 (1512 and 1532), while these snapshots are being replicated and transferred from source FS 1510 to target FS 1530, before target FS 1530 starts applying these snapshots at UTC 18:05, user snapshot S5 is being deleted (displayed as "-" to indicate snapshot deletion) in source FS 1510 during source cycle 1 (1512). Source CP 1510 allows S5 to continue to be transferred to target FS 1530, but temporarily retains the deletion (i.e., keeps snapshot S5 in the "deleting" state), and then deletes S5 (i.e., CP changes to the "deleted" state for S5) at the end of the entire replication cycle 1 (or target cycle 1 (1532)) after receiving a notification from target FS 1530 indicating that S5 has been applied by target FS 1530 at UTC 18:15. At this point, the internal state is set to the "deleting" state (i.e., pending deletion), so any other requests related to S5 can receive an HTTP 409 response (i.e., indicating that there is a conflict between the other request and the current state of the resource). Fig.15 As shown in , snapshot S5 is not actually deleted (shown as "-S5") by target FS 1530 until replication cycle 2 (or target cycle 2 (1534)) ends at 19:15 UTC time. This delayed deletion of S5 can be called blocked deletion because the snapshot is blocked from immediate deletion.

[0220] In source FS 1510, more snapshots (e.g., S16 and S18) are created, while some snapshots (e.g., S7 and S16) are deleted after replication cycle 1 (1512 and 1532) and before replication cycle 2 (1514 and 1534). Replication cycle 2 starts at 19:00 UTC from the start of source cycle 2 (1514) and ends at 19:15 UTC in target cycle 2 (1534). User snapshot S7 is deleted (displayed as "-S7") between replication cycles 1 and 2, so S7 is deleted by the source FS at the time of the deletion request (also known as non-blocking deletion) and is deleted by the target FS at the end of replication cycle 2 at time 19:15 UTC.

[0221] In some embodiments, when a snapshot is deleted, the state of the corresponding shortcut (a type of tag key) changes from visible to invisible, so no user can read it. Once the shortcut is removed by garbage collection, the state changes from invisible to unretrievable, and the shortcut is removed from the B-tree (i.e., no longer exists in memory). This can be done in the following Fig.15 Snapshot S16 is described in detail.

[0222] exist Fig.15 In the example, in source FS 1510, snapshot S16 that is created (shown as “+S16”) and deleted (shown as “-S16”) within the same incremental range or replication cycle window (i.e., after replication cycle 1 (1532) is completed and before replication cycle 2 (1514) starts incremental calculation) may not be replicated to target FS 1530 because it is not visible for replication purposes even within source FS 1510. Therefore, S16 becomes an inaccessible entry and is not replicated to the target FS at all. Here, S16 becomes visible (i.e., “+S16”) after being created and then becomes invisible (i.e., “-S16”) when it is deleted in the source FS. After the garbage collector removes S16, it becomes irretrievable within the same replication cycle. This scheme can help save some replication resources. Therefore, when snapshots are copied from source FS 1510 to target FS 1530, they may have gaps between S15 to S17 (i.e., S16 is missing).

[0223] As mentioned earlier, user snapshots are controlled by the user. A user snapshot can be deleted only if the user requests that the created snapshot be deleted. For example, in Fig.15 In FIG. 1 , user snapshot S18 is created between replication cycle 1 (1512 and 1532) and replication cycle 2 (1514 and 1534), but is never deleted by the user. Therefore, snapshot S18 can continue to exist and will not be cleaned up by FSS. In contrast, snapshot S7 is created before replication cycle 1 (1512 and 1532) and is later deleted by the user between replication cycle 1 and cycle 2.

[0224] In some embodiments, if a snapshot is created after a replication cycle has started in the source FS (i.e., the delta between two existing snapshots has been calculated), the snapshot may not be transferred from the source FS to the target FS until the next replication cycle. Fig.15 , snapshot 22 (shown as "+S22") is created in source FS1510 during source replication cycle 2 (1514). Since the delta between system snapshot S20 and the earlier snapshot has been calculated and is in the process of being transferred from source FS1510 to target FS1530, S22 may not have been replicated to target FS1530 during the current replication cycle (i.e., cycle 2, 1514, and 1534) before the next replication cycle (i.e., cycle 3, 1516, and 1536). However, if S22 is deleted before replication cycle 3 (1516) begins, then S22 may not be replicated to target FS1530 because it has become irretrievable, similar to the scenario of snapshot S16 discussed above. In addition, if S22 receives a delete request during source replication cycle 3 (1516), then a delayed snapshot deletion scheme can be applied, just like snapshot S5 discussed above.

[0225] Fig.16 16 is a flowchart illustrating the processing of delayed snapshot deletion and replication after detecting a snapshot deletion request according to certain embodiments. At step 1601, the source FS may generate one or more snapshots in the source area. At step 1602, the source FS and the target FS may periodically perform x-region replication. At step 1604, when the source FS detects a snapshot deletion request, for example, a request to delete a user snapshot, at step 1606, the source FS needs to determine whether the snapshot deletion request occurs during the x-region replication cycle of the source FS. If not, then this means that the snapshot deletion request occurs between two replication cycles, for example, after replication cycle N but before replication cycle N+1. At step 1608, the source FS may directly delete the requested snapshot without performing x-region replication on the deleted snapshot.

[0226] The snapshot deleted at step 1608 may or may not have been replicated in the previous replication cycle (i.e., replication cycle N), depending on when the snapshot was created. Either scenario will not affect operations in the current replication cycle (i.e., replication cycle N+1). Fig.15In FIG. 15, snapshot S7 is created before source cycle 1 (1512), and then requested to be deleted between source cycle 1 (1512) and source cycle 2 (1514). Since S7 has already gone through replication cycle 1 (1512 and 1532), there is no need to replicate S7 again. In contrast, snapshot S16 is created between source cycle 1 (1512) and source cycle 2 (1514) and then requested to be deleted. Once source FS 1510 deletes S16, it will never be replicated.

[0227] At step 1606, if the snapshot deletion request occurs during the x-region replication cycle of the source FS, then at step 1620, the source FS may retain (or temporarily withhold) the snapshot deletion, but still allow x-region replication to be performed on the requested snapshot. In other words, the source FS may transfer the requested snapshot to the target FS, the target FS may perform an incremental application on the requested snapshot, and then notify the source FS. At step 1622, when the target FS has completed the x-region replication, the source FS may delete the requested snapshot at the end of the replication cycle. At step 1624, the target FS may not delete the requested snapshot that the target FS has applied in the current replication cycle until the next replication cycle ends (i.e., wait for another replication cycle). For example, in Fig.15 In FIG. 15, the snapshot S5 deletion request occurs during source cycle 1 (1512). The source FS 1510 retains the deletion and passes S5 to the target FS 1530. After the target FS has applied S5 in target cycle 1 (1532), completed the copy and notified the source FS, the source FS then deletes S5 at UTC time 18:15.

[0228] Fig.17 is a flow chart illustrating a process of delaying snapshot deletion and replication after detecting a snapshot creation event according to some embodiments. In some embodiments, if a snapshot is created during an x-region replication cycle (e.g., replication cycle N), but the source FS does not receive a snapshot deletion request before or during the next x-region replication cycle (e.g., replication cycle N+1), then replication of the newly created snapshot is delayed until the next replication cycle.

[0229] exist Fig.17 In step 1702, the source FS and the target FS may periodically perform x-region replication. At step 1704, when the source FS detects a new snapshot creation event, such as a newly created user snapshot, at step 1706, the source FS needs to determine whether the new snapshot is created during the x-region replication cycle of the source FS. If not, then this means that the new snapshot is created between two replication cycles, such as after replication cycle N but before replication cycle N+1. At step 1708, the source FS and the target FS may replicate the new snapshot during the upcoming replication cycle. For example, Fig.15In the example, snapshot S18 is created between source cycle 1 (1512) and source cycle 2 (1514). Then, source FS 1510 and target FS 1530 may replicate S18 during replication 2, source cycle 2 (1514) and target cycle 2 (1534).

[0230] At step 1706, if the new snapshot is created during the x-zone replication cycle of the source FS, then at step 1720, if no snapshot deletion request is received before or during the next replication cycle, the source FS may delay replicating the new snapshot until the next replication cycle. Fig.15 , snapshot S22 is created during source cycle 2 (1514), and no snapshot deletion request is received before or during source cycle 3 (1516). Therefore, source FS 1510 does not start replicating S22 until source cycle 3 (1516), and then transfers S22 to target FS 1530 for application during target cycle 3 (1536).

[0231] The delayed snapshot deletion and replication technique can use a schema table in the SDB of the source FS and another schema table in the SDB of the target FS to temporarily store metadata of the deleted snapshot (e.g. Fig.15 Snapshots during source period 1 (1512) in S5) and track deleted snapshots.

[0232] In some embodiments, the schema table may be a key-value store that contains metadata information including, but not limited to, replication numbers, snapshot numbers that have been applied, snapshot numbers that have been deleted, and workflow IDs of the replicators that handled these snapshots. In other words, such a schema table may help track blocking and non-blocking deleted snapshots in the source FS, and these snapshots may have been applied in the target FS.

[0233] Snapshot metadata transfer between source CP and target CP

[0234] Fig.18 is a flow chart illustrating a control plane workflow for a source region and a target region according to certain embodiments. The workflow may involve snapshot metadata collection for the source region, transfer between the source region and the target region, and metadata application for the target region. Fig.10 As discussed, in certain embodiments, the state machine of the x-zone replication process can be roughly divided into five parts, 1) metadata collection and transmission on the source zone, 2) delta generation and transmission on the source zone, 3) session key generation and transmission between the source zone and the target zone, 4) delta download and application on the target zone, and 5) metadata download and application on the target zone. Fig.18Focus is placed on the first part (ie, metadata collection and transfer on the source zone) and the fifth part (ie, metadata download and application on the target zone) of the x-zone replication process.

[0235] At a high level regarding metadata processing, the source FS may extract snapshot metadata and upload it to the object repository at the start of a replication cycle, for example involving the state of the state machine (which may also be referred to as incremental state in this article) from Ready_to_Copy_Metadata to Snapshot_Metadata_Copied. Uploading metadata at the start of a replication cycle can help detect and resolve any issues with replication as early as possible before large amounts of data transfer begin. The target FS populates the snapshot metadata and performs snapshot deletion after the incremental apply is completed to add the metadata to the existing data. The snapshot metadata transmission may include, but is not limited to, the origin ID, the snapshot type (e.g., system snapshot and user snapshot), and the snapshot time. In addition, snapshot records (such as the creation and deletion of snapshots) are also part of the snapshot metadata transmission. As discussed in the discussion of incremental transfers between source and target regions, Figure 2 compared to, Fig.18 It is about control plane communication between the source and target regions specifically related to snapshot metadata information.

[0236] In general, the source CP tracks the status of snapshot copy and delete activities in the source region and receives verification from the target CP. The source CP and target CP communicate through the SDB in both regions. Fig.18 In step S1, the CP API 1810 can begin recording the status of snapshots, including any deleted snapshots after the replication process begins. At step S2, the source snapshot generator 1812 (a separate thread in the CP API service) scans the replication policy and creates a system snapshot. At step S3, if the source CPAPI 1810 detects a snapshot deletion request during the replication cycle (also referred to as an incremental range from a data perspective), it records the pending deletion to the source SDB 1814 (e.g., the schema table described above). At step S4, the source data plane (DP) / replicator 1816 can check the status of the snapshot creation (e.g., whether a system snapshot has been created). If a new system snapshot has been created, then at step S5, the incremental monitor of the source CP API 1810 can update its incremental state to copying snapshot metadata (Snapshot_Metadata_Copying) (refer to Fig.10In step 1004 in FIG. 1005 ). The incremental monitor may be a thread on the CP API for managing and converting incremental states. At step S6, the source CP 1810 may prepare information about the user snapshot in the current replication cycle by extracting metadata such as the source ID, snapshot type and snapshot time, and snapshot record. The source CP may then store the extracted information in the source SDB 1814.

[0237] Then, at step S7, the replicator 1816 source DP may obtain the metadata information from the source SDB 1814 and upload it to the object repository 1850. For regular increments between system snapshots, they may be uploaded to the object repository at different stages of the same replication cycle. At step S8, the source CP 1810 may change its increment status to snapshot metadata copied (Snapshot_Metadata_Copied) (refer to Fig.10 1806 in step 1006) and update the source SDB 1814 accordingly. Then, the source CP API 1810 notifies the target CP API 1830 (i.e., the FSS target CP host) that the snapshot metadata is in the copied state. The source CP 1810 can also clean up the deleted snapshot records stored in the source SDB 1814 in the current replication cycle. Please note that Fig.18 The second part (ie, delta generation and transfer on the source zone) and the third part (ie, session key generation and transfer) of the x-zone replication process mentioned above are not discussed in .

[0238] After the source FS completes its incremental generation and transfer process, at step S9, the target CP 1830 may update its target SDB 1834 upon receiving a notification from the source CP API 1810, and accordingly change its incremental state to Ready_To_Replicate (refer to Fig.10 At step S10, once the target data plane (DP) (e.g., replicator) 1836 detects that the system snapshot is in the copied state (in the source region) and Ready_To_Replicate (in the target region), and it is ready to replicate, the target DP moves to the next step of incremental apply and then metadata apply.

[0239] At step S11, for incremental replication, the target DP 1836 obtains the incremental from the object repository. At step S12, the target replicator 1836 may apply the incremental to the base snapshot of the target FS in the DP. At step S13, when the target DP 1836 completes the incremental application, it then notifies the target CP 1830 (e.g., incremental monitor) to update the incremental status to the replicated status (see Fig.10, or step 1058 in the example above).

[0240] The target FS can then continue to prepare for metadata download and application. At step S14, the target CP 1830 can change the incremental state to populating snapshot metadata (Snapshot_Metadata_Populating) (refer to Fig.10 At step S15, the target DP 1836 may download the snapshot metadata of the current replication cycle (or between the last snapshot number and the current snapshot number in the architecture) from the object repository and populate the metadata of all snapshots in the range. The target DP 1836 also downloads the deleted snapshot records of the current replication cycle from the object repository. At step S16, the target CP 1830 then updates the incremental state to the populated snapshot metadata (Snapshot_Metadata_Populated) (refer to Fig.10 1062 in step 1062), and notify the source CP 1810.

[0241] At step S17, the target DP 1836 may then locally delete the system snapshot, clean up the corresponding snapshot metadata and the deleted snapshot records. This may complete the current replication cycle (or incremental cycle). At step S18, the target CP 1830 may then move to the state X-region_Done (refer to Fig.10 Step 1068 in the above) and notify the source CP 1810 that the current x-region replication is completed.

[0242] Example Infrastructure as a Service Architecture

[0243] 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.

[0244] 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.

[0245] 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.

[0246] 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.).

[0247] 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.

[0248] 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.

[0249] 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.

[0250] 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.

[0251] Fig.19 1900 is a block diagram illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 1902 can be communicatively coupled to a secure host lease 1904 that can include a virtual cloud network (VCN) 1906 and a secure host subnet 1908. In some examples, the service operator 1902 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 has access to VCN 1906 and / or the Internet.

[0252] VCN 1906 may include a local peer gateway (LPG) 1910, which may be communicatively coupled to a secure shell (SSH) VCN 1912 via the LPG 1910 contained in an SSH VCN 1912. SSH VCN 1912 may include an SSH subnet 1914, and SSH VCN 1912 may be communicatively coupled to a control plane VCN 1916 via the LPG 1910 contained in a control plane VCN 1916. In addition, SSH VCN 1912 may be communicatively coupled to a data plane VCN 1918 via the LPG 1910. Control plane VCN 1916 and data plane VCN 1918 may be contained in a service lease 1919, which may be owned and / or operated by an IaaS provider.

[0253] The control plane VCN 1916 may include a control plane demilitarized zone (DMZ) layer 1920 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 1920 may include one or more load balancer (LB) subnets 1922, a control plane application layer 1924 that may include (one or more) application subnets 1926, and a control plane data layer 1928 that may include (one or more) database (DB) subnets 1930 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 1922 included in the control plane DMZ layer 1920 may be communicatively coupled to the application subnet(s) 1926 included in the control plane application layer 1924 and the Internet gateway 1934 that may be included in the control plane VCN 1916, and the application subnet(s) 1926 may be communicatively coupled to the DB subnet(s) 1930 included in the control plane data layer 1928 as well as the service gateway 1936 and the network address translation (NAT) gateway 1938. The control plane VCN 1916 may include the service gateway 1936 and the NAT gateway 1938.

[0254] The control plane VCN 1916 may include a data plane mirror application layer 1940, which may include application subnet(s) 1926. The application subnet(s) 1926 contained in the data plane mirror application layer 1940 may include a virtual network interface controller (VNIC) 1942 that may execute a compute instance 1944. The compute instance 1944 may communicatively couple the application subnet(s) 1926 of the data plane mirror application layer 1940 to the application subnet(s) 1926 that may be contained in the data plane application layer 1946.

[0255] The data plane VCN 1918 may include a data plane application layer 1946, a data plane DMZ layer 1948, and a data plane data layer 1950. The data plane DMZ layer 1948 may include (one or more) LB subnets 1922, which may be communicatively coupled to (one or more) application subnets 1926 of the data plane application layer 1946 and an Internet gateway 1934 of the data plane VCN 1918. The (one or more) application subnets 1926 may be communicatively coupled to a service gateway 1936 of the data plane VCN 1918 and a NAT gateway 1938 of the data plane VCN 1918. The data plane data layer 1950 may also include (one or more) DB subnets 1930, which may be communicatively coupled to (one or more) application subnets 1926 of the data plane application layer 1946.

[0256] The internet gateway 1934 of the control plane VCN 1916 and the data plane VCN 1918 may be communicatively coupled to a metadata management service 1952, which may be communicatively coupled to a public Internet 1954. The public Internet 1954 may be communicatively coupled to a NAT gateway 1938 of the control plane VCN 1916 and the data plane VCN 1918. The service gateway 1936 of the control plane VCN 1916 and the data plane VCN 1918 may be communicatively coupled to a cloud service 1956.

[0257] In some examples, service gateway 1936 of control plane VCN 1916 or data plane VCN 1918 can make application programming interface (API) calls to cloud services 1956 without going through public internet 1954. API calls from service gateway 1936 to cloud services 1956 can be one-way: service gateway 1936 can make API calls to cloud services 1956, and cloud services 1956 can send requested data to service gateway 1936. However, cloud services 1956 may not initiate API calls to service gateway 1936.

[0258] In some examples, secure host lease 1904 can be directly connected to service lease 1919, which can otherwise be isolated. Secure host subnet 1908 can communicate with SSH subnet 1914 through LPG 1910, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 1908 to SSH subnet 1914 can enable secure host subnet 1908 to access other entities within service lease 1919.

[0259] Control plane VCN 1916 may allow a user of service lease 1919 to set up or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1916 may be deployed or otherwise used in data plane VCN 1918. In some examples, control plane VCN 1916 may be isolated from data plane VCN 1918, and a data plane mirror application layer 1940 of control plane VCN 1916 may communicate with a data plane application layer 1946 of data plane VCN 1918 via a VNIC 1942, which may be included in both data plane mirror application layer 1940 and data plane application layer 1946.

[0260] 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 1954 which may transmit the request to the metadata management service 1952. The metadata management service 1952 may transmit the request to the control plane VCN 1916 through the internet gateway 1934. The request may be received by the LB subnet(s) 1922 contained in the control plane DMZ layer 1920. The LB subnet(s) 1922 may determine that the request is valid, and in response to the determination, the LB subnet(s) 1922 may transmit the request to the application subnet(s) 1926 contained in the control plane application layer 1924. If the request is validated and a call to the public internet 1954 is required, the call to the public internet 1954 may be transmitted to the NAT gateway 1938 which may make the call to the public internet 1954. The metadata that the request may desire to be stored may be stored in the DB subnet(s) 1930.

[0261] In some examples, data plane mirror application layer 1940 may facilitate direct communication between control plane VCN 1916 and data plane VCN 1918. 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 1918. Control plane VCN 1916 may communicate directly with the resources contained in data plane VCN 1918 via VNIC 1942 and may thereby perform changes, updates, or other appropriate modifications to the configuration.

[0262] In some embodiments, control plane VCN 1916 and data plane VCN 1918 may be included in service lease 1919. In this case, a user or customer of the system may not own or operate control plane VCN 1916 or data plane VCN 1918. Alternatively, an IaaS provider may own or operate control plane VCN 1916 and data plane VCN 1918, both of which may be included in service lease 1919. 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 1954 for storage, which may not have the desired level of threat prevention.

[0263] In other embodiments, the LB subnet(s) 1922 contained in the control plane VCN 1916 may be configured to receive signals from the service gateway 1936. In this embodiment, the control plane VCN 1916 and the data plane VCN 1918 may be configured to be called by customers of the IaaS provider without calling the public Internet 1954. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer may be controlled by the IaaS provider and may be stored on the service lease 1919, which may be isolated from the public Internet 1954.

[0264] Fig. 20 2 is a block diagram 2000 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2002 (e.g., Fig.19 The service operator 1902) can be communicatively coupled to the secure host lease 2004 (e.g., Fig.19 The secure host lease 1904 may include a virtual cloud network (VCN) 2006 (e.g., Fig.19 VCN 1906) and secure host subnet 2008 (for example, Fig.19 The VCN 2006 may include a local peer gateway (LPG) 2010 (e.g., Fig.19 1910), which may be communicatively coupled to a secure shell (SSH) VCN 2012 via an LPG 1910 contained in an SSH VCN 2012 (e.g., Fig.19 SSH VCN 2012 may include SSH subnet 2014 (e.g., Fig.19 SSH subnet 1914), and SSH VCN 2012 can be communicatively coupled to control plane VCN 2016 via LPG 2010 contained in control plane VCN 2016 (e.g., Fig.19 The control plane VCN 1916). The control plane VCN 2016 can be included in the service lease 2019 (e.g., Fig.19 service lease 1919), and the data plane VCN 2018 (for example, Fig.19 The data plane VCN 1918) may be contained in a customer lease 2021 which may be owned or operated by a user or customer of the system.

[0265] The control plane VCN 2016 may include a control plane DMZ layer 2020 (e.g., Fig.19 The control plane DMZ layer 1920) may include (one or more) LB subnets 2022 (e.g., Fig.19 (one or more) LB subnets 1922), may include (one or more) application subnets 2026 (e.g., Fig.19 (one or more) application subnets 1926) of the control plane application layer 2024 (e.g., Fig.19 The control plane application layer 1924 of FIG. 10 may include (one or more) database (DB) subnets 2030 (e.g., similar to Fig.19 (one or more) DB subnets 1930) of the control plane data layer 2028 (e.g., Fig.19 The LB subnet(s) 2022 contained in the control plane DMZ layer 2020 may be communicatively coupled to the application subnet(s) 2026 contained in the control plane application layer 2024 and the Internet gateway 2034 (e.g., Fig.19 1934), and the application subnet(s) 2026 may be communicatively coupled to the DB subnet(s) 2030 and the service gateway 2036 (e.g., Fig.19 service gateway 1936) and network address translation (NAT) gateway 2038 (e.g., Fig.19NAT gateway 1938). The control plane VCN 2016 may include a service gateway 2036 and a NAT gateway 2038.

[0266] The control plane VCN 2016 may include a data plane mirror application layer 2040 (e.g., Fig.19 The data plane image application layer 1940). The (one or more) application subnets 2026 included in the data plane image application layer 2040 may include a computing instance 2044 (e.g., similar to Fig.19 The compute instance 2044 may facilitate the application subnet(s) 2026 of the data plane mirroring application layer 2040 and the application subnets 2026 that may be included in the data plane application layer 2046 (e.g., Fig.19 Communication between (one or more) application subnets 2026 in the data plane application layer 1946) via the VNIC 2042 contained in the data plane mirror application layer 2040 and the VNIC 2042 contained in the data plane application layer 2046.

[0267] The Internet gateway 2034 included in the control plane VCN 2016 can be communicatively coupled to the metadata management service 2052 (e.g., Fig.19 2052), which can be communicatively coupled to the public Internet 2054 (e.g., Fig.19 The public Internet 2054 can be communicatively coupled to a NAT gateway 2038 included in the control plane VCN 2016. The service gateway 2036 included in the control plane VCN 2016 can be communicatively coupled to a cloud service 2056 (e.g., Fig.19 Cloud services 1956).

[0268] In some examples, the data plane VCN 2018 may be contained in a customer lease 2021. In this case, the IaaS provider may provide a control plane VCN 2016 for each customer, and the IaaS provider may provision a unique compute instance 2044 contained in a service lease 2019 for each customer. Each compute instance 2044 may allow communication between the control plane VCN 2016 contained in the service lease 2019 and the data plane VCN 2018 contained in the customer lease 2021. The compute instance 2044 may allow resources provisioned in the control plane VCN 2016 contained in the service lease 2019 to be deployed or otherwise used in the data plane VCN 2018 contained in the customer lease 2021.

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

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

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

[0272] Fig.21 21 is a block diagram 2100 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2102 (e.g., Fig.19 The service operator 1902) can be communicatively coupled to the secure host lease 2104 (e.g., Fig.19 The secure host lease 2104 may include a virtual cloud network (VCN) 2106 (e.g., Fig.19 VCN 1906) and secure host subnet 2108 (e.g., Fig.19 VCN 2106 may include LPG 2110 (e.g., Fig.19 1910), which may be communicatively coupled to the SSH VCN 2112 via the LPG 2110 contained in the SSH VCN 2112 (e.g., Fig.19 SSH VCN 2112 may include SSH subnet 2114 (e.g., Fig.19 SSH subnet 1914), and SSH VCN 2112 may be communicatively coupled to control plane VCN 2116 via LPG 2110 included in control plane VCN 2116 (e.g., Fig.19The control plane VCN 1916 of the present invention is coupled to the data plane VCN 2118 via the LPG 2110 contained in the data plane VCN 2118 (e.g., Fig.19 The control plane VCN 2116 and the data plane VCN 2118 may be included in a service lease 2119 (e.g., Fig.19 of the service lease 1919).

[0273] The control plane VCN 2116 may include a load balancer (LB) subnet 2122 (e.g., Fig.19 (one or more) LB subnets 1922) of the control plane DMZ layer 2120 (e.g., Fig.19 The control plane DMZ layer 1920 may include (one or more) application subnets 2126 (e.g., similar to Fig.19 (one or more) application subnets 1926) of the control plane application layer 2124 (e.g., Fig.19 The control plane application layer 1924 of the embodiment of the present invention may include a control plane data layer 2128 (e.g., Fig.19 The LB subnet(s) 2122 contained in the control plane DMZ layer 2120 may be communicatively coupled to the application subnet(s) 2126 contained in the control plane application layer 2124 and the Internet gateway 2134 (e.g., Fig.19 1934), and the application subnet(s) 2126 may be communicatively coupled to the DB subnet(s) 2130 and the service gateway 2136 (e.g., Fig.19 ) and a network address translation (NAT) gateway 2138 (e.g., Fig.19 NAT gateway 1938). The control plane VCN 2116 may include a service gateway 2136 and a NAT gateway 2138.

[0274] The data plane VCN 2118 may include a data plane application layer 2146 (e.g., Fig.19 Data plane application layer 1946), data plane DMZ layer 2148 (e.g., Fig.19 Data plane DMZ layer 1948), and data plane data layer 2150 (e.g., Fig.19The data plane DMZ layer 2148 may include (one or more) trusted application subnets 2160 and (one or more) untrusted application subnets 2162 that may be communicatively coupled to the data plane application layer 2146 and (one or more) LB subnets 2122 of the Internet gateway 2134 included in the data plane VCN 2118. The (one or more) trusted application subnets 2160 may be communicatively coupled to the service gateway 2136 included in the data plane VCN 2118, the NAT gateway 2138 included in the data plane VCN 2118, and (one or more) DB subnets 2130 included in the data plane data layer 2150. The (one or more) untrusted application subnets 2162 may be communicatively coupled to the service gateway 2136 included in the data plane VCN 2118 and (one or more) DB subnets 2130 included in the data plane data layer 2150. Data plane data layer 2150 may include DB subnet(s) 2130 that may be communicatively coupled to a service gateway 2136 included in data plane VCN 2118 .

[0275] The untrusted application subnet(s) 2162 may include one or more primary VNICs 2164(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2166(1)-(N). Each tenant VM 2166(1)-(N) may be communicatively coupled to a respective application subnet 2167(1)-(N) that may be contained in a respective container egress VCN 2168(1)-(N), which may be contained in a respective customer tenancy 2170(1)-(N). A respective secondary VNIC 2172(1)-(N) may facilitate communications between the untrusted application subnet(s) 2162 contained in the data plane VCN 2118 and the application subnets contained in the container egress VCN 2168(1)-(N). Each container egress VCN 2168(1)-(N) may include a NAT gateway 2138 that may be communicatively coupled to the public Internet 2154 (e.g., Fig.19 The public internet (1954).

[0276] The Internet gateway 2134 included in the control plane VCN 2116 and included in the data plane VCN 2118 can be communicatively coupled to the metadata management service 2152 (e.g., Fig.192154) can be communicatively coupled to the public Internet 2154. The public Internet 2154 can be communicatively coupled to the NAT gateway 2138 contained in the control plane VCN 2116 and contained in the data plane VCN 2118. The service gateway 2136 contained in the control plane VCN 2116 and contained in the data plane VCN 2118 can be communicatively coupled to the cloud service 2156.

[0277] In some embodiments, data plane VCN 2118 may be integrated with customer lease 2170. 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.

[0278] 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 2146. Code running the functionality may be executed in a VM 2166(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 2118. Each VM 2166(1)-(N) may be connected to a customer tenancy 2170. The corresponding container 2171(1)-(N) contained in the VM 2166(1)-(N) may be configured to run the code. In this case, there may be double isolation (e.g., the container 2171(1)-(N) runs the code, where the container 2171(1)-(N) may be contained at least in a VM 2166(1)-(N) contained in (one or more) untrusted application subnets 2162), 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 2171(1)-(N) may be communicatively coupled to customer lease 2170 and may be configured to transmit or receive data from customer lease 2170. Containers 2171(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 2118. After running the code is complete, the IaaS provider may terminate or otherwise dispose of containers 2171(1)-(N).

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

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

[0281] Fig. 22 2200 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2202 (e.g., Fig.19 The service operator 1902) can be communicatively coupled to the secure host lease 2204 (e.g., Fig.19 The secure host lease 2204 may include a virtual cloud network (VCN) 2206 (e.g., Fig.19 VCN 1906) and secure host subnet 2208 (e.g., Fig.19 VCN 2206 may include LPG 2210 (e.g., Fig.19 LPG 1910), which LPG 2210 can be included in the SSH VCN 2212 (for example, Fig.19LPG 2210 in SSH VCN 1912 of the present invention is communicatively coupled to SSH VCN 2212. SSH VCN 2212 may include SSH subnet 2214 (e.g., Fig.19 SSH subnet 1914), and SSH VCN 2212 can be communicatively coupled to control plane VCN 2216 via LPG 2210 contained in control plane VCN 2216 (e.g., Fig.19 The control plane VCN 1916 of the present invention is coupled to the data plane VCN 2218 via the LPG 2210 contained in the data plane VCN 2218 (e.g., Fig.19 The control plane VCN 2216 and the data plane VCN 2218 may be included in a service lease 2219 (e.g., Fig.19 of the service lease 1919).

[0282] The control plane VCN 2216 may include a LB subnet 2222 (e.g., Fig.19 (one or more) LB subnets 1922) of the control plane DMZ layer 2220 (e.g., Fig.19 The control plane DMZ layer 1920 may include (one or more) application subnets 2226 (e.g., Fig.19 (one or more) application subnets 1926) of the control plane application layer 2224 (e.g., Fig.19 control plane application layer 1924), may include (one or more) DB subnets 2230 (e.g., Fig.21 (one or more) DB subnets 2130) of the control plane data layer 2228 (e.g., Fig.19 The LB subnet(s) 2222 contained in the control plane DMZ layer 2220 may be communicatively coupled to the application subnet(s) 2226 contained in the control plane application layer 2224 and the Internet gateway 2234 (e.g., Fig.19 1934), and the application subnet(s) 2226 may be communicatively coupled to the DB subnet(s) 2230 and the service gateway 2236 (e.g., Fig.19 ) and a network address translation (NAT) gateway 2238 (e.g., Fig.19 NAT gateway 1938). The control plane VCN 2216 may include a service gateway 2236 and a NAT gateway 2238.

[0283] The data plane VCN 2218 may include a data plane application layer 2246 (e.g., Fig.19 Data plane application layer 1946), data plane DMZ layer 2248 (e.g., Fig.19 Data plane DMZ layer 1948)), and data plane data layer 2250 (e.g., Fig.19 The data plane DMZ layer 2248 may include (one or more) trusted application subnets 2260 (e.g., Fig.21 (one or more) trusted application subnets 2160) and (one or more) untrusted application subnets 2262 (e.g., Fig.21 The trusted application subnet(s) 2260 may be communicatively coupled to the service gateway 2236 contained in the data plane VCN 2218, the NAT gateway 2238 contained in the data plane VCN 2218, and the DB subnet(s) 2230 contained in the data plane data layer 2250. The untrusted application subnet(s) 2262 may be communicatively coupled to the service gateway 2236 contained in the data plane VCN 2218 and the DB subnet(s) 2230 contained in the data plane data layer 2250. The data plane data layer 2250 may include the DB subnet(s) 2230 that may be communicatively coupled to the service gateway 2236 contained in the data plane VCN 2218.

[0284] The untrusted application subnet(s) 2262 may include primary VNICs 2264(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2266(1)-(N) residing within the untrusted application subnet(s) 2262. Each tenant VM 2266(1)-(N) may run code in a corresponding container 2267(1)-(N) and may be communicatively coupled to an application subnet 2226 contained in a data plane application layer 2246 contained in a container egress VCN 2268. Corresponding secondary VNICs 2272(1)-(N) may facilitate communications between the untrusted application subnet(s) 2262 contained in the data plane VCN 2218 and the application subnets contained in the container egress VCN 2268. The container egress VCN may include a primary VNIC 2264(1)-(N) that may be communicatively coupled to a public Internet 2254 (e.g., Fig.19 NAT gateway 2238 of the public Internet 1954).

[0285] The Internet gateway 2234 included in the control plane VCN 2216 and included in the data plane VCN 2218 can be communicatively coupled to the metadata management service 2252 (e.g., Fig.19 2254) can be communicatively coupled to the public Internet 2254. The public Internet 2254 can be communicatively coupled to a NAT gateway 2238 contained in the control plane VCN 2216 and contained in the data plane VCN 2218. A service gateway 2236 contained in the control plane VCN 2216 and contained in the data plane VCN 2218 can be communicatively coupled to the cloud service 2256.

[0286] In some examples, Fig. 22 The architecture model shown in block diagram 2200 can be considered as Fig.21 2100 , and may be desired by customers of the IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer may access the corresponding container 2267(1)-(N) contained in each customer's VM 2266(1)-(N) in real time. The container 2267(1)-(N) may be configured to make calls to the corresponding secondary VNIC 2272(1)-(N) contained in the (one or more) application subnets 2226 of the data plane application layer 2246, which may be contained in the container egress VCN 2268. The secondary VNIC 2272(1)-(N) may transmit the call to the NAT gateway 2238, which may transmit the call to the public Internet 2254. In this example, containers 2267(1)-(N), which may be accessed by customers in real time, may be isolated from control plane VCN 2216 and may be isolated from other entities contained in data plane VCN 2218. Containers 2267(1)-(N) may also be isolated from resources from other customers.

[0287] In other examples, a customer can use containers 2267(1)-(N) to call cloud service 2256. In this example, a customer can run code in containers 2267(1)-(N) to request a service from cloud service 2256. Containers 2267(1)-(N) can transmit the request to secondary VNICs 2272(1)-(N), which can transmit the request to a NAT gateway, which can transmit the request to the public Internet 2254. The public Internet 2254 can transmit the request to LB subnet(s) 2222 included in control plane VCN 2216 via Internet gateway 2234. In response to determining that the request is valid, the LB subnet(s) can transmit the request to application subnet(s) 2226, which can transmit the request to cloud service 2256 via service gateway 2236.

[0288] It should be appreciated that the IaaS architectures 1900, 2000, 2100, 2200 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.

[0289] 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.

[0290] Fig.23 An example computer system 2300 is illustrated in which various embodiments may be implemented. System 2300 may be used to implement any of the computer systems described above. As shown, computer system 2300 includes a processing unit 2304 that communicates with multiple peripheral subsystems via a bus subsystem 2302. These peripheral subsystems may include a processing acceleration unit 2306, an I / O subsystem 2308, a storage subsystem 2318, and a communication subsystem 2324. Storage subsystem 2318 includes a tangible computer-readable storage medium 2322 and a system memory 2310.

[0291] The bus subsystem 2302 provides a mechanism for allowing the various components and subsystems of the computer system 2300 to communicate with each other by intention. Although the bus subsystem 2302 is schematically shown as a single bus, an alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 2302 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.

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

[0293] In various embodiments, the processing unit 2304 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 2304 and / or in the storage subsystem 2318. Through appropriate programming, (one or more) processors 2304 can provide the various functions described above. The computer system 2300 can additionally include a processing acceleration unit 2306, which can include a digital signal processor (DSP), a special processor, and the like.

[0294] I / O subsystem 2308 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.

[0295] 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.

[0296] 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 2300 to a user or other computer. 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.

[0297] Computer system 2300 may include storage subsystem 2318, which 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., which, when executed by one or more cores or processors of processing unit 2304, provide the above-described functionality. Storage subsystem 2318 may also provide a repository for storing data used in accordance with the present disclosure.

[0298] like Fig.23 As shown in the example in , storage subsystem 2318 may include various components, including system memory 2310, computer-readable storage media 2322, and computer-readable storage media reader 2320. System memory 2310 may store program instructions that may be loaded and executed by processing unit 2304. System memory 2310 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 2310, including but not limited to client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0299] System memory 2310 may also store an operating system 2316. Examples of operating system 2316 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 2300 executes one or more virtual machines, the virtual machines and their guest operating systems (GOS) may be loaded into the system memory 2310 and executed by one or more processors or cores of the processing unit 2304 .

[0300] The system memory 2310 can be configured in different ways, depending on the type of computer system 2300. For example, the system memory 2310 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 embodiments, the system memory 2310 can include a basic input / output system (BIOS), which contains the basic routines that help transfer information between elements within the computer system 2300, such as during startup.

[0301] Computer-readable storage media 2322 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 2300 (including instructions executable by processing unit 2304 of computer system 2300).

[0302] Computer readable storage media 2322 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.

[0303] As examples, computer-readable storage media 2322 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 optical drives). Computer readable storage media 2322 may include, but are not limited to, The computer readable storage medium 2322 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 2300.

[0304] Machine-readable instructions executable by one or more processors or cores of processing unit 2304 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.

[0305] The communication subsystem 2324 provides an interface to other computer systems and networks. The communication subsystem 2324 is used as an interface for receiving data from other systems and transmitting data from the computer system 2300 to other systems. For example, the communication subsystem 2324 can enable the computer system 2300 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 2324 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 2324 may provide a wired network connection (e.g., Ethernet).

[0306] In some embodiments, the communication subsystem 2324 may also receive input communications in the form of structured and / or unstructured data feeds 2326 , event streams 2328 , event updates 2330 , and the like on behalf of one or more users who may use the computer system 2300 .

[0307] As an example, the communication subsystem 2324 may be configured to receive data feeds 2326 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.

[0308] Additionally, the communication subsystem 2324 may also be configured to receive data in the form of a continuous data stream, which may include event streams 2328 and / or event updates 2330, 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.

[0309] The communication subsystem 2324 may also be configured to output structured and / or unstructured data feeds 2326, event streams 2328, event updates 2330, 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 2300.

[0310] Computer system 2300 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.

[0311] Due to the ever-changing nature of computers and networks, the description of the computer system 2300 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 adopted. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will recognize other ways and / or methods for implementing various embodiments.

[0312] 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.

[0313] 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.

[0314] 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.

[0315] Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive. However, 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.

[0316] 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 (including)" and "include (containing)" 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 of individually referencing 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. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0317] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in the context generally used to indicate that an item, term, or the like, can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless expressly stated otherwise. 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.

[0318] 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.

[0319] 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.

[0320] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but those skilled in the art will appreciate 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 embodiment can be used in any number of environments and applications other than those described herein. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0321] Clause 1: A computer-implemented method comprising:

[0322] Generating, by the computing system, a snapshot of the source file system in the source area;

[0323] Performing, by the computing system, a first cross-region replication and a second 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 located in different regions;

[0324] Receiving, by the computing system, a snapshot deletion request in the source file system to delete the snapshot;

[0325] Determining, by the computing system, a time of a snapshot deletion request in the source file system;

[0326] The computing system performs a first operation according to the timing of the snapshot deletion request being determined to be during the first cross-region replication period;

[0327] The computing system performs a second operation according to determining that the time of the snapshot deletion request is between the first cross-region replication and the second cross-region replication.

[0328] Clause 2: The method of clause 1, wherein the first operation comprises withholding, by the source file system, the snapshot deletion request until the first cross-region replication is complete.

[0329] Clause 3: The method of clause 1 or clause 2, wherein withholding the snapshot deletion request comprises storing, by the source file system, metadata information of the snapshot in a database for communication to the target file system.

[0330] Clause 4: The method of any one of clauses 1 to 3, wherein withholding the snapshot deletion request comprises:

[0331] The source file system transmits the snapshot to the target file system to complete the first cross-region replication;

[0332] The snapshot is deleted by the target file system at the end of the second cross-region copy.

[0333] Clause 5: The method of any of clauses 1 to 4, wherein the second operation comprises deleting the snapshot by the source file system without transferring the snapshot to the target file system.

[0334] Clause 6: The method of any one of clauses 1 to 5, further comprising determining a second time to generate a snapshot of the source file system.

[0335] Clause 7: The method as described in Clause 6 also includes: based on the second moment of snapshot generation being determined as during the first cross-region replication and based on the moment of snapshot deletion request being determined as after the second cross-region replication, transferring the generated snapshot to the target file system during the second cross-region replication.

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

[0337] Generating, by the computing system, a snapshot of the source file system in the source area;

[0338] Performing, by the computing system, a first cross-region replication and a second 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 located in different regions;

[0339] Receiving, by the computing system, a snapshot deletion request in the source file system to delete the snapshot;

[0340] Determining, by the computing system, a time of a snapshot deletion request in the source file system;

[0341] The computing system performs a first operation according to the timing of the snapshot deletion request being determined to be during the first cross-region replication period;

[0342] The computing system performs a second operation according to determining that the time of the snapshot deletion request is between the first cross-region replication and the second cross-region replication.

[0343] Clause 9: The non-transitory computer-readable medium of Clause 8, wherein the first operation comprises withholding, by the source file system, the snapshot deletion request until the first cross-region replication ends.

[0344] Clause 10: The non-transitory computer-readable medium of clause 8 or clause 9, wherein withholding the snapshot deletion request comprises storing, by the source file system, metadata information of the snapshot in a database for communication to the target file system.

[0345] Clause 11: The non-transitory computer-readable medium of any of clauses 8 to 10, wherein the withholding snapshot deletion request comprises:

[0346] The source file system transmits the snapshot to the target file system to complete the first cross-region replication;

[0347] The snapshot is deleted by the target file system at the end of the second cross-region copy.

[0348] Clause 12: The non-transitory computer-readable medium of any of Clauses 8 to 11, wherein the second operation comprises deleting, by the source file system, the snapshot without transferring the snapshot to the target file system.

[0349] Clause 13: The non-transitory computer-readable medium of any of Clauses 8 to 12, the operations further comprising determining a second time to generate the snapshot of the source file system.

[0350] Clause 14: The non-transitory computer-readable medium of Clause 13, wherein the operation further comprises: transferring the generated snapshot to the target file system during the second cross-region replication according to the second moment of snapshot generation being determined as during the first cross-region replication and according to the moment of snapshot deletion request being determined as after the second cross-region replication.

[0351] Clause 15: A system comprising:

[0352] one or more processors; and

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

[0354] Create a snapshot of the source file system in the source region;

[0355] performing a first cross-region replication and a second 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 located in different regions;

[0356] receiving a snapshot deletion request in a source file system to delete the snapshot;

[0357] Determine a moment of a snapshot deletion request in a source file system;

[0358] According to the timing of the snapshot deletion request being determined to be during the first cross-region replication, performing a first operation;

[0359] According to determining that the time of the snapshot deletion request is determined to be between the first cross-region replication and the second cross-region replication, a second operation is performed.

[0360] Clause 16: The system of clause 15, wherein the first operation comprises withholding, by the source file system, the snapshot deletion request until the first cross-region replication is complete.

[0361] Clause 17: The system of clause 15 or clause 16, wherein the withheld snapshot deletion request comprises:

[0362] The source file system transmits the snapshot to the target file system to complete the first cross-region replication;

[0363] The snapshot is deleted by the target file system at the end of the second cross-region copy.

[0364] Clause 18: The system of any of Clauses 1 to 17, wherein the second operation comprises deleting, by the source file system, the snapshot without transferring the snapshot to the target file system.

[0365] Clause 19: The system of any of Clauses 1 to 18, wherein the system is further caused to determine a second time at which to generate the snapshot of the source file system.

[0366] Clause 20: A system as described in Clause 19, wherein the system is further configured to transfer the generated snapshot to the target file system during the second cross-region replication based on the second moment of snapshot generation being determined as during the first cross-region replication and the moment of snapshot deletion request being determined as after the second cross-region replication.

Claims

1. A method comprising: Generating, by the computing system, a first snapshot and a second snapshot in a source file system in a source area; Assigning, by the computing system, a first provenance identifier for the first snapshot and a second provenance identifier for the second snapshot in the source file system, the first provenance identifier being unique among all snapshots in all regions, and the second provenance identifier being unique among all snapshots in all regions; Receiving, by a computing system, a request to perform replication between a source file system in a source zone and a target file system in a target zone, the source zone and the target zone being located in different zones; Comparing, by the computing system at least in response to the request, a first provenance identifier in the source file system with provenance identifiers of existing snapshots in the target area; identifying, by the computing system, a matching snapshot in the target region having a first provenance identifier based at least in part on the comparison to serve as a base snapshot for copying; as well as The copying is performed by the computing system using a delta between the second snapshot and the base snapshot in the source file system. 2 . The method of claim 1 , further comprising selecting the matching snapshot as the base snapshot in response to at least a matching snapshot having the first provenance identifier in the target area being located in the target file system.

3. The method of claim 1 or claim 2, wherein the target area includes a non-target file system having a snapshot associated with the first provenance identifier.

4. The method according to any one of claims 1 to 3, further comprising: In response to at least that the matching snapshot with the first provenance identifier in the target area is not in the target file system, copying the matching snapshot with the first provenance identifier from the non-target file system to the area of ​​the target file system; as well as Select a copy in the target file system that matches the snapshot's region as the base snapshot.

5. The method according to any one of claims 1 to 4, wherein the copy in the area of ​​the matching snapshot in the target file system and the matching snapshot in the non-target file system have the same first provenance identifier, but have different resource identifiers.

6. The method according to any one of the preceding claims, further comprising selecting a first snapshot with the first provenance identifier in the source file system as the base snapshot at least in response to not finding a matching snapshot with the first provenance identifier in the target area.

7. The method according to any one of claims 1 to 6, further comprising performing a cross-region copy of the first snapshot with the first provenance identifier from the source file system to the target file system before generating a delta between the second snapshot and the base snapshot in the source file system.

8. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by one or more processors, cause the one or more processors to perform operations comprising: Generating, by the computing system, a first snapshot and a second snapshot in a source file system in a source area; Assigning, by the computing system, a first provenance identifier for the first snapshot and a second provenance identifier for the second snapshot in the source file system, the first provenance identifier being unique among all snapshots in all regions, and the second provenance identifier being unique among all snapshots in all regions; Receiving, by a computing system, a request to perform replication between a source file system in a source zone and a target file system in a target zone, the source zone and the target zone being located in different zones; Comparing, by the computing system at least in response to the request, a first provenance identifier in the source file system with provenance identifiers of existing snapshots in the target area; identifying, by the computing system, a matching snapshot in the target region having a first provenance identifier based at least in part on the comparison to serve as a base snapshot for copying; as well as The replication between the source file system and the target file system is performed by the computing system using a delta between the second snapshot and the base snapshot in the source file system.

9. The non-transitory computer-readable medium of claim 8, the operations further comprising selecting the matching snapshot as the base snapshot in response to at least a matching snapshot having the first provenance identifier in the target area being located in the target file system.

10. The non-transitory computer readable medium of claim 8 or claim 9, wherein the target area comprises a non-target file system having a snapshot associated with the first provenance identifier.

11. The non-transitory computer readable medium of claim 10, the operations further comprising: In response to at least that the matching snapshot with the first provenance identifier in the target area is not in the target file system, copying the matching snapshot with the first provenance identifier from the non-target file system to the area of ​​the target file system; as well as Select a copy in the target file system that matches the snapshot's region as the base snapshot.

12. The non-transitory computer-readable medium of any one of claims 8 to 11, the operation further comprising selecting a first snapshot with the first provenance identifier in the source file system as a base snapshot at least in response to not finding a matching snapshot with the first provenance identifier in the target area.

13. The non-transitory computer-readable medium of claim 12, the operations further comprising performing a cross-region copy of the first snapshot having the first provenance identifier from the source file system to the target file system before generating a delta between the second snapshot and the base snapshot in the source file system. 14 . The non-transitory computer-readable medium of claim 13 , wherein the cross-region copy of the first snapshot in the target file system has the same first origin identifier as the first snapshot in the source file system, but has a different resource identifier.

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: Generating a first snapshot and a second snapshot in a source file system in a source area; Assigning a first provenance identifier to the first snapshot and a second provenance identifier to the second snapshot in the source file system, the first provenance identifier being unique among all snapshots in all regions, and the second provenance identifier being unique among all snapshots in all regions; receiving a request to perform replication between a source file system in a source zone and a target file system in a target zone, the source zone and the target zone being in different zones; comparing, in response to at least the request, a first provenance identifier in the source file system with provenance identifiers of existing snapshots in the target area; identifying, based at least in part on the comparing, a matching snapshot in the target region having a first provenance identifier to serve as a base snapshot for copying; as well as Replication between the source file system and the target file system is performed by using a delta between the second snapshot and the base snapshot in the source file system. 16 . The system of claim 15 , wherein the system is further configured to select the matching snapshot as the base snapshot in response to at least a matching snapshot having the first origin identifier in the target area being located in the target file system.

17. The system of claim 15 or 16, wherein the target area includes a non-target file system having a snapshot associated with the first provenance identifier.

18. The system of claim 17, wherein the system is further configured to: At least in response to the matching snapshot with the first provenance identifier in the target area not being in the target file system, copying the matching snapshot with the first provenance identifier from the non-target file system to the area in the target file system; and Select a copy in the target file system that matches the snapshot's region as the base snapshot.

19. The system according to any one of claims 15 to 18, wherein the system is further configured to select a first snapshot with the first provenance identifier in the source file system as a base snapshot in response to at least not finding a matching snapshot with the first provenance identifier in the target area.

20. The system of claim 19, further causing the system to perform a cross-region copy of the first snapshot with the first origin identifier from the source file system to the target file system before generating a delta between the second snapshot and the base snapshot in the source file system.

Images