Techniques for copy checkpoint operations during disaster recovery

Abstract

Techniques are described for checkpoint operations on multiple key ranges in parallel and concurrently during file storage replication between file systems in different cloud infrastructure areas. In some embodiments, multiple range threads (one thread per key range) that process multiple key ranges create checkpoints for their respective key ranges in parallel and concurrently after processing a predetermined number of B-tree keys. In some embodiments, each thread requests a lock to a central checkpoint record and is used in turn to update status bytes while continuing to process B-tree keys in the key range in which it is responsible. In some embodiments, upon encountering a fault event such as a system crash or a thread fault, each thread resumes its B-tree key processing from a B-tree key after the most recent checkpoint. In some embodiments, within the key range, two generation numbers are assigned to two sets of processed B-tree key value pairs, one before a fault event and one after the fault event.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Non-Provisional Application No. 18 / 304,161, filed on April 20, 2023, entitled “TECHNIQUES FOR REPLICATION CHECK POINTING DURING DISASTER RECOVERY” and U.S. Non-Provisional Application No. 18 / 304,161, filed on April 20, 2023, entitled “TECHNIQUES FOR MAINTAINING DATA CONSISTENCY DURING DISASTER RECOVERY” all of which claim the benefit of and priority to U.S. Provisional Application No. 63 / 352,992 filed on June 16, 2022, U.S. Provisional Application No. 63 / 357,526 filed on June 30, 2022, U.S. Provisional Application No. 63 / 412,243 filed on September 30, 2022, and U.S. Provisional Application No. 63 / 378,486 filed on October 5, 2022, under 35 U.S.C. 119(e), the disclosures of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] The present disclosure relates generally to file systems. More specifically, but not limited to, techniques are described for checkpointing multiple key ranges in parallel and concurrently while maintaining data consistency in the event of a failure during file storage replication between file systems in different cloud infrastructure regions. Background Art

[0004] The replication process for disaster recovery may fail due to various reasons including crash, lease expiration, object storage device failure, unsuccessful deployment, patching, etc. Checkpointing plays an important role during the file system replication process by periodically saving necessary information and allowing to minimize the risk of data loss or corruption and continue from a consistent point without starting from the beginning, thus saving time. In addition, parallel processing is used to improve performance. However, there is a need to enhance the checkpoint operation and data consistency during replication. Summary of the invention

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

[0006] In certain embodiments, a technique is provided that includes a method comprising: receiving, by a computing system, a request for a file system copy between a source file system and a target file system, the source file system and the target file system being in different regions; creating, by a first processing thread of the computing system, a checkpoint in the first key range after satisfying predetermined requirements for processing binary tree (B-tree) key-value pairs in the first key range; requesting, by the first processing thread of the computing system, a lock for updating a central record after creating the checkpoint in the first key range; creating, by a second processing thread of the computing system, a checkpoint in a second key range after satisfying predetermined requirements for processing the B-tree key-value pairs in the second key range; requesting, by the second processing thread of the computing system, the lock for updating the central record after creating the checkpoint in the second key range; and granting, by the computing system, the lock to the first processing thread to update the central record, the request by the first processing thread being earlier than the request by the second processing thread.

[0007] In yet another embodiment, the lock prevents the second processing thread from updating the central record.

[0008] In another embodiment, the method further includes: processing, by the first processing thread, more B-tree key-value pairs in the first key range after updating the central record; and granting, by the computing system, a lock to the second processing thread to update the central record after the first processing thread completes updating the central record.

[0009] In yet another embodiment, the method further includes processing, by the second processing thread, more B-tree key-value pairs in the second key range while waiting for the lock.

[0010] In yet another embodiment, the first processing thread operates independently of the second processing thread.

[0011] In yet another embodiment, processing of B-tree key-value pairs in a first key range by a first processing thread is performed in parallel with processing of B-tree key-value pairs in a second key range by a second processing thread.

[0012] In yet another embodiment, the method further includes resuming, by the first processing thread, processing of B-tree key-value pairs in the first key range from a B-tree key after a checkpoint in the first key range when a system failure is detected.

[0013] In yet another embodiment, the method further includes resuming processing of B-tree key-value pairs in the first key range by a third processing thread from a B-tree key after a checkpoint in the first key range when a failure of the first processing thread is detected.

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

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

[0016] 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. 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 illustrating 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 of cross-region replication according to certain embodiments.

[0025] Figure 7is 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 simplified example diagram illustrating key range processing for delta generation during cross-region replication in accordance with certain embodiments.

[0032] Fig.14 is a flow chart illustrating the end-to-end process flow of delta generation and delta application during cross-region replication according to certain embodiments.

[0033] Fig.15 Illustrated is a generation log of incremental generation and application processing according to certain embodiments.

[0034] Fig.16 is a flow diagram illustrating key range processing of generation records involving delta generation and application during cross-region replication in accordance with certain embodiments.

[0035] Fig.17 Illustrated is a checkpoint record of incremental generation and application processing according to certain embodiments.

[0036] Fig.18 is an example checkpoint record in a table format according to some embodiments.

[0037] Fig.19A is a flow diagram illustrating incremental generation restart processing utilizing checkpoints according to certain embodiments.

[0038] Fig.19B is a flow diagram illustrating a synchronization mechanism for checkpoint status updates among all key ranges according to certain embodiments.

[0039] Fig. 20 is an example checkpoint manifest file according to some embodiments.

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

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

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

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

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

[0045] In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. However, it is apparent that various embodiments can be practiced without these specific details. The drawings and descriptions are not intended to be limiting.

[0046] The present disclosure relates generally to file systems. More specifically, but not limited to, techniques are described for checkpointing multiple key ranges in parallel and concurrently during file storage replication between file systems in different cloud infrastructure regions. There are several challenges when the system crashes during the replication process. One challenge is how to continue from the last point and complete it without repeating the entire process. The second challenge is potential data corruption because the failed thread may suddenly wake up unexpectedly and conflict with another thread that has taken over the failed thread. The third challenge is how to keep the checkpoint information somewhere accessible after the crash without having recovery performance issues.

[0047] The technology disclosed in the present disclosure creates an efficient recovery scheme by dividing the B-tree into multiple key ranges, each with its own checkpoint. As a result, all of these key ranges can be restarted and recovered from their respective most recent checkpoints in parallel and concurrently. Therefore, the recovery performance is much better than having only one checkpoint for a larger key range. In addition, a range thread is assigned to process a key range, and all range threads operate independently. Each key range can have a checkpoint record to track the information that has been processed. The checkpoint record can have a range-level lock for updating the record by one or more range threads processing the key range. In addition, all range threads can update a central master checkpoint record about their respective status to achieve synchronization between threads. The central master checkpoint record can have a replication job-level lock for updating the master record by all range threads.

[0048] Furthermore, in some embodiments, when a failure event occurs, these techniques use generation numbers (GenNum) to distinguish different generations of processed deltas during delta generation (in the source file system) or delta application (in the target file system) processing. Generation numbers can prevent potential data corruption or conflict issues that may cause data inconsistency during replication caused by thread failures when both an unreliable failure thread and a replacement thread (i.e., a thread that takes over the failure thread) update the same record because they process the same key range.

[0049] Finally, in some embodiments, the proposed solution condenses the information used for recovery into a concise format, such as a manifest file, so that each checkpoint is transferred from the source file system (FS) to the target file system. Therefore, the concise information can be stored in a small memory footprint to improve recovery performance.

[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. Replicators may be formed into a queue (i.e., multiple VMs or replicator threads), referred to as a replicator queue, to perform cross-region (or X-region) replication processing (e.g., uploading deltas to a target region) in parallel.

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

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

[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 1As shown in , primary site A 102 encounters an unplanned incident at time 110, which triggers a failover replication process by copying the latest snapshot and its deltas to secondary site B 104. The initially copied information arrives at secondary site B 104 at time 112. Primary site A 102 completes its copying of information to secondary site B 104 at time 114, and secondary site B 104 completes its replication process at time 116. Therefore, secondary site B 104 becomes fully operational at time 116. Therefore, from point 110 until point 116 when the data is available again, the user's data is inaccessible in primary site A 110. Therefore, the RPO is the time between point 110 and point 116. For example, if there is 10 minutes of data that the user does not care about, then the RPO is 10 minutes. If the data is lost for more than 10 minutes, then the RPO is not met. Zero RPO means synchronous replication.

[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 is more than one file system in the region, the same replication architecture applies to each pair of source and target file systems. In some embodiments, multiple cross-region replications can be performed concurrently between each pair of source and target file systems by utilizing parallel processing threads. In some embodiments, a source file system can be replicated to different target file systems located in the same target region. In addition, file systems in a region can share resources. For example, depending on the implementation, certain resources in KMS250, object repository 260, and the data plane can be shared by many file systems in the same region.

[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 2 The control plane is not shown in the figure. As used herein, a "cycle" may refer to the duration starting when the source file system 280 begins transferring data 230a to the target file system 282 and ending when the target file system 282 receives all of the data 230b and completes its application of the received data. The data 230a-b is captured on the source side and then applied to the target side. Once all changes for a cycle are applied on the target side, the source file system 280 takes another snapshot and starts another cycle.

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

[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 replicator 412 (or uploader) as a component 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 that the upload is complete.

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

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

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

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

[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 in the middle of replication, another replicator thread can take over and continue to complete the job originally owned by the failed replicator thread from the last successful point. If a stray replicator thread (eg, crashes and wakes up again) conflicts with another replicator thread, the FSS can use a mechanism called generation numbering to avoid the conflict by having the two replicator threads update different records.

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

[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 complete, the data can be written to the blob format ( Figure 8 ), and then upload to the object repository using the format or path name ( Fig. 9 (see figure in the figure).

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

[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. 9 The bucket in contains two objects 910 and 930. The first object 910 has two deltas 912 and 920. It starts with a path name 911 prefixed with the source file system ID (e.g., ocid1.filesystem.oc1.iad....), the first delta 912 is generated from snapshot 1 and snapshot 2, and the second snapshot 920 is generated from snapshot 2 and snapshot 3. Each delta has one or more blobs representing the content of the delta. For the first delta 912, it has two blobs 914 and 916 stored in the order in which they were generated. For the second delta 920, it has only one blob 922. Each delta also has a manifest describing the content of the information in the layout of the delta, for example, manifest 918 for the first delta 912 and manifest 924 for the second delta 920. The manifest in the bucket is the content that describes the delta (e.g., file system number and snapshot range, etc.). The manifest can be a master manifest, a range manifest, or a checkpoint manifest, depending on the stage of the replication process.

[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.10In the example, the target file system can start the replication download process (i.e., Ready_to_Reconcile state 1050) only after it receives the following indications: at least one object has been uploaded to the object storage device by the source file system (i.e., Mainfest_Copied state 1014) and the session key is ready for its download (i.e., Copied_DTK state 1034).

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

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

[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 start accurately from the last point in time based on the checkpoint mechanism. Checkpoints help the system know where the last point of progress was, allowing it to continue from that point without having to re-execute the entire job.

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

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

[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 begins 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] Replication checkpointing and data consistency for disaster recovery

[0190] As discussed above, incremental generation is a time-consuming task, especially for large file systems. When the B-tree keys of the source file system are partitioned into many key ranges of approximately equal size, each key range can be processed by a range thread of the incremental generator of the data plane. Each range thread that processes the key range can maintain an active checkpoint record and one or more generation records to track B-tree visits and blob upload processing. Both the checkpoint record and the generation record for incremental generation can be stored in the source shared database (SDB). A checkpoint can refer to and represent the state of the processed increments of both the source file system and the target file system at a given point in time, and the incremental generation in the source FS or the incremental application in the target FS should succeed from this point on. Both the source FS and the target FS can perform checkpoint operations, which means that both file systems are able to create a checkpoint after processing a predetermined amount of increments (e.g., B-tree key-value pairs or converted blobs) or a predetermined time period (e.g., a few minutes), whichever is reached first, because the progress and rhythm of each range thread that processes the key range may be different. For simplicity, the present disclosure can use a predetermined amount of increments. The generation record may contain generation numbers, where each generation number (GenNum) is associated with a set of blobs processed and uploaded by a range thread. In other words, the generation number may refer to or indicate how many generations an incremental build or apply job has gone through in terms of the number of restarts or crashes or thread ownership changes during the replicated incremental build and apply processing. The generation number (GenNum) may be stored in a central location (e.g., a source SDB or a central master checkpoint record) that all range threads can access and use the same GenNum for their respective generation records. Once the incremental build for a key range is completed, the memory space storing the checkpoint record and one or more generation records may be released.

[0191] Fig.13 is a simplified example diagram illustrating key range processing for incremental generation during cross-region replication according to some embodiments. Fig.13 In FIG. 1 , the B-tree keys (i.e., the key portion of a key-value pair) of the source file system (FS) 1302 in the source region may have been partitioned into three key ranges: key range 1 (1310), key range 2 (1312), and key range 3 (1314). In some embodiments, each key range may contain 1000 keys, for example, key range 1 has key numbers K1 to K1000. The keys may be converted into blobs to be uploaded to the object repository as objects. As described above with respect to Figure 8As discussed, a blob may contain multiple B-tree key-value pairs (which may be referred to as keys in a key range). Some B-tree keys may have associated file data and may take up more space in their corresponding blob. Since each blob size may be fixed, each converted blob may contain a different number of key-value pairs (or keys). As a result, even if each key range has approximately the same number of keys, the same number of keys for different key ranges may also be converted into different numbers of blobs. For example, a key range with 1000 keys may be converted into 100 blobs for uploading. Another key range with 1000 keys may be converted into only 50 blobs for uploading because some keys in the key range may have a larger associated data size. Yet another key range with 1000 keys may be converted into 200 blobs for uploading because most of the keys in the key range have almost no associated data. In some embodiments, the key numbers are connected after being partitioned into many key ranges. However, the blob sequence number for each key range may start from B1 and continue until all keys in that key range are processed, because the range threads working on different key ranges operate independently and convert keys into blobs for upload at their own pace. Each blob may have a field called key_value count (kv_count) to indicate the number of B-tree keys it holds to help the target FS calculate the number of keys that the target FS has downloaded and the relationship between the downloaded blobs and the keys.

[0192] To keep it simple, Fig.13Assume that a blob contains 10 keys. Therefore, there are 100 blobs for each key range, for example, B1-B100 for key range 1, B1-B100 for key range 2, and B1-B100 for key range 3. The key numbers are contiguous for K1-K1000 for key range 1, K1001-2000 for key range 2, and K2001-3000 for key range 3. Each key range is processed by a range thread of the incremental generator, and all range threads (T1-T3) process the key range concurrently, in parallel, and independently. If a thread fails (e.g., thread T2 1322), then a new range thread (e.g., T4) can take over. Range threads work independently because they may not communicate with each other when processing their respective key ranges. Range threads work concurrently and in parallel because each range thread can process the keys in its corresponding key range at the same time without waiting for other range threads because the keys in different key ranges are different. Therefore, each range thread can process at its own pace for its corresponding key range. In addition, each blob can include a fixed number of keys. As a result, the source FS can know the equivalent number of keys processed. In addition, all key ranges start with a generation number (GenNum) G1. Whenever the source FS encounters a failure event, GenNum is increased by one. Fig.13 In , due to two failure events (system crash 1320 and thread failure 1322), all key ranges have three GenNums (G1, G2, and G3).

[0193] In some embodiments, each range thread also maintains one or more generation records and checkpoint records (or referred to as range checkpoint records to distinguish from the central master checkpoint record) created at the beginning of the incremental generation process. When a failure event (system crash or thread failure) occurs, a new generation record can be created, and its new GenNum is increased by 1 compared to the previous GenNum. Therefore, one generation record corresponds to one GenNum. For example, since two failure events occurred, namely, a system crash and a thread failure in another key range, range thread T1 has checkpoint record 1 (1350) and three generation records (1353a, 1352b, and 1352c) for key range 1.

[0194] refer to Fig.13, range thread T2 has checkpoint record 2 (1360) and three generation records (1362a-c) for key range 2. Due to the system failure, two of the generation records (1362a-b) are for T2, and due to the failure of thread T2, one of them (1362c) is for T4. Due to the two failure events, range thread T3 has checkpoint record 3 (1370) and three generation records (1372a-c) for key range 3. In each key range, there are four checkpoints (C1, C2, C3, and C4), each covering 25 blobs. For example, when range thread T1 for key range 1 has processed 25 blobs (i.e., up to blob number B25), checkpoint record 1 is created at point C1. When range thread T1 has processed another 25 blobs to reach B50, checkpoint record 1 is updated at point C2, and so on. Since each range thread processes at its own pace and is independent of each other, the checkpoint time for each key range may be different, but the number of blobs processed for each checkpoint is the same; for example, 25 blobs at C1 for key range 1, 25 blobs at C1 for key range 2, and 25 blobs at C1 for key range 3. In some embodiments, a checkpoint may be created after a predetermined period of time, rather than after a predetermined number of processed blobs.

[0195] In some embodiments, the generation record of each range thread is updated (i.e., the generation number GenNum is increased by one) whenever a system crash 1320 (or an event that affects all key ranges) occurs (e.g., between checkpoints C1 and C2) or a thread failure 1322 (e.g., only for key range 2, between checkpoints C2 and C3). In both cases, incremental generation processing can be restarted from the most recent checkpoint in all key ranges by all range threads in parallel and concurrently. A system failure affects the entire system and therefore all key ranges. Therefore, all key ranges are marked with a system failure (i.e., an "X"). However, a thread failure may occur only for range threads that process a particular key range. Fig.13 In FIG. 1 , range thread T2 fails (i.e., 1322) in range 2 between checkpoints C2 and C3 (i.e., marked as solid black dots), but no thread failures occur in other key ranges (i.e., marked as white dots). As a result, a new range thread T4 (also referred to herein as a replacement range thread) takes over, which in turn creates a new generation record (1362c) with GenNum G3. Fig.13As shown in , when a system failure 1320 occurs, the generation number (GenNum) of all generation records changes from G1 to G2, and when a thread failure 1322 occurs, the generation number (GenNum) of all generation records changes from G2 to G3, because all key ranges perform the same incremental generation process. In other words, all range threads maintain the same generation number.

[0196] In some embodiments, a failed range thread may occasionally wake up unexpectedly after a certain time and start processing its key range again. Since the new replacement range thread is also processing the same key range, both the failed range thread and the replacement range thread are updating the same records and generating blobs to be uploaded to the object repository. This situation may cause data corruption. Therefore, a new generation record (e.g., 1362c) is created for the replacement range thread T4. The generation number (GenNum) in the generation record 1362c of thread T4 should start at G3 (i.e., increment from G2 to G3). However, the GenNum in the generation record 1362b of the old thread T2 is still G2 because it is unaware of its own failure. As a result, overlapping blob numbers processed and uploaded by both the failed range thread T2 and the new replacement range thread T4 may be associated with different GenNums, which enables the target FS to distinguish between the blobs processed by threads T2 and T4.

[0197] After the checkpoint is created, the information in the checkpoint record and the generation record for each key range can be merged and copied into a checkpoint manifest file that is uploaded to the object store. The checkpoint manifest file contains the generation number of the checkpoint for the key range and its associated blob group. The target file system can download this checkpoint manifest file, which uses the information to download the blobs from the object store and apply the key values ​​and file data to its B-tree. The checkpoint manifest file is described in more detail later. In some embodiments, the blob for each key range can be uploaded to the object store path for that particular key range, such as / REPL-<JOB ID> / .... / RANGE-<RANGE ID> / BLOB-<BLOB SEQNO> - <gennum>. replication-job_id indicates a specific replication between the source and target file systems. The range-id indicates a specific key range for blob uploads. The uploaded blobs are placed in a specific path with their associated GenNum under the starting blob sequence number (seqno).

[0198] Although Fig.13 The delta generation in the source file system is illustrated, but it can be applied to the delta application in the target file system because similar key range processing is performed in the target FS. In some embodiments, the target FS can also have many key ranges, where one range thread processes the key range to perform the download of blobs and manifest files from the object repository. Each range thread also maintains the checkpoint record and generation record stored in the target shared database (target SDB) during the delta application process to prevent any system crash or thread failure.

[0199] End-to-end process flow

[0200] Fig.14 is a flow chart illustrating the end-to-end process flow of delta generation and delta application during cross-region replication according to certain embodiments. Fig.14 In step 1410, after receiving the replication request, the source FS partitions the B-tree key into multiple key ranges of approximately equal size, and assigns a range thread to each key range to perform incremental generation concurrently and in parallel. At step 1412, the source FS creates a range list file containing information (including at least the total number of key ranges) and transmits it to the target FS via the object repository to inform the target FS of the total number of key ranges processed by the source FS so that the target FS can make corresponding preparations. At step 1420, each range thread working on the key range in the source FS creates and updates a checkpoint record and one or more generation records during the incremental generation process. These checkpoint records and generation records can be stored in the source SDB. During the incremental generation process, if a failure event occurs, each range thread can restart the incremental generation process of the key range it is responsible for based on the information in the checkpoint record. In addition, the generation record of each key range can also be updated to address potential data corruption caused by the failure event. The details of the update of these records will be discussed in more detail later.

[0201] At step 1422, after each checkpoint in a key range, the range threads working on the key range can copy and merge the information in its checkpoint record and generation record into the checkpoint manifest file. At step 1424, each range thread uploads the checkpoint manifest file to the object repository for download by the target FS. At step 1426, the target FS can download the checkpoint manifest file for each key range, create a key range that mirrors the key range in the source FS, download blobs based on the information in the checkpoint manifest file, and then clean up the manifest file. When the target FS detects the final checkpoint manifest file and the end of file (eof) field of the key range is set to true, it knows that the blob group it will download is for the last checkpoint stage of the key range. At step 1428, each range thread in the target FS can also create and update checkpoint records and one or more generation records during the incremental apply process. These checkpoint records and generation records can be stored in the target SDB. At step 1430, the process repeats steps 1420-1428 until all range threads complete the delta generation for their responsible key range in the source FS and the delta application for their key range in the target FS.

[0202] Data consistency for disaster recovery

[0203] As mentioned above Fig.13 As discussed, the generation number (GenNum) can be used to resolve potential data corruption between two range threads processing the same key range. In some embodiments, each time the replicator obtains a replication job, the range threads processing different key ranges are assigned a GenNum, which is also recorded in the source shared database (SDB). When a new range thread starts, whether for a brand new job or a takeover job, a generation record is created. The new range thread can check the source SDB to obtain the current generation number and then increase the number by one. Therefore, no two range threads can write to the same generation record. For example, in Fig.13 , when incremental build processing begins, all generation records of range threads (e.g., T1, T2, and T3) are assigned generation number G1. When range thread T2, processing key range 2, fails, for example, due to timing out (i.e., lease expiration) without updating its heartbeat status, a new replacement range thread T4 can take over and continue incremental build processing (or restart from the next key after the most recent checkpoint made by thread T2). The new replacement thread T4 can examine the source SDB and find that the generation number of thread T2 is G2. Therefore, the new replacement thread T4 can set its generation number to G3. As a result, thread T2 and thread T4, although processing the same key range 2, can update different records (e.g., generation record 1362b and generation record 1362c), and the blobs they process are associated with different generation numbers (G2 and G3). In some embodiments, the blobs processed and uploaded by thread T2 and thread T4 can be placed in different buffers assigned to different generation numbers. When the target file system downloads blobs uploaded by both thread T2 and thread T4, the target file system may discard overlapping blob numbers associated with the lower generation number G2 and use overlapping blob numbers associated with the higher generation number G3.

[0204] Fig.15 Illustrated is a generation record of incremental generation and application processing according to some embodiments. Fig.15 In the example, generation record 1500 may include key-value pairs, one key-value pair for each generation record in a key range. The key-value pairs may be stored in a table format (e.g., a table stored in memory inside the source SDB). In some embodiments, the fields in key 1510 may include, but are not limited to, replication type, replication ID, range ID, and generation number (GenNum). The replication type may indicate whether the generation record is for the source file system or the target file system, because both file systems have their respective generation records in the same format. For the source file system, the generation record may be used to track the blob groups that have been uploaded to the object repository. For the target file system, the generation record may be used to track the blob groups that have been downloaded from the object repository. The replication ID may be a source file system ID or a target file system ID for identifying the file system that performs cross-region replication. The range ID indicates the key range associated with the generation record. The generation number is the generation of a group of blobs processed and uploaded by the range thread that owns the generation record (i.e., the number of restarts or system failures or thread ownership changes). For example, after the incremental generation job starts, the blobs processed and uploaded belong to the first generation (i.e., GenNum=1). After the system crashes and restarts, the blobs processed and uploaded belong to the second generation (ie, GenNum=2), and so on.

[0205] exist Fig.15 In some embodiments, the fields in value 1520 may include, but are not limited to, start_blob_seqno and end_blob_seqno. These fields represent the starting blob sequence number and the ending blob sequence number that define a set of blobs associated with the generation number in the key. For example, in table 1530 for thread T1, processing blobs in key range 1 (1310) may have three key-value pairs to represent the three generations of blobs processed by thread T1, such as Fig.13 For simplicity and illustration purposes, not all fields are listed in the table. The first key-value pair in the first generation record (i.e., Fig.13 1352a in or the first entry of table 1530) contains a key whose range_id R1 and GenNum G1 are associated with a set of blobs from sequence number (seqno or blob number) 1 (or B1) to 35 (or B35). When thread T1 completes blob number 35, the system crashes. Therefore, thread T1 creates a second generation record in which GenNum is increased by one to G2. Thread T1 can resume from the previous checkpoint at B25 ( Fig.13 The next key after B26 (shown in FIG. 1 ) restarts the incremental generation process for key range 1. Since the blobs from B25 to B35 have been processed and uploaded to the object repository, GenNum G2 only records blobs from B36 onwards.

[0206] The second key-value pair (i.e., Fig.13 The second generation record 1352b in or the second entry of table 1530 contains a key having GenNum G2 associated with a set of blobs from blob number 36 to blob number 70, which is in key range 2 ( Fig.13 1312 in ( ) when the thread failure occurs. Although the thread failure did not occur in key range 1, the GenNum in all generation records is updated. Therefore, thread T1 creates a third generation record in which GenNum is increased by one again to G3. Thread T1 can start from the previous checkpoint at B50 ( Fig.13 ) restarts the incremental generation process for key range 1 until it completes all 100 blobs. Therefore, the third key-value pair (i.e., Fig.13 The second generation record 1352c) in has GenNum G3 and a value representing a set of blobs from blob numbers 71 to 100.

[0207] To further illustrate, key range 2 ( Fig.13 1312) A system crash occurred at B35 and a thread failure occurred at B70. Fig.15 There are two tables in the table 1532. Table 1532 has two key-value pair entries, indicating Fig.13 Table 1534 has a key-value pair entry, indicating Fig.13 A generation of blobs processed by thread T4. Return reference Fig.13 , key range 2 crashes at B35, and thread failure of T2 occurs at B70. Therefore, thread T2's first generation record (1362a) has a first key-value pair, where range ID R2 and GenNumG1 are associated with a set of blobs from B1 to B35. Then, thread T2 creates a second generation record ( Fig.13 1362b in or the second entry in table 1532), increments GenNum by one to G2, and restarts the incremental generation process for key range 2 from the next key after the previous checkpoint B25 until it fails at B70. When thread T2 fails, a new replacement thread T4 takes over and creates a new generation record stored in table 1534. Thread T4 checks the source SDB and finds that the current GenNum for key range 2 is G2. Therefore, thread T4 creates a third generation record ( Fig.13 1362c in or the first entry of table 1534), increment GenNum by one to G3, and proceed from the failure point B70 of thread T2 to complete all blobs (until B100) of key range 2. Thus, table 1534 for thread T4 has GenNum G3 associated with blobs B71 to B100.

[0208] However, a failed thread may wake up unexpectedly and continue processing blobs. For example, thread T2 that failed at B70 may wake up and continue processing blobs from B70 until it fails again at B85. As a result, the second key-value pair (or second generation record) in table 1532 of thread T2 has a GenNum G2 associated with blobs from B36 to B85 because it processed additional blobs (B71-B85) after waking up unexpectedly after the failure. Since threads T2 and T4, both working on the same key range 2 (range ID R2), have different generation records (i.e., tables 1532 and 1534) with different GenNums, this prevents data corruption on blobs B71-B85 that were processed overlappingly when thread T2 woke up unexpectedly. When the information in the generation record of the key range is transmitted to the target FS via the object storage, the target FS can see a set of overlapping blobs (B71-B85) between the key-value pair owned by thread T2 (GenNum=G2, blobs B36-B85) and another key-value pair owned by thread T4 (GenNum=G3, blobs B71-B100). Since the overlapping blobs (B71-B85) associated with a higher GenNum are recovered blobs, the target FS can download and apply blobs B1-B35 associated with GenNum G1, blobs B36-B70 associated with GenNum G2, and blobs B71-B100 associated with GenNum G3.

[0209] Fig.16 is a flow diagram illustrating key range processing of generation records involving incremental generation and application during cross-region replication in accordance with certain embodiments. Fig.16 Can be expanded and illustrated about Fig.14 . At step 1610, each range thread working on the key range creates a generation record by assigning a generation number (GenNum) to a set of blobs with a starting sequence number and an ending sequence number. The range thread processes the set of blobs by identifying deltas (e.g., key-value pairs) from the B-tree of the source FS, converting the deltas to blob format, and uploading the blobs to the object store. When a failure event occurs, the range thread may need to identify whether the failure event is a system crash or a thread failure. At step 1612, if the failure event is a system crash (e.g., Fig.13 1320 in ), then at step 1614, the current scope thread can create a new generation record and set the GenNum (e.g., Fig.15 1510 in step 1616) is increased by one (i.e., a new generation number is created). At step 1616, the current thread can check its corresponding checkpoint record and restart the incremental generation process from the next key to be processed after the previous checkpoint. The incremental generation restart process can be described in more detail later.

[0210] At step 1620, if the fault event is a thread fault (e.g., Fig.13 1322 in ), then at step 1622, the new alternative scope thread (e.g., Fig.13 Thread T4 in can take over the failed thread (for example, Fig.13 Thread T2 in the process), creates a new generation record (for example, Fig.15 1534 in Table 1534), and increase GenNum by one (e.g., from G2 to G3, as Fig.13 and Fig.15 ). At step 1624, the replacement range thread may check the checkpoint record for key range 2 (range id R2) and restart the incremental generation process from the next key to be processed after the previous checkpoint. After the incremental generation process is restarted in response to the system crash or thread failure, the process may proceed to step 1630. At step 1630, after processing a predetermined number of blobs (or a predetermined time period) that meet the checkpoint requirements, the active thread (e.g., T1 or T4) may copy the information in the generation record to the checkpoint manifest file for upload to the object store.

[0211] Replication Checkpoint Operation

[0212] Fig.17 Illustrated is a checkpoint record of incremental generation and application processing according to some embodiments. Fig.17 In the embodiment of the present invention, the generation record 1700 may include key-value pairs, one key-value pair for each checkpoint in the key range. The key-value pairs may be stored in a table format. In some embodiments, the fields in key 1710 may include, but are not limited to, replication type, replication ID, and range_ID. The replication type may indicate whether the checkpoint record is for the source file system or the target file system, as both file systems have their respective generation records in the same format. The replication ID may be a source file system ID or a target file system ID, used to identify the file system performing cross-region replication. The range ID may be a key range identifier for the checkpoint record.

[0213] In some embodiments, the fields in value 1720 may include, but are not limited to, the following three categories of information: 1) data that has been processed, 2) the location of the processed keys, and 3) a generation number used to cross-reference between the generation record and the checkpoint record. The first category, information about the data that has been processed, may include, but is not limited to, the number of objects or blobs uploaded as part of the checkpoint (i.e., num_objects), the number of keys that the source file system has uploaded (i.e., num_keys_uploaded) or the number of keys that the target file system has applied (i.e., num_keys_applied), the total cumulative delta size (in bytes) that the source file system has uploaded so far for this replication (i.e., total_delta_size_uploaded) or the total cumulative delta size (in bytes) that the target system has applied (i.e., total_delta_size_applied). For example, each blob may have 100 bytes. Therefore, uploading 10 blobs may have a delta size of 1000 bytes. total_delta_size_uploaded is measured from the beginning of the entire key range. Since the delta generator partitions the B-tree key into multiple key ranges, the delta generator has information about the number of keys and blobs for each key range. This information can be used to calculate the cumulative delta size when the thread creates the checkpoint record. The second category, the position of the key processed, can be the next key to start after the checkpoint (next_delta_key) and the last key to be copied by the source file system (last_delta_key). Finally, the generation number can help cross-reference between the generation record and the checkpoint record, as the checkpoint number and the generation number (depending on the location of the failure event) may be different.

[0214] In some embodiments, each range thread can checkpoint a predetermined number of processed blobs. Each range thread may have a different progress, so the range threads can update their respective checkpoint records at different times after completing a predetermined number of processed blobs. In some embodiments, a blob may contain a fixed number of keys. In other embodiments, the number of keys in a blob may vary depending on the implementation. The number of keys (num_keys_uploaded) and the number of blobs (total_delta_size_uploaded) uploaded by the source file system to the object repository can inform the target file system how many blobs to download for incremental application and the progress of the entire replication process. When the system crashes or the thread fails to allow the working range thread to know where to restart the incremental generation process in the source file system or the incremental application process in the target file system, the next key (next_delta_key) to start after the checkpoint can be used. As an example of checkpoint usage, after creating a checkpoint, the range thread can continue to process the B-tree keys of the key range and upload the converted blobs to the object repository. At some point, a system crash occurs. The range thread may need to restart the incremental generation process after the system is restored. Each scope thread does not need to return from the beginning of the file system, but only needs to return to the previous checkpoint immediately before the crash point, and continue from there.

[0215] Fig.18 is an example checkpoint record in a table format according to some embodiments. For simplicity and illustration purposes, not all fields are listed in the table. Fig.18 Table 1810 for thread T1 in FIG. 1 has four key-value pairs for four checkpoints (C1, C2, C3, and C4), one for each checkpoint, such as C1 at B25, C2 at B50, C3 at B75, and C4 at B100, as shown in FIG. Fig.13 As shown in . For the first key-value pair, the key range ID (range_ID) is R1. The number of objects or blobs at this checkpoint is 25. Assuming that each blob has 100 bytes, the total number of delta bytes uploaded by the source file system (total_delta_size_uploaded) is also 2500. Assuming that there are 10 keys in each blob, the total number of keys processed until this checkpoint is 250. Therefore, the next key (next_delta_key) to start after this checkpoint is 251. The generation number (GenNum) cross-referenced to the generation record of thread T1 is G1, as shown in Fig.13 Afterwards, when the system crashes, thread T1 can continue processing B-tree keys until blob B35, as shown in Fig.13 As shown in . After the system recovers, thread T1 knows by checking the checkpoint record that blobs B1-B25 have been successfully processed and uploaded to the object store. Therefore, thread T1 may only need to restart processing keys from key number K251 after checkpoint C1 (i.e., next_delta_key or the first key in blob B26). When thread T1 processes another 25 blobs, it can create another checkpoint C2. Therefore, the value portion of the key-value pair of checkpoint C2 may have the following: the number of objects (num_objects) is 25, the total number of blobs uploaded for key range 2 (total_delta_size_uploaded) is 5000, the next key to start (next_delta_key) is 501, and GenNum is G2 because the system crash should cause the generation number to increase by one. When thread T1 completes processing all 100 blobs for key range two, similar processing is performed for checkpoints C3 and C4. The next_delta_key field may not be used for checkpoint C4 because thread T1 has completed processing the last key in key range 1. Checkpoint C4 exists because if a failure event occurs after the range thread for the key range has uploaded all blobs but before its checkpoint manifest file is uploaded to the object store, the range thread can use the checkpoint C4 information to continue with the generation and upload of the checkpoint manifest file.

[0216] continue Fig.18 , for key range 2, since the thread failure occurs between checkpoints C2 and C3, as Fig.13 As shown in , thread T2 may have created and updated checkpoint records, such as table 1820 for checkpoint numbers C1 and C2. Thread T4, after taking over thread T2, can continue to update the checkpoint record table 1820 for checkpoint numbers C3 and C4 by obtaining a range-level lock on the checkpoint record (from the replicator or delta generator) to prevent the failed thread T2 from performing any unexpected updates. When thread T4 takes over thread T2, it can restart the delta generation process from next_delta_key K1501 after checkpoint C2 by looking up the summary information in table 1820 stored in the source SDB or in the central master checkpoint record to be discussed later.

[0217] Each checkpoint record for a key range may have a range-level lock for the range thread of that key range to update the checkpoint record. For example, if a thread failure occurs, multiple range threads may process the key range. The new replacement thread that updates the checkpoint record (i.e., the thread that takes over the failure) may obtain the range-level lock so that the failed thread cannot update the same record.

[0218] Incremental build restart and checkpoint status updates

[0219] While all range threads perform incremental generation of their key ranges concurrently, in parallel, and independently, they need to update the progress byte located in the central master checkpoint record, allowing the source file system to coordinate or synchronize all range threads. The central master checkpoint can be managed by the replicator of the data plane. The master checkpoint record with range_ID set to 0 can contain a summary of the source FS processing information, such as the generation number, the number of checkpoint records that the target FS can expect, the total B-tree key count, and the processed B-tree keys. This information may be helpful in reporting replication progress to the client. After completing the checkpoint, each range thread can take turns to obtain a lock (e.g., a mutex replication job-level lock) to update the progress byte of the central checkpoint record to synchronize all range threads. After the range thread completes its update, it can release the lock to allow another range thread to update the progress byte. In addition, the master checkpoint record may need to periodically write the progress byte to the source shared database (SDB) so that the control plane of the source file system can track the status of the incremental generation progress. Therefore, all range threads may be blocked from accessing the progress byte periodically (e.g., for a few minutes) so that the master checkpoint record performs such updates to the SDB. This process can be described in Figure 19 below.

[0220] Fig.19A is a flow diagram illustrating incremental generation restart processing utilizing checkpoints according to certain embodiments. Fig.19B is a flow diagram illustrating a synchronization mechanism for checkpoint status updates among all key ranges according to certain embodiments. Fig.19A and Fig.19B The flow charts are all Fig.14 Expand on step 1420 regarding checkpoint updates.

[0221] refer to Fig.19A The incremental generation of restarts the processing, in some embodiments, at step 1910, after satisfying the checkpoint requirements (such as a predetermined requirement for processing binary tree (B-tree) key-value pairs), each range thread of the source file system creates a checkpoint and updates the checkpoint record of the key range it is responsible for. The predetermined requirement can be to process a predetermined number of keys (i.e., B-tree key values ​​representing the increment) or converted blobs in the source FS, or a predetermined time period (e.g., a few minutes), whichever occurs first. At step 1912, each range thread continues to process B-tree keys and create blobs to upload to the object repository.

[0222] At step 1920, when a fault event is encountered, the process checks whether it is a system crash or a thread fault. If the fault event is a thread fault (e.g., Fig.13 ), then processing proceeds to step 1922 for additional steps, where the new thread may take over the failed thread by obtaining ownership of the checkpoint record before resuming delta generation processing. In addition, as mentioned with respect to generation records, the new thread also creates a new generation record in which GenNum is incremented by one. Otherwise (i.e., a non-thread failure event), processing proceeds to step 1924, where all active scope threads (including the new thread) restart in parallel and concurrently from the next delta key (i.e., B-tree key) after their respective most recent checkpoint by examining and using the next_delta_key field in the checkpoint record. For example, when the failure event occurs between checkpoints C1 and C2, all scope threads may restart from the next_delta_key of checkpoint C1 in their respective checkpoint tables. Assuming the failure event is a system crash ( Fig.13 1320); then thread T1 can check table 1810 (reference Fig.18 ) restarts at key number 251. If the failure event is a thread failure ( Fig.13 1322), such as thread T2, then thread T4 can be at B170 ( Fig.13 After taking over thread T2 and obtaining ownership of the checkpoint record, by checking table 1820 (reference Fig.18 ) restarts at key number K1501. At step 1926, processing may repeat steps 1910-1924 until all keys in each key range have been processed by the range thread for which it is responsible.

[0223] refer to Fig.19B In some embodiments, at step 1930, as discussed above, after receiving a cross-region replication request between a source FS and a target FS in different regions, the source FS may partition the B-tree key into multiple key ranges and assign range threads to the key ranges to perform incremental generation, one range thread for each key range. At step 1940, after satisfying the checkpoint requirements (such as a predetermined requirement for the number of processed blobs or duration of processing binary tree (B-tree) key-value pairs), each range thread of the source file system creates a checkpoint and updates the checkpoint record of the key range it is responsible for. At step 1942, for the range thread that first creates a checkpoint among all range threads (referred to as the cp-first thread), after creating the checkpoint, the cp-first thread may request a lock from the central master checkpoint record to update the central record, such as a progress byte. At step 1943, the cp-first thread may obtain a lock (or be granted a lock) from the lock manager of the central master checkpoint record to update the progress byte, and all other range threads may wait until the cp-first thread completes the update and releases the lock. The locking mechanism is to ensure that only one scope thread can update the progress byte at a time (or to prevent other threads from updating at the same time). At step 1944, all other scope threads that have completed creating their respective checkpoints can take turns to obtain the lock and update the central record (e.g., the status byte). For example, a first scope thread (e.g., a cp-first thread) can create a checkpoint for a first key range before a second scope thread creates a checkpoint for a second key range. Therefore, the first scope thread can request a lock from the central master checkpoint record earlier than the second scope thread's request for the same lock. As a result, the first scope thread may be granted a lock to update the central record, and the second scope thread may need to wait for the first scope thread to release the lock.

[0224] In some embodiments, if two or more threads request a lock at the same time, a conflict resolution strategy can be used to resolve the conflict. The conflict resolution strategy may include, but is not limited to, a round robin mechanism, thread priority, first-come-first-served, etc. For example, a round robin mechanism may be used to select a requesting thread based on the thread IDs of the requesting threads, such as selecting a lower thread ID associated with a thread that starts incremental build processing earlier. The priority of a thread may select a scope thread designated as a higher priority (if applicable). Requests may be queued and serviced to obtain locks. In some embodiments, while threads are waiting for update progress bytes, they may still continue to process the keys in the key range for which they are responsible.

[0225] At step 1946, after updating the central master checkpoint record, the cp-first thread continues the incremental generation process for the next checkpoint phase for the key range it is responsible for while other threads are updating the central master checkpoint record. Since each thread proceeds at its own pace, the cp-first thread that obtains the lock at the next checkpoint phase may be a different thread. For example, in Fig.13 , assuming that thread T1 first reaches checkpoint C1 in key range 1 (1310) (i.e., the cp-first thread) and obtains the lock, then threads T2 and T3 can wait for the lock to be released. After T1 completes updating the progress byte, it moves to the next checkpoint phase to create checkpoint C2 in key range 1; threads T2 and T3 can take turns obtaining the lock and updating the progress byte. Assume that after updating the progress byte, thread T3 processes faster in the next checkpoint phase and reaches checkpoint C2 in key range 3 (1304) first, becoming the cp-first thread in the checkpoint C2 phase; then thread T3 can obtain the lock, and threads T1 and T2 may need to wait for the lock to be released. At step 1948, processing repeats steps 1940 to 1946 for the remaining checkpoint phases until all range threads complete incremental generation of all key ranges.

[0226] The target file system can also utilize the same restart process when performing incremental apply, such as a new replacement thread taking over ownership of the checkpoint record from the failed thread, and a synchronization mechanism for checkpoint state updates between its scope threads.

[0227] Checkpoint manifest file

[0228] As mentioned above Fig.14 As discussed, the checkpoint records and generation records for each key range can be merged to create a checkpoint manifest file after each checkpoint and uploaded to the object repository as a manifest blob by the responsible range thread. The manifest blob can be uploaded by the range thread after all the incremental blobs of the checkpoint have been uploaded. Once the target FS detects the presence of the checkpoint manifest blob in the object repository, the target FS can first download the checkpoint manifest blob, read and use the information in the checkpoint manifest to download a certain number of incremental blobs uploaded by the source FS, and apply it to the corresponding key range in the target FS. The above process continues until the target FS receives a manifest blob with the end of file (eof) field set to true, thereby signaling the checkpoint phase of the key range. The checkpoint manifest blob is used as communication with concise information between the source file system and the target file system.

[0229] Fig. 20 is an example checkpoint manifest file according to certain embodiments. In some embodiments, fields in the checkpoint manifest file may include, but are not limited to, the number of objects or blobs uploaded as part of the checkpoint (i.e., num_objects), the number of keys that the source file system has uploaded (i.e., num_keys_uploaded) or the number of keys that the target file system has applied (i.e., num_keys_applied), the total cumulative delta size (in blobs) that the source file system has uploaded so far for this replication (i.e., total_delta_size_uploaded) or the total cumulative delta size (in blobs) that the target file system has applied (i.e., total_delta_size_applied). The source replication ID (i.e., src_repl_id) and the target replication ID (i.e., tgt_repl_id) are used to identify a specific replication job between the source FS and the target FS. The total cumulative delta size in bytes that the source file system has uploaded so far for this replication (i.e., total_delta_size_uploaded) or the total cumulative delta size in bytes that the target FS has applied so far for this replication (i.e., total_delta_size_applied) can help the target confirm the deltas it has received and applied. The key range used to generate the manifest file (i.e., range_ID) and the total number of range threads working on the key range (i.e., total_sub_tasks) can help the target FS figure out whether there is more than one thread working on the key range, for example, in case of a failed thread. The end of file setting (i.e., eof) can help the target FS track the end of the key range. Finally, the array of the latest generation number (i.e., latest_gennum) and the list of generation numbers (i.e., GenNum) and the corresponding list of blob sequence numbers (i.e., start_blob_seqno and end_blob_seqno) are used to track failure events and avoid potential data corruption during the replication process, as described with Fig.15 Related to what was discussed about generation records, the checkpoint manifest blob has an array of GenNum and blob sequence number groups, since multiple failure events may occur during the checkpoint phase.

[0230] The checkpoint manifest file can help the target FS calculate the blobs available for download, the progress of the copy process, and resolve potential data corruption issues, as described above. Fig.13 The key range 2 where the thread failure occurred (for example, Fig.13 Take the thread T2 at B70 shown in FIG as an example. Fig. 20 , when incremental generation of key range 2 is complete, the key range may have uploaded the following four checkpoint manifest files / blobs to the object repository (see also Fig.13 Key range 2 (1312) and Fig.18 Threads T2 and T4):

[0231] First checkpoint manifest blob for C1 (created by thread T2):

[0232] num_objects=25,

[0233] delta_size_uploaded = 2500, (assuming each blob is 100 bytes)

[0234] total_sub_tasks=1,

[0235] range_id=R2,

[0236] eof=0,

[0237] latest_gennum=G1,

[0238] [G1: start_blob_seqno, end_blob_seqno) = (1, 25)] The second checkpoint list blob for C2 (created by thread T2):

[0239] num_objects=25,

[0240] delta_size_uploaded=5000,

[0241] total_sub_tasks=1,

[0242] range_id=R2,

[0243] eof=0,

[0244] latest_gennum=G2,

[0245] [G1:(start_blob_seqno,end_blob_seqno)=(26,35)]

[0246] [G2: (start_blob_seqno, end_blob_seqno) = (36, 50)] The third checkpoint list blob for C3 (created by thread T4):

[0247] num_objects=25,

[0248] delta_size_uploaded=7500,

[0249] total_sub_tasks=2,

[0250] range_id=R2,

[0251] eof=0,

[0252] latest_gennum=G3,

[0253] [G2:(start_blob_seqno,end_blob_seqno)=(51,70)]

[0254] [G3: (start_blob_seqno, end_blob_seqno) = (71, 75)] The fourth checkpoint manifest blob for C4 (created by thread T4):

[0255] num_objects=25,

[0256] delta_size_uploaded=10000,

[0257] total_sub_tasks=2,

[0258] range_id=R2,

[0259] eof=1,

[0260] latest_gennum=G3,

[0261] [G3:(start_blob_seqno,end_blob_seqno)=(76,100)]

[0262] For example, when the target FS receives the second checkpoint manifest blob for checkpoint C2 for key range 2 (range ID R2), the target FS knows based on the num_objects field that it needs to download 25 blobs from the object store, and based on the delta_size_uploaded field that it should have received a total of 5000 bytes for the key range so far. Based on the total_sub_tasks field, only one range thread is working on the key range, namely T2. Based on the eof field, the 25 blobs that the target FS plans to download are not the last set of blobs for the key range. Finally, since the system crash occurred at B35, this set of blobs belongs to generation number G1 associated with sequence numbers between 26 and 35 and generation number G2 associated with sequence numbers between 36 and 50.

[0263] When the target FS receives the third checkpoint manifest blob for C3, this information can help the target FS discover that a failure event occurred in the source FS during the incremental generation process. Based on the total_sub_tasks, range_id, and GenNum fields, the target FS can know that thread T4 is the replacement thread, which is the second range thread working on this key range because the latest generation number (latest_gennum) has increased from G2 to G3. The 25 blobs that the target FS plans to download belong to GenNum G2 associated with blob sequence numbers between 51 and 70, and GenNumG3 associated with sequence numbers between 71 and 75. If the failed thread T2 is at B70 (ref. Fig.13 ) wakes up unexpectedly and also uploads another checkpoint manifest blob for C3, but fails again, then the target FS can receive the fifth checkpoint manifest blob uploaded by thread T2, but the timing is uncertain:

[0264] Fifth checkpoint manifest blob for C3 (created by thread T2):

[0265] num_objects=25,

[0266] delta_size_uploaded=7500,

[0267] total_sub_tasks=1,

[0268] range_id=R2,

[0269] latest_gennum=G2,

[0270] eof=0,

[0271] [G2:(start_blob_seqno,end_blob_seqno)=(51,75)]

[0272] The third and fifth checkpoint manifest blobs have overlapping blob_seqno (51-70 and 71-75). Since the fifth checkpoint manifest blob has a smaller GenNum G2 for blobs B71-B75 (of failed thread T2), the target FS should discard this set of blobs and use the recovered blobs B71-B75 (of thread T4) associated with GenNum G3, as described above for Fig.15 As discussed. When the new replacement thread T4 takes over the failed thread T2, it can find from the checkpoint record that the checkpoint manifest file has not been generated and uploaded. Thread T4 can generate and upload the converted checkpoint manifest blob and update the checkpoint record, indicating that the manifest file has been uploaded. Although the failed thread T2 can upload the checkpoint manifest blob after it wakes up, it may not be able to update the checkpoint record of the key range 2, and therefore cannot generate any checkpoint manifest files in the future. For example, if thread T2 wakes up before its job lease expires, it cannot update the checkpoint record because the ownership of the checkpoint record has changed after thread T4 took over. If thread T2 wakes up after its job lease expires, it cannot renew to extend the lease because thread T4 has taken over the incremental generation job. The checkpoint record ownership and job lease mechanism can be coordinated between the data plane (e.g., replicator, incremental generator, and range thread), the source SDB, and the control plane.

[0273] When the target FS receives the fourth checkpoint manifest blob, it knows that this is the last set of 25 blobs for the key range because the eof field is set to 1. Once the target FS downloads the manifest blobs and applies the delta blobs for each checkpoint, it can delete the manifest blobs in the object store to make more space for future blob uploads from the source FS. In addition, in some embodiments, in the source FS, once the checkpoint manifest file is created, the checkpoint and one or more generation records can be deleted in the source SDB to improve resource utilization.

[0274] Example cloud architecture

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

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

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

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

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

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

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

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

[0283] Fig.21 2 is a block diagram 2100 illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 2102 can be communicatively coupled to a secure host lease 2104 that can include a virtual cloud network (VCN) 2106 and a secure host subnet 2108. In some examples, the service operator 2102 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 2106 and / or the Internet.

[0284] VCN 2106 may include a local peer gateway (LPG) 2110, which may be communicatively coupled to a secure shell (SSH) VCN 2112 via LPG 2110 contained in SSH VCN 2112. SSH VCN 2112 may include an SSH subnet 2114, and SSH VCN 2112 may be communicatively coupled to control plane VCN 2116 via LPG 2110 contained in control plane VCN 2116. In addition, SSH VCN 2112 may be communicatively coupled to data plane VCN 2118 via LPG 2110. Control plane VCN 2116 and data plane VCN 2118 may be contained in a service lease 2119, which may be owned and / or operated by an IaaS provider.

[0285] The control plane VCN 2116 may include a control plane demilitarized zone (DMZ) layer 2120 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 2120 may include one or more load balancer (LB) subnets 2122, a control plane application layer 2124 that may include (one or more) application subnets 2126, and a control plane data layer 2128 that may include (one or more) database (DB) subnets 2130 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 2122 included in the control plane DMZ layer 2120 may be communicatively coupled to the application subnet(s) 2126 included in the control plane application layer 2124 and the Internet gateway 2134 that may be included in the control plane VCN 2116, and the application subnet(s) 2126 may be communicatively coupled to the DB subnet(s) 2130 included in the control plane data layer 2128 and the service gateway 2136 and the network address translation (NAT) gateway 2138. The control plane VCN 2116 may include the service gateway 2136 and the NAT gateway 2138.

[0286] The control plane VCN 2116 may include a data plane mirror application layer 2140, which may include application subnet(s) 2126. The application subnet(s) 2126 included in the data plane mirror application layer 2140 may include a virtual network interface controller (VNIC) 2142 that may execute a compute instance 2144. The compute instance 2144 may communicatively couple the application subnet(s) 2126 of the data plane mirror application layer 2140 to the application subnet(s) 2126 that may be included in the data plane application layer 2146.

[0287] The data plane VCN 2118 may include a data plane application layer 2146, a data plane DMZ layer 2148, and a data plane data layer 2150. The data plane DMZ layer 2148 may include (one or more) LB subnets 2122, which may be communicatively coupled to (one or more) application subnets 2126 of the data plane application layer 2146 and an internet gateway 2134 of the data plane VCN 2118. The (one or more) application subnets 2126 may be communicatively coupled to a service gateway 2136 of the data plane VCN 2118 and a NAT gateway 2138 of the data plane VCN 2118. The data plane data layer 2150 may also include (one or more) DB subnets 2130, which may be communicatively coupled to (one or more) application subnets 2126 of the data plane application layer 2146.

[0288] The internet gateway 2134 of the control plane VCN 2116 and the data plane VCN 2118 may be communicatively coupled to a metadata management service 2152, which may be communicatively coupled to a public internet 2154. The public internet 2154 may be communicatively coupled to a NAT gateway 2138 of the control plane VCN 2116 and the data plane VCN 2118. The service gateway 2136 of the control plane VCN 2116 and the data plane VCN 2118 may be communicatively coupled to a cloud service 2156.

[0289] In some examples, a service gateway 2136 of a control plane VCN 2116 or a data plane VCN 2118 can make application programming interface (API) calls to cloud services 2156 without going through public internet 2154. API calls from service gateway 2136 to cloud services 2156 can be one-way: service gateway 2136 can make API calls to cloud services 2156, and cloud services 2156 can send requested data to service gateway 2136. However, cloud services 2156 may not initiate API calls to service gateway 2136.

[0290] In some examples, secure host lease 2104 can be directly connected to service lease 2119, which can otherwise be isolated. Secure host subnet 2108 can communicate with SSH subnet 2114 through LPG 2110, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 2108 to SSH subnet 2114 can enable secure host subnet 2108 to access other entities within service lease 2119.

[0291] Control plane VCN 2116 may allow a user of service lease 2119 to set up or otherwise provision desired resources. Desired resources provisioned in control plane VCN 2116 may be deployed or otherwise used in data plane VCN 2118. In some examples, control plane VCN 2116 may be isolated from data plane VCN 2118, and a data plane mirror application layer 2140 of control plane VCN 2116 may communicate with a data plane application layer 2146 of data plane VCN 2118 via a VNIC 2142, which may be included in both the data plane mirror application layer 2140 and the data plane application layer 2146.

[0292] 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 2154, which may transmit the request to the metadata management service 2152. The metadata management service 2152 may transmit the request to the control plane VCN 2116 through the internet gateway 2134. The request may be received by the LB subnet(s) 2122 contained in the control plane DMZ layer 2120. The LB subnet(s) 2122 may determine that the request is valid, and in response to the determination, the LB subnet(s) 2122 may transmit the request to the application subnet(s) 2126 contained in the control plane application layer 2124. If the request is validated and a call to the public internet 2154 is required, the call to the public internet 2154 may be transmitted to the NAT gateway 2138, which may make the call to the public internet 2154. The metadata 2154 that the request may desire to be stored may be stored in the DB subnet(s) 2130.

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

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

[0295] In other embodiments, the LB subnet(s) 2122 contained in the control plane VCN 2116 can be configured to receive signals from the service gateway 2136. In this embodiment, the control plane VCN 2116 and the data plane VCN 2118 can be configured to be called by customers of the IaaS provider without calling the public Internet 2154. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 2119, which may be isolated from the public Internet 2154.

[0296] 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.21 The service operator 2102 may be communicatively coupled to the secure host lease 2204 (e.g., Fig.21 The secure host lease 2104 may include a virtual cloud network (VCN) 2206 (e.g., Fig.21 VCN 2106) and secure host subnet 2208 (e.g., Fig.21 The VCN 2206 may include a local peer gateway (LPG) 2210 (e.g., Fig.21 2110 ), which may be communicatively coupled to a secure shell (SSH) VCN 2212 via an LPG 2110 contained in an SSH VCN 2212 (e.g., Fig.21 SSH VCN 2112). SSH VCN 2212 may include SSH subnet 2214 (e.g., Fig.21 SSH subnet 2114 of the control plane VCN 2214), 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.21 The control plane VCN 2116 may be included in a service lease 2219 (e.g., Fig.21 service lease 2119), and the data plane VCN 2218 (e.g., Fig.21 The data plane VCN 2118) may be contained in a customer lease 2221 which may be owned or operated by a user or customer of the system.

[0297] The control plane VCN 2216 may include a control plane DMZ layer 2220 (e.g., Fig.21 The control plane DMZ layer 2120 may include (one or more) LB subnets 2222 (e.g., Fig.21 (one or more) LB subnets 2122), may include (one or more) application subnets 2226 (e.g., Fig.21 (one or more) application subnets 2126) of the control plane application layer 2224 (e.g., Fig.21 The control plane application layer 2124 of FIG. 1 may include (one or more) database (DB) subnets 2230 (e.g., similar to Fig.21 (one or more) DB subnets 2130) of the control plane data layer 2228 (e.g., Fig.21 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.21 2134), and the application subnet(s) 2226 may be communicatively coupled to the DB subnet(s) 2230 and the service gateway 2236 (e.g., Fig.21 service gateway 2136) and network address translation (NAT) gateway 2238 (e.g., Fig.21 The control plane VCN 2216 may include a service gateway 2236 and a NAT gateway 2238.

[0298] The control plane VCN 2216 may include a data plane mirror application layer 2240 (e.g., Fig.21 The data plane image application layer 2140). The (one or more) application subnets 2226 included in the data plane image application layer 2240 may include a computing instance 2244 (e.g., similar to Fig.21 The compute instance 2244 can facilitate the application subnet(s) 2226 of the data plane mirroring application layer 2240 and can include the application subnets 2226 of the data plane mirroring application layer 2246 (e.g., Fig.21 Communication between (one or more) application subnets 2226 in the data plane application layer 2146) via the VNIC 2242 contained in the data plane mirror application layer 2240 and the VNIC 2242 contained in the data plane application layer 2246.

[0299] The Internet gateway 2234 included in the control plane VCN 2216 can be communicatively coupled to the metadata management service 2252 (e.g., Fig.21 2152), which can be communicatively coupled to the public Internet 2254 (e.g., Fig.21 The public Internet 2254 can be communicatively coupled to a NAT gateway 2238 included in the control plane VCN 2216. The service gateway 2236 included in the control plane VCN 2216 can be communicatively coupled to a cloud service 2256 (e.g., Fig.21 Cloud service 2156).

[0300] In some examples, the data plane VCN 2218 may be contained in a customer lease 2221. In this case, the IaaS provider may provide a control plane VCN 2216 for each customer, and the IaaS provider may provision each customer with a unique compute instance 2244 contained in a service lease 2219. Each compute instance 2244 may allow communication between a control plane VCN 2216 contained in a service lease 2219 and a data plane VCN 2218 contained in a customer lease 2221. The compute instance 2244 may allow resources provisioned in a control plane VCN 2216 contained in a service lease 2219 to be deployed or otherwise used in a data plane VCN 2218 contained in a customer lease 2221.

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

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

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

[0304] Fig.23 2300 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2302 (e.g., Fig.21 The service operator 2102) can be communicatively coupled to the secure host lease 2304 (e.g., Fig.21 The secure host lease 2104 may include a virtual cloud network (VCN) 2306 (e.g., Fig.21 VCN 2106) and secure host subnet 2308 (e.g., Fig.21 VCN 2306 may include LPG 2310 (e.g., Fig.21 ), which may be communicatively coupled to the SSH VCN 2312 via the LPG 2310 contained in the SSH VCN 2312 (e.g., Fig.21 SSH VCN 2312). SSH VCN 2312 may include SSH subnet 2314 (e.g., Fig.21 SSH subnet 2114 of the control plane VCN 2314), and SSH VCN 2312 can be communicatively coupled to control plane VCN 2316 via LPG 2310 contained in control plane VCN 2316 (e.g., Fig.21 The control plane VCN 2116 of the embodiment of the present invention is coupled to the data plane VCN 2318 via the LPG 2310 contained in the data plane VCN 2318 (e.g., Fig.21 The control plane VCN 2316 and the data plane VCN 2318 may be included in a service lease 2319 (e.g., Fig.21 Service lease 2119).

[0305] The control plane VCN 2316 may include a load balancer (LB) subnet 2322 (e.g., Fig.21 The control plane DMZ layer 2320 (e.g., Fig.21 The control plane DMZ layer 2120 may include (one or more) application subnets 2326 (e.g., similar to Fig.21 (one or more) application subnets 2126) of the control plane application layer 2324 (e.g., Fig.21 The control plane application layer 2124 of the embodiment of the present invention may include a control plane data layer 2328 (e.g., Fig.21 The LB subnet(s) 2322 contained in the control plane DMZ layer 2320 may be communicatively coupled to the application subnet(s) 2326 contained in the control plane application layer 2324 and the Internet gateway 2334 (e.g., Fig.21 2134), and the application subnet(s) 2326 may be communicatively coupled to the DB subnet(s) 2330 and the service gateway 2336 (e.g., Fig.21 ) and a network address translation (NAT) gateway 2338 (e.g., Fig.21 The control plane VCN 2316 may include a service gateway 2336 and a NAT gateway 2338.

[0306] The data plane VCN 2318 may include a data plane application layer 2346 (e.g., Fig.21 Data plane application layer 2146), data plane DMZ layer 2348 (e.g., Fig.21 Data plane DMZ layer 2148), and data plane data layer 2350 (e.g., Fig.21 The data plane DMZ layer 2348 may include the trusted application subnet(s) 2360 and the untrusted application subnet(s) 2362 that may be communicatively coupled to the data plane application layer 2346 and the LB subnet(s) 2322 of the Internet gateway 2334 included in the data plane VCN 2318. The trusted application subnet(s) 2360 may be communicatively coupled to the service gateway 2336 included in the data plane VCN 2318, the NAT gateway 2338 included in the data plane VCN 2318, and the DB subnet(s) 2330 included in the data plane data layer 2350. The untrusted application subnet(s) 2362 may be communicatively coupled to the service gateway 2336 included in the data plane VCN 2318 and the DB subnet(s) 2330 included in the data plane data layer 2350. The data plane data layer 2350 may include (one or more) DB subnets 2330 that may be communicatively coupled to a service gateway 2336 included in the data plane VCN 2318.

[0307] The untrusted application subnet(s) 2362 may include one or more primary VNICs 2364(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2366(1)-(N). Each tenant VM 2366(1)-(N) may be communicatively coupled to a respective application subnet 2367(1)-(N) that may be contained in a respective container egress VCN 2368(1)-(N), which may be contained in a respective customer tenancy 2370(1)-(N). A respective secondary VNIC 2372(1)-(N) may facilitate communications between the untrusted application subnet(s) 2362 contained in the data plane VCN 2318 and the application subnets contained in the container egress VCN 2368(1)-(N). Each container egress VCN 2368(1)-(N) may include a NAT gateway 2338 that may be communicatively coupled to the public Internet 2354 (e.g., Fig.21 of the public Internet 2154).

[0308] An internet gateway 2334 included in control plane VCN 2316 and included in data plane VCN 2318 may be communicatively coupled to a metadata management service 2352 (e.g., Fig.21 2354) can be communicatively coupled to a public Internet 2354. The public Internet 2354 can be communicatively coupled to a NAT gateway 2338 included in the control plane VCN 2316 and included in the data plane VCN 2318. A service gateway 2336 included in the control plane VCN 2316 and included in the data plane VCN 2318 can be communicatively coupled to a cloud service 2356.

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

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

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

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

[0313] Fig.24 2400 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2402 (e.g., Fig.21 The service operator 2102) can be communicatively coupled to the secure host lease 2404 (e.g., Fig.21 The secure host lease 2104 may include a virtual cloud network (VCN) 2406 (e.g., Fig.21 VCN 2106) and secure host subnet 2408 (e.g., Fig.21 VCN 2406 may include LPG 2410 (e.g., Fig.21 LPG 2110), which can be accessed via an LPG 2410 contained in an SSH VCN 2412 (e.g., Fig.21 LPG 2410 in SSH VCN 2112 of the present invention is communicatively coupled to SSH VCN 2412. SSH VCN 2412 may include SSH subnet 2414 (e.g., Fig.21 SSH subnet 2114 of the control plane VCN 2414), and SSH VCN 2412 can be communicatively coupled to control plane VCN 2416 via LPG 2410 contained in control plane VCN 2416 (e.g., Fig.21 The control plane VCN 2116 of the embodiment of the present invention is coupled to the data plane VCN 2418 (e.g., the control plane VCN 2116 of the embodiment of the present invention) and is coupled to the data plane VCN 2418 (e.g., the control plane VCN 2116 of the embodiment of the present invention) via the LPG 2410 contained in the data plane VCN 2418 Fig.21 The control plane VCN 2416 and the data plane VCN 2418 may be included in a service lease 2419 (e.g., Fig.21 Service lease 2119).

[0314] The control plane VCN 2416 may include a LB subnet 2422 (e.g., Fig.21 The control plane DMZ layer 2420 (e.g., Fig.21 The control plane DMZ layer 2120 may include (one or more) application subnets 2426 (e.g., Fig.21 (one or more) application subnets 2126) of the control plane application layer 2424 (e.g., Fig.21 The control plane application layer 2124 of FIG. 1 may include (one or more) DB subnets 2430 (e.g., Fig.23 (one or more) DB subnets 2330) of the control plane data layer 2428 (e.g., Fig.21 The LB subnet(s) 2422 contained in the control plane DMZ layer 2420 may be communicatively coupled to the application subnet(s) 2426 contained in the control plane application layer 2424 and the Internet gateway 2434 (e.g., Fig.21 2434), and the application subnet(s) 2426 may be communicatively coupled to the DB subnet(s) 2430 and the service gateway 2436 (e.g., Fig.21 ) and a network address translation (NAT) gateway 2438 (e.g., Fig.21 The control plane VCN 2416 may include a service gateway 2436 and a NAT gateway 2438.

[0315] The data plane VCN 2418 may include a data plane application layer 2446 (e.g., Fig.21 Data plane application layer 2146), data plane DMZ layer 2448 (e.g., Fig.21 Data plane DMZ layer 2148)), and data plane data layer 2450 (e.g., Fig.21 The data plane DMZ layer 2448 may include (one or more) trusted application subnets 2460 (e.g., Fig.23 (one or more) trusted application subnets 2360) and (one or more) untrusted application subnets 2462 (e.g., Fig.23 The trusted application subnet(s) 2460 may be communicatively coupled to the service gateway 2436 contained in the data plane VCN 2418, the NAT gateway 2438 contained in the data plane VCN 2418, and the DB subnet(s) 2430 contained in the data plane data layer 2450. The untrusted application subnet(s) 2462 may be communicatively coupled to the service gateway 2436 contained in the data plane VCN 2418 and the DB subnet(s) 2430 contained in the data plane data layer 2450. The data plane data layer 2450 may include the DB subnet(s) 2430 that may be communicatively coupled to the service gateway 2436 contained in the data plane VCN 2418.

[0316] The untrusted application subnet(s) 2462 may include primary VNICs 2464(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2466(1)-(N) residing within the untrusted application subnet(s) 2462. Each tenant VM 2466(1)-(N) may run code in a corresponding container 2467(1)-(N) and may be communicatively coupled to an application subnet 2426 in a data plane application layer 2446 that may be contained in a container egress VCN 2468. Corresponding secondary VNICs 2472(1)-(N) may facilitate communications between the untrusted application subnet(s) 2462 contained in the data plane VCN 2418 and the application subnets contained in the container egress VCN 2468. The container egress VCN may include a primary VNIC that may be communicatively coupled to the public Internet 2454 (e.g., Fig.21 NAT gateway 2438 of the public Internet 2154).

[0317] The Internet gateway 2434 included in the control plane VCN 2416 and included in the data plane VCN 2418 can be communicatively coupled to the metadata management service 2452 (e.g., Fig.21 2452), which can be communicatively coupled to the public Internet 2454. The public Internet 2454 can be communicatively coupled to a NAT gateway 2438 contained in the control plane VCN 2416 and contained in the data plane VCN 2418. A service gateway 2436 contained in the control plane VCN 2416 and contained in the data plane VCN 2418 can be communicatively coupled to the cloud service 2456.

[0318] In some examples, Fig.24 The architecture model shown in block diagram 2400 can be considered as Fig.23 2300 , and may be desired by customers of the IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., a disconnected region). The customer may access the corresponding container 2467(1)-(N) contained in each customer's VM 2466(1)-(N) in real time. The container 2467(1)-(N) may be configured to make calls to the corresponding secondary VNIC 2472(1)-(N) contained in the (one or more) application subnets 2426 of the data plane application layer 2446, which may be contained in the container egress VCN 2468. The secondary VNIC 2472(1)-(N) may transmit the call to the NAT gateway 2438, which may transmit the call to the public Internet 2454. In this example, containers 2467(1)-(N), which may be accessed by customers in real time, may be isolated from control plane VCN 2416 and may be isolated from other entities contained in data plane VCN 2418. Containers 2467(1)-(N) may also be isolated from resources from other customers.

[0319] In other examples, a customer can use containers 2467(1)-(N) to call cloud service 2456. In this example, a customer can run code in containers 2467(1)-(N) to request a service from cloud service 2456. Containers 2467(1)-(N) can transmit the request to secondary VNICs 2472(1)-(N), which can transmit the request to a NAT gateway, which can transmit the request to public Internet 2454. Public Internet 2454 can transmit the request to LB subnet(s) 2422 contained in control plane VCN 2416 via Internet gateway 2434. In response to determining that the request is valid, LB subnet(s) can transmit the request to application subnet(s) 2426, which can transmit the request to cloud service 2456 via service gateway 2436.

[0320] It should be appreciated that the IaaS architectures 2100, 2200, 2300, 2400 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.

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

[0322] Fig.25 An example computer system 2500 in which various embodiments may be implemented is illustrated. System 2500 may be used to implement any of the computer systems described above. As shown, computer system 2500 includes a processing unit 2504 that communicates with a plurality of peripheral subsystems via a bus subsystem 2502. These peripheral subsystems may include a processing acceleration unit 2506, an I / O subsystem 2508, a storage subsystem 2518, and a communication subsystem 2524. Storage subsystem 2518 includes a tangible computer-readable storage medium 2522 and a system memory 2510.

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

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

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

[0326] I / O subsystem 2508 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 the eye gesture 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.

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

[0328] 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 2500 to a user or other computers. For example, the user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

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

[0330] like Fig.25 As depicted in the example of , storage subsystem 2518 may include various components, including system memory 2510, computer-readable storage media 2522, and computer-readable storage media reader 2520. System memory 2510 may store program instructions that may be loaded and executed by processing unit 2504. System memory 2510 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 2510, including but not limited to client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

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

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

[0333] Computer-readable storage media 2522 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 2500 (including instructions executable by processing unit 2504 of computer system 2500).

[0334] Computer readable storage media 2522 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.

[0335] As examples, computer-readable storage media 2522 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 2522 may include, but are not limited to, The computer readable storage medium 2522 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 2500.

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

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

[0338] In some embodiments, the communication subsystem 2524 may also receive input communications in the form of structured and / or unstructured data feeds 2526 , event streams 2528 , event updates 2530 , and the like on behalf of one or more users who may use the computer system 2500 .

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

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

[0341] The communication subsystem 2524 may also be configured to output structured and / or unstructured data feeds 2526, event streams 2528, event updates 2530, 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 2500.

[0342] Computer system 2500 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.

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

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

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

[0346] The description and drawings are therefore to be regarded as illustrative rather than restrictive. However, additions, subtractions, deletions and other modifications and changes may be made 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.

[0347] The use of the terms "a" and "an" and "the" and similar references in the context of describing the disclosed embodiments (especially in the context of the following claims) is to be interpreted as covering the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context. Unless otherwise stated, the terms "include", "have", "include" and "contain" are to be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" should be interpreted as being partially or completely contained in, attached to or connected together, even if there is something in the middle. Unless otherwise indicated herein, the enumeration of value ranges 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 does not 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.

[0348] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in the context of being generally used to indicate that an item, term, etc. 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.

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

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

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

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

[0353] Clause 1: A method comprising:

[0354] Receiving, by a computing system, a request for a file system copy between a source file system and a target file system, the source file system and the target file system being in different zones;

[0355] Processing, by a computing system, a plurality of binary tree (B-tree) key-value pairs that differ between two snapshots of a source file system;

[0356] Assigning, by the computing system, a first identifier to a first set of key-value pairs in the plurality of B-tree key-value pairs; and

[0357] A second identifier is assigned to a second set of key-value pairs in the plurality of B-tree key-value pairs by the computing system when a failure event is detected during file system replication.

[0358] Clause 2: The method of clause 1, wherein the processing comprises identifying the plurality of B-tree key-value pairs and uploading them to an object storage device.

[0359] Clause 3: The method of clause 1 or clause 2, wherein the failure event is caused by a failure of the first processing thread.

[0360] Clause 4: The method of clause 3, wherein a first set of key-value pairs in the plurality of B-tree key-value pairs is processed by a first processing thread, and a second set of key-value pairs in the plurality of B-tree key-value pairs is processed by a second processing thread.

[0361] Clause 5: The method as described in Clause 4 also includes creating a record associated with a second processing thread for tracking a second group of key-value pairs in the multiple B-tree key-value pairs, and the record associated with the second processing thread is different from the record associated with the first processing thread for tracking the first group of key-value pairs in the multiple B-tree key-value pairs.

[0362] Clause 6: The method of clause 1 or clause 2, wherein the failure event is caused by a system crash.

[0363] Clause 7: The method of Clause 6, wherein both the first set of key-value pairs and the second set of key-value pairs in the plurality of B-tree key-value pairs are processed by a single processing thread.

[0364] Clause 8: The method of any of clauses 1 to 7, wherein the first identifier and the second identifier are numerical numbers, and the second identifier has a higher number than the first identifier.

[0365] Clause 9: The method as described in Clause 8 also includes: if the first group and the second group have overlapping key-value pairs, then the target file system discards the overlapping portion of the first group of key-value pairs in the multiple B-tree key-value pairs at least in part based on the second identifier having a higher number than the first identifier.

[0366] Clause 10: The method of any of clauses 1 to 9, wherein the plurality of B-tree key-value pairs belong to a key range of a plurality of key ranges.

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

[0368] Receiving, by a computing system, a request for a file system copy between a source file system and a target file system, the source file system and the target file system being in different zones;

[0369] Processing, by a computing system, a plurality of binary tree (B-tree) key-value pairs that differ between two snapshots of a source file system;

[0370] Assigning, by the computing system, a first identifier to a first set of key-value pairs in the plurality of B-tree key-value pairs; and

[0371] A second identifier is assigned to a second set of key-value pairs in the plurality of B-tree key-value pairs by the computing system when a failure event is detected during file system replication.

[0372] Clause 12: The non-transitory computer-readable medium of Clause 11, wherein the failure event is caused by a failure of the first processing thread.

[0373] Clause 13: The non-transitory computer-readable medium of Clause 12, wherein a first set of key-value pairs in the plurality of B-tree key-value pairs is processed by a first processing thread and a second set of key-value pairs in the plurality of B-tree key-value pairs is processed by a second processing thread.

[0374] Clause 14: The non-transitory computer readable medium of Clause 11, wherein the failure event is caused by a system crash.

[0375] Clause 15: The non-transitory computer-readable medium of Clause 14, wherein both the first set of key-value pairs and the second set of key-value pairs in the plurality of B-tree key-value pairs are processed by a single processing thread.

[0376] Clause 16: A non-transitory computer-readable medium as described in any of Clauses 11 to 15, wherein the operation further includes: if the first group and the second group have overlapping key-value pairs, then the target file system discards the overlapping portion of the first group of key-value pairs in the plurality of B-tree key-value pairs at least in part based on the second identifier having a higher number than the first identifier, wherein the first identifier and the second identifier are numerical numbers and the second identifier has a higher number than the first identifier.

[0377] Clause 17: A system comprising:

[0378] one or more processors; and

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

[0380] receiving a request for a file system replication between a source file system and a target file system, the source file system and the target file system being in different zones;

[0381] Handling multiple binary tree (B-tree) key-value pairs that differ between two snapshots of a source file system;

[0382] Assigning a first identifier to a first set of key-value pairs in the plurality of B-tree key-value pairs; and

[0383] A second identifier is assigned to a second set of key-value pairs in the plurality of B-tree key-value pairs when a failure event is detected during the file system replication.

[0384] Clause 18: A system as described in Clause 17,

[0385] wherein the fault event is caused by a fault of the first processing thread; and

[0386] A first group of key-value pairs in the plurality of B-tree key-value pairs is processed by a first processing thread, and a second group of key-value pairs in the plurality of B-tree key-value pairs is processed by a second processing thread.

[0387] Clause 19: A system as described in Clause 17,

[0388] where the failure event is caused by a system crash; and

[0389] Wherein both a first set of key-value pairs and a second set of key-value pairs in the plurality of B-tree key-value pairs are processed by a single processing thread.

[0390] Clause 20: A system as described in any of Clauses 17 to 19, wherein the system is further configured to: if the first group and the second group have overlapping key-value pairs, then the target file system discards the overlapping portion of the first group of key-value pairs in the plurality of B-tree key-value pairs at least in part based on the second identifier having a higher number than the first identifier, wherein the first identifier and the second identifier are numerical numbers and the second identifier has a higher number than the first identifier.< / gennum>

Claims

1. A method comprising: Receiving, by a computing system, a request for a file system copy between a source file system and a target file system, the source file system and the target file system being in different zones; Creating, by a first processing thread of the computing system, a checkpoint in the first key range in response to a request for a file system copy after satisfying predetermined requirements for processing a binary tree (B-tree) key-value pair in the first key range; requesting, by a first processing thread of the computing system, a lock for updating a central record after creating a checkpoint in a first key range; Creating, by a second processing thread of the computing system, a checkpoint in the second key range in response to the request for the file system copy after satisfying predetermined requirements for processing the B-tree key-value pairs in the second key range; requesting, by a second processing thread of the computing system, the lock for updating the central record after creating a checkpoint in a second key range; The lock is granted by the computing system to a first processing thread to update a central record, the first processing thread requesting the lock for updating the central record prior to a request by a second processing thread.

2. The method of claim 1, wherein the lock prevents the second processing thread from updating the central record.

3. The method of claim 2, further comprising: After updating the central record, processing more B-tree key-value pairs in the first key range by the first processing thread; as well as After the first processing thread completes updating the central record, the lock is granted by the computing system to the second processing thread to update the central record.

4. The method of claim 2 or claim 3, further comprising processing, by a second processing thread, more B-tree key-value pairs in a second key range while waiting for the lock.

5. The method of any one of claims 1 to 4, wherein the first processing thread operates independently of the second processing thread.

6. The method of any one of claims 1 to 5, wherein the processing of the B-tree key-value pairs in the first key range by the first processing thread is performed in parallel with the processing of the B-tree key-value pairs in the second key range by the second processing thread.

7. The method of any one of claims 1 to 6 further comprises, when a system failure is detected, restarting, by the first processing thread, processing of B-tree key-value pairs in the first key range from the B-tree key after a checkpoint in the first key range.

8. The method of any one of claims 1 to 7, further comprising, when a failure of the first processing thread is detected, restarting processing of B-tree key-value pairs in the first key range by a third processing thread from a B-tree key after a checkpoint in the first key range.

9. A non-transitory computer readable medium storing computer executable instructions, which, when executed by one or more processors of a computing system, cause the one or more processors to perform operations comprising: Receiving, by a computing system, a request for a file system copy between a source file system and a target file system, the source file system and the target file system being in different zones; Creating, by a first processing thread of the computing system, a checkpoint in the first key range in response to a request for a file system copy after satisfying predetermined requirements for processing a binary tree (B-tree) key-value pair in the first key range; requesting, by a first processing thread of the computing system, a lock for updating a central record after creating a checkpoint in a first key range; Creating, by a second processing thread of the computing system, a checkpoint in the second key range in response to the request for the file system copy after satisfying predetermined requirements for processing the B-tree key-value pairs in the second key range; requesting, by a second processing thread of the computing system, the lock for updating the central record after creating a checkpoint in a second key range; The lock is granted by the computing system to a first processing thread to update a central record, the first processing thread's request for the lock to update the central record precedes a request by a second processing thread, the lock being configured to prevent the second processing thread from updating the central record.

10. The non-transitory computer readable medium of claim 9, the operations further comprising: After updating the central record, processing more B-tree key-value pairs in the first key range by the first processing thread; as well as After the first processing thread completes updating the central record, the lock is granted by the computing system to the second processing thread to update the central record.

11. The non-transitory computer readable medium of claim 9 or claim 10, wherein the first processing thread operates independently of the second processing thread.

12. The non-transitory computer-readable medium of any one of claims 9 to 11, wherein processing of B-tree key-value pairs in a first key range by a first processing thread is performed in parallel with processing of B-tree key-value pairs in a second key range by a second processing thread.

13. The non-transitory computer-readable medium of any one of claims 9 to 12, wherein the operation further comprises, when a system failure is detected, resuming processing of B-tree key-value pairs in the first key range by the first processing thread from the B-tree key after a checkpoint in the first key range.

14. The non-transitory computer-readable medium of any one of claims 9 to 13, wherein the operation further comprises, when a failure of the first processing thread is detected, restarting processing of B-tree key-value pairs in the first key range by a third processing thread from a B-tree key after a checkpoint in the first key range.

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: receiving a request for a file system replication between a source file system and a target file system, the source file system and the target file system being in different zones; Creating, by a first processing thread of the system, a checkpoint in the first key range in response to a request for a file system copy after satisfying predetermined requirements for processing binary tree (B-tree) key-value pairs in the first key range; requesting, by a first processing thread of the system, a lock for updating a central record after creating a checkpoint in a first key range; Creating, by a second processing thread of the system, a checkpoint in the second key range in response to a request for a file system copy after satisfying predetermined requirements for processing B-tree key-value pairs in the second key range; requesting, by the second processing thread after creating a checkpoint in the second key range, the lock for updating the central record; The lock is granted to a first processing thread to update a central record, the first processing thread's request for the lock to update the central record precedes a request by a second processing thread, the lock being configured to prevent the second processing thread from updating the central record.

16. The system of claim 15, wherein the system is further configured to: After updating the central record, processing more B-tree key-value pairs in the first key range by a first processing thread of the system; and After the first processing thread completes updating the central record, the lock is granted to the second processing thread to update the central record.

17. A system as claimed in claim 15 or claim 16, wherein the first processing thread operates independently of the second processing thread.

18. The system of any one of claims 15 to 17, wherein the processing of B-tree key-value pairs in a first key range by a first processing thread is performed in parallel with the processing of B-tree key-value pairs in a second key range by a second processing thread.

19. The system of any one of claims 15 to 18, wherein when a system failure is detected, the system is further configured to restart processing of B-tree key-value pairs in the first key range by the first processing thread from the B-tree key after the checkpoint in the first key range.

20. The system of any one of claims 15 to 19, wherein the system is further configured to restart processing of B-tree key-value pairs in the first key range by a third processing thread from the B-tree key after a checkpoint in the first key range when a failure of the first processing thread is detected.

Images