Hierarchical key management across regional replication

Abstract

Techniques are described for performing hierarchical key management involving end-to-end file storage replication between different cloud infrastructure regions. Hierarchical key management includes three different keys: a first security key for a source region, a session key valid only within a session for communicating data between two different regions, and a second security key for a target region. Novel techniques for using different file keys for different files of a file system in each region are also described.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. non-provisional application No. 18 / 094,302, filed on January 6, 2023, entitled “HIERARCHICAL KEY MANAGEMENT FOR CROSS-REGION REPLICATION,” which claims the benefit and priority of 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, key management techniques involving end-to-end file storage replication between different cloud infrastructure regions are described. Background Art

[0004] Enterprise businesses contain critical data. While a good disaster recovery solution is important, security is also an essential aspect. The security of critical data needs to be guaranteed when it is at rest in the data center and when it is in transit between data centers during failover and failback. Therefore, security is required in disaster recovery. Summary of the invention

[0005] The present disclosure relates generally to file systems. More specifically, but not limited to, key management techniques involving end-to-end file storage replication between different cloud infrastructure regions are described.

[0006] In certain embodiments, a technique is provided that includes a method comprising: generating, by a computing system at least in part based on a first master key, a first security key associated with a source file system for encrypting and decrypting a plurality of file keys in the source file system, the source file system being configured to send snapshot increments during a replication process, the snapshot increments being identified between two snapshots of the source file system; generating, by the computing system at least in part based on a second master key, a second security key associated with a target file system for encrypting and decrypting a plurality of file keys in the target file system, the target file system being configured to receive snapshot increments during the replication process; and generating, by the computing system at least in part based on a third master key, a session key for encrypting and decrypting snapshot increments transmitted between the source file system and the target file system during the replication process, the session key being valid for a session; the first master key, the second master key, and the third master key being different keys.

[0007] In yet another embodiment, a session is the duration between the start of a copy process in a source file system and the end of the copy process in a target file system.

[0008] In yet another embodiment, the snapshot delta transferred between the source file system and the target file system further includes an object storage device configured to receive the snapshot delta from the source file system and forward the snapshot delta to the target file system.

[0009] In yet another embodiment, the method further includes encrypting the snapshot delta using the session key before transmitting the snapshot delta to the object storage device, and decrypting the snapshot delta using the session key after transmitting the snapshot delta to the target file system.

[0010] In yet another embodiment, the method further includes transmitting the session key from the control plane of the source file system to the control plane of the target file system.

[0011] In yet another embodiment, the session key is associated with a globally unique resource identifier.

[0012] In another embodiment, each of the multiple file keys in the source file system is associated with a specific file in the source file system and is used to encrypt and decrypt file data of the specific file in the source file system, and each of the multiple file keys in the target file system is associated with a specific file in the target file system and is used to encrypt and decrypt file data of the specific file in the target file system.

[0013] In yet another embodiment, the method further includes authenticating a key requester in the source file system who requests to use the first security key; and authenticating a key requester in the target file system who requests to use the second security key.

[0014] In yet another embodiment, authenticating the key requestor in the source file system includes checking an identification number of the replication process and an identification number of the source file system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0033] Fig.13 is a flow diagram illustrating key management for cross-region replication according to certain embodiments.

[0034] Fig.14 is a flow chart illustrating the steps of session key generation according to some embodiments.

[0035] Fig.15 Depicted is a simplified table format (or schema) for a shared database (SDB) for storing encrypted session keys in accordance with certain embodiments.

[0036] Fig.16 is a flow diagram illustrating an end-to-end key management process for cross-region replication in accordance with certain embodiments.

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

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

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

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

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

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

[0043] The present disclosure relates generally to file systems. More specifically, but not limited to, key management techniques involving end-to-end file storage replication between different cloud infrastructure regions are described.

[0044] In certain embodiments, the file storage service (FSS) disclosed in the present disclosure utilizes a three-tier key architecture for cross-region replication. Three different keys may be involved during the replication process: source file system key (FSKa), session key, and target file system key (FSKb). In each source and target region, its file system key is also a hierarchical structure to encrypt local files, and the file system key is securely stored using a master key from the customer.

[0045] In some embodiments, in the source file system, it has three keys: a source file key (FKa) for each file, a source file system key (FSKa), and a master key (based on customer-managed keys). The source file system has multiple files, each with its own file key FKa for encryption and decryption. In the target file system, it has three keys: a target file key (FKb) for each file, a target file system key (FSKb), and a master key (based on customer-managed keys). In some embodiments, the master key of the source file system is different from the master key of the target file system.

[0046] Explanation of terms in certain embodiments

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

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

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

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

[0051] For purposes of this disclosure and in certain embodiments, a "shared database" (SDB) may refer to a key-value store through which components in the control plane and data plane of a file system (e.g., replicator queues) can read and write to communicate with each other.

[0052] In some embodiments, the SDB may be part of a B-tree.

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

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

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

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

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

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

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

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

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

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

[0063] In the context of the cloud, a region is a local geographic area that includes one or more connected data centers. Regions are independent of other regions and can be separated by great distances - across countries or even continents. A realm is a logical collection of one or more regions. Realms are typically isolated from each other and do not share data. Within a region, data centers in a region can be organized into one or more availability domains (ADs). Availability domains are isolated from each other, fault-tolerant, and unlikely to fail at the same time. ADs are configured so that a failure at one AD in a region is unlikely to affect the availability of other ADs in the same region.

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

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

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

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

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

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

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

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

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

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

[0074] 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 source region 290 and one file system 282 in target region 292 are shown. If there are multiple file systems in a region, the same replication architecture applies to each pair of source and target file systems. File systems in a region can share resources. For example, depending on the implementation, certain resources in KMS 250, object repository 260, and the data plane can be shared by many file systems in the same region.

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

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

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

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

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

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

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

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

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

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

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

[0086] 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 it somewhere before applying it to the target so that the data is not lost.

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

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

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

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

[0091] 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 fast as possible, and the target can start downloading as soon as it 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0163] 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 an X-region completion notification. The source file system returns the ready-to-copy metadata state 1002 to start another replication cycle.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0180] 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:

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

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

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

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

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

[0186] Hierarchical key management architecture

[0187] For the purposes of this application, in some examples, a KMS vault is a key management service that stores and manages master encryption keys and secrets for secure access to resources. The KMS vault enables secure storage of master encryption keys (or master keys) and secrets that might otherwise be stored in configuration files or code. The vault service is integrated with FSS to support the use of customer-managed keys. The master encryption key obtained from the KMS vault can be used to generate other encryption keys, such as file system keys (FSKs) and / or incremental encryption keys (DEKs, also referred to herein as session keys), for encryption / decryption of other keys or data. For security purposes, FSKs and DEKs may also be referred to herein as security keys. Each vault master key can be automatically assigned a key version. The vault service supports keys as a cloud infrastructure and assigns a globally unique resource identifier (e.g., Oracle Cloud ID (OCID)) to each key.

[0188] In certain embodiments, the file storage service (FSS) disclosed in the present disclosure utilizes a three-tier key architecture for cross-region replication. Three different keys may be involved during the replication process: source file system key (FSKa), session key, and target file system key (FSKb). In each source and target region, its file system key is also a hierarchical structure to encrypt local files, and the file system key is securely stored using a master key from the customer.

[0189] In some embodiments, in the source file system, it has three keys: a source file key (FKa) for each file, a source file system key (FSKa), and a master key (based on customer-managed keys). The source file system has multiple files, each with its own file key FKa for encryption and decryption. Each FKa is encrypted by FSKa and stored in the iNode of the file B-tree. The FSKa unique to each file system is generated and encrypted / decrypted by the file master key (which may be referred to as the source-side master key herein) provided by the customer, and stored in the metadata of the data plane. A similar scheme is used in the target area. In the target file system, it has three keys: a target file key (FKb) for each file, a target file system key (FSKb), and a master key (based on customer-managed keys), which may be referred to as the target-side master key herein. In some embodiments, the master key of the source file system is different from the master key of the target file system.

[0190] During cross-region replication, the three keys mentioned for cross-region replication can be used to decrypt and encrypt data during transfer between regions. FSS defines sessions, and each session is a data cycle (or a replication cycle). Session keys are created only for that session to transfer data. First, the source region decrypts its file data using FSKa (via FKa) during incremental generation. Second, the data (e.g., blobs and manifest files) are encrypted using the session key in the source region and uploaded for storage in the object repository. Third, the session key is transferred from the CP of the source region to the CP of the target region using the Key Management Service (KMS). Fourth, the target region downloads the data from the object repository and decrypts it using the session key. Finally, the target region re-encrypts its data using FSKb (via FKb) and stores it locally in the B-tree.

[0191] Existing key management for file system replication may use one encryption key for more than one zone and transfer data between different zones. This increases the risk of data integrity being compromised across zones once the security of the local zone is compromised. Therefore, a different approach is needed to address these challenges related to security risks and other risks.

[0192] The three-tier key architecture disclosed in this disclosure avoids any exposure of FSKa or customer-managed keys (or master keys) outside of the source region by using session keys to encrypt data (e.g., blobs and lists) before uploading them to the object repository. In addition, the key infrastructure of FSS has a unique key (e.g., FSKa) for each file system, rather than sharing file system-level keys between multiple file systems in one or more regions, thereby adding additional protection in each file system. Finally, the session key is transmitted through the CP API (requiring the help of KMS before being used again) instead of being transmitted with the data through the object repository, which is the third level of protection.

[0193] In some embodiments, all keys involved in the replication process are stored in encrypted form. For example, customer-managed keys (or service keys) are securely stored in the KMS vault. In some embodiments, FSKa and FKa are encrypted and stored locally in the source B-tree, while FSKb and FKb are encrypted and stored locally in the target B-tree. To further ensure security, there is an authentication process in both the source and target regions to check the identity of the key requester. For example, the control plane (including the file system key server (FSK service)) can check the replication ID (i.e., the replication job that the key requester will perform) and the file system number (i.e., which file system the key requester belongs to) provided by the key requester before granting the file system key (FSK).

[0194] Placing the KMS vault in the target region while creating the session key in the source region for replication purposes has the following advantages: When an unexpected disaster occurs in the source region, the session key will remain in the target region because the target file system can still download the data (or objects) in the object repository and decrypt the data for the application. In some embodiments, for security reasons, the session key is temporarily stored in the source region to be used to encrypt the data to be uploaded to the object repository.

[0195] Fig.13 is a flow diagram illustrating key management for cross-region replication according to certain embodiments. Fig.13 In the example, components involved in key management in the source zone 1301 include a snapshot monitor 1310, a shared database (SDB) 1312, a replicator 1314, and a file system key (FSK) service 1316. Components involved in key management in the target zone 1302 include a key management service (KMS) 1350, an application programming interface (API) 1330, an SDB 1332, an object storage device 1360, a replicator 1334, and an FSK service 1336. When the replication process is initiated, the control plane of the source file system can cooperate with the data plane to start Fig.13 The key management process shown in .

[0196] exist Fig.13 In step S1, the source replicator 1314 communicates with the target KMS vault 1350 to obtain a master key (different from the master key of the source FSK discussed above), which may be referred to herein as a cross-region master key, to generate a new session key (i.e., DEK, plain text key) for the replication cycle. In some cases, after another failed replicator has previously generated a session key, a replicator (or a replicator thread, also referred to herein as a replacement replicator) can take over the replication job from the other failed replicator to restart replication. In some embodiments, the replacement replicator first checks the source SDB 1312 (refer to step S3 discussed later) to obtain the locally stored session key (i.e., decrypt the existing DTK). If for some rare cases, the source SDB loses the record of the session key, then the replacement replicator will need to generate a new DEK by using CGO code to call the KMS API and provide the KMS resource ID to communicate with the target KMS vault to obtain the master key, thereby restarting the replication job (i.e., encrypting the remaining unfinished increments left before).

[0197] At step S2, the source replicator 1314 communicates with the FSK service 1316 to obtain the source file system key (FSKa). The FSK service 1316 also performs authentication on the key requester, the source replicator 1314, by checking the replication ID and the file system number (FSNum) to ensure that the key requester is indeed associated with a specific file system and a specific replication process. At step S3, the source replicator 1314 uses FSKa to encrypt the session key DEK (the encrypted session key is referred to as the incremental transfer key (DTK) in this article) to store it in the source SDB 1312 for use by other replicator threads (including replacement threads) later during the replication cycle, thereby avoiding the need to communicate with the KMS again through a cross-region call. At step S4, the source replicator 1314 caches FSKa locally. At step S5, in addition to storing the DTK in the source SDB 1312, the source replicator 1314 also caches the DTK locally. At step S6, during the replication cycle, each replicator thread handling the replication job (i.e., part of the overall replication) checks the source SDB 1312 to reuse the session key (i.e., DEK) by decrypting the encrypted session key (i.e., DTK) using the locally cached FSKa. The source replicator 1314 also uses FSKa to decrypt its local FKa, which in turn is used to decrypt the file data collected during the B-tree walk. So far, the above steps are performed within the source area 1301.

[0198] From steps S7 to S9, the key management process enters the cross-region phase. At step S7, in some embodiments, the source replicator 1314 then decrypts the data using FSKa (as discussed above) and re-encrypts the data (e.g., B-tree key values, file data, manifest files, and metadata) using the session key and uploads it to the object repository 1360 as an object in the target region 1302. In some embodiments, a portion of the data (e.g., internal metadata for internal management purposes) may not be encrypted.

[0199] At step S8, the source replicator 1314 notifies the state machine to change to the Manifest_Copied state by marking a record in the source SDB 1312. At step S9, the snapshot monitor in the source area 1301 transmits the encrypted session key (i.e., DTK) and the KMS key resource ID to the target API 1330. Although the flowchart shows that the step of transmitting the data objects to the object repository (S7) occurs before the step of transmitting the DTK to the target API (S9), the source area does not need to wait until all data objects are transmitted before starting step S9. The sooner the source file system can transmit the DTK to the target file system, the sooner the target file system can download and decrypt the data.

[0200] At step S10, the target API 1330 stores the received encrypted session key (i.e., DTK) and KMS key resource ID in the target SDB 1332 for reuse during the replication cycle. At step S11, the target replicator 1334 (or replicator thread) obtains the encrypted session key and KMS key resource ID from the target SDB 1332. The target replicator 1334 also checks whether the DTK has expired. If it has expired, the target replicator 1334 triggers an alarm and signals a hard failure. Otherwise, it moves to the next step. At step S12, the target replicator 1334 sends the encrypted session key and KMS key resource ID to the KMS vault 1350 and requests to decrypt the DTK (i.e., to become a DEK) for use. The KMS vault 1350 also authenticates the key requester, the target replicator 1334, to ensure that the DTK is used for the session associated with this particular replication cycle. At step S13, the target replicator 1334 caches the session key (i.e., DEK) locally. At step S14, the target replicator 1334 downloads data from the object repository 1360 and decrypts the data using the session key. At step S15, the target replicator 1334 communicates with the target FSK service 1336 to obtain the target file system key (FSKb). The target FSK service 1336 also performs authentication on the key requester, the source replicator 1334, by checking the replication ID and the file system number to ensure that the key requester is indeed associated with a specific file system and a specific replication process. At step S16, the target replicator 1334 caches FSKb locally for reuse. At step S17, the target replicator 1334 uses FSKb to decrypt the target file key (FKb) (the key is used to re-encrypt the data after applying the data to its latest snapshot), and then stores the data locally in the B-tree. At step S18, the target replicator 1334 notifies the state machine to change to the replicated state by marking the record in the target SDB 1332.

[0201] When the source completes the upload (which may happen before the target's download process), the source cleans up its storage and removes all keys. When the target completes its application of deltas to its latest snapshot, it cleans up its storage and also removes all keys. The FSS service also releases the KMS master key. Therefore, the key is valid only during the current replication cycle.

[0202] Fig.14 is a flow chart illustrating the steps of session key generation according to some embodiments. Fig.14 , the components involved in session key (ie, DEK) generation in source zone 1401 may be source SDB 1410, source control plane (CP) API 1412, source replicator 1414, and source FSK service 1416. The components in target zone 1402 involve target KMS vault 1418.

[0203] In some embodiments, at step S1, the source replicator 1414 receives a request from the CP to prepare for session key generation for the purpose of cross-region replication, and performs initialization to communicate with the KMS and object repository in the target region. At step S2, the source replicator 1414 communicates with the target KMS 1418 to list all vaults in a particular compartment. At step S3, the source replicator 1414 obtains all keys for a particular vault whose vault prefix matches the expected prefix, because both the key and the vault have a unique prefix name. At step S4, the source replicator 1414 caches the master key resource ID for future use by all ADs. Since the master key vault and key are unique for each AD, caching the resource IDs of other ADs in the same source region when processing the keys of the AD can help reduce future communications with the KMS. At step S5, the source replicator 1414 generates a session key (i.e., DEK) using the additional authentication data (AAD) as the snapshot resource ID. AAD is metadata provided to KMS during encryption / decryption to help FSS verify whether a particular session key is associated with a snapshot resource. This provides an additional layer of protection. At step S6, as discussed above, all keys can be stored in encrypted form. Therefore, the source replicator 1414 encrypts the session key using the source file system key FSK 1316 (not shown), and stores the encrypted session key (i.e., DTK) and KMS source ID in the source SDB 1410 for reuse by other replicator threads in the current replication cycle. The key and its KMS resource ID need to be stored together so that they can be presented to the target KMS vault for later decryption. At step S7, the source replicator (worker replicator thread) 1414 caches the DEK for its use, and at step S8, the data to be uploaded to the object repository is re-encrypted using the session key DEK.

[0204] As discussed previously with respect to the pipeline stages in FIG. 6 , multiple replicator threads in a replicator queue may each handle a portion of the overall replication process. Steps 9 to 11 may be repeated for each replicator thread that performs the replication process. At step S9, the new source replicator thread 1414 obtains the encrypted session key DTK and the KMS resource ID from the source SDB 1410. At step S10, the new replicator thread 1414 communicates with the KMS vault by calling the KMS API using the CGO with the snapshot resource ID of the source region to obtain the decrypted session key DEK. At step S11, the new replicator thread 1414 re-encrypts the data for upload to the object repository.

[0205] When all replicator threads complete their replication tasks for the current replication cycle, at step S12, the source CP API 1412 deletes the encrypted session key DTK and KMS resource ID stored in the source SDB 1410. At step 13, all replicator threads 1414 clear the cached session key DEK from their memory. Therefore, this can make the session key valid only within one replication cycle (i.e., one session) and cannot be reused in another replication cycle.

[0206] Fig.15 Depicted is a simplified table format (or schema) of a shared database (SDB) for storing encrypted session keys DTK according to some embodiments. As discussed above, each region has an SDB for storing encrypted session keys DTK. In some embodiments, the SDB can be a key-value storage library. Thus, the schema has two parts: a key part and a value part. The information in this table can be used for communication between the DP and CP in each region. Fig.15 , the key portion 1510 includes a key type 1511, an object type 1512, an object number (i.e., an incremental transfer ID or a replication number) 1514, and a snapshot number 1516. The value portion 1520 includes a version 1522, a KMS key resource ID 1524, an encryption key 1526, a target file system number 1528, a target queue 1530, and a target availability domain (AD) 1532.

[0207] In some embodiments, the key portion 1510 of the architecture 1500 begins with a key type 1511, which indicates the type of metadata in the B-tree to help efficiently resolve the B-tree key. For example, the key type of metadata can include iNode, file mapping (i.e., fmap), etc. Object type 1512 can be used to distinguish the purpose of the key entry. For example, object type 1512 set to 10 can indicate that the entry is written by the source replicator in the source area and read by the CP of the source area to transfer the encrypted session key 1526 to the target area. On the other hand, object type 1512 set to 11 can indicate that the entry is written by the target CP after receiving the encrypted session key 1526 from the source area, and is read by the target replicator to decrypt the increment / data downloaded from the target object repository.

[0208] In some embodiments, the object number 1514 is used to identify which replication process (eg, a particular replication cycle) is associated with the encrypted session key DTK 1526. The snapshot number 1516 is used to identify the particular snapshot involved in the replication.

[0209] In some embodiments, the value portion 1520 of the schema 1500 begins with a version 1522 field, which indicates the version of the resource ID. The KMS key resource ID 1524 is the resource ID of the KMS master key in the target region. In an alternative embodiment, the KMS resource ID 1524 can be a customer managed key. The encryption key 1526 contains an octet string of ciphertext, vault prefix, and count to indicate the byte array length of the key. The target file system number 1528 is used to communicate with the FSK service to determine which target file system requires an FSK for authentication / verification purposes. The target queue 1530 is used to identify the replicator queue in the target DP. The target AD 1532 is used for authentication / verification purposes to confirm the region and AD of the target file system.

[0210] Fig.16 is a flowchart illustrating end-to-end key management processing for cross-region replication according to certain embodiments. In certain embodiments, the FSS three-tier key architecture may have three different system-level security keys - source file system key (FSKa), target file system key (FSKb), and session key (DEK). A security key may refer to a key used for security purposes and may encrypt / decrypt another key or data. FSKa is used for the source file system. FSKb is used for the target file system. The session key is used between the source file system and the target file system. Each of the three system-level security keys may be generated by three different master keys, respectively. The first version of the master key from the KMS vault may be used to generate FSKa in the source file system. The second version of the master key from the KMS vault may be used to generate FSKb in the target file system. The third version of the master key from the KMS vault may be used to generate DEK in the source file system. In addition, there are two different file-level security keys - the source file key (FKa) and the target file key (FKb).

[0211] In some embodiments, FSKa and the first version of the master key are maintained in the source region. FSKb and the second version of the master key are maintained in the target region. The third version of the master key may also be maintained in the source region. Only the DEK can be transmitted across the source and target regions and can be used to encrypt / decrypt data transmitted between the source and target regions. Therefore, the exposure of the key outside the region where the key is generated can be minimized.

[0212] At step 1610, the FSS may generate a source file system key (FSKa) in the source file system based on the source-side master key for use in encrypting / decrypting a file key (e.g., FKa) in the source file system. At step 1612, the source file system may use the source file key (FKa) to decrypt the file data of its corresponding file previously encrypted by FKa. At step 1614, the source replicator (e.g., Fig.13 At step 1314) the target KMS vault may communicate with the target KMS vault to obtain a cross-region master key to generate a new session key (i.e., DEK, plain text key) for the replication cycle (or session). At step 1616, during the incremental generation process in the source file system, the source file system may use the DEK to encrypt the generated snapshot incremental (including file data and manifest files).

[0213] At step 1630, the source file system may upload the encrypted snapshot increment to the object repository for download by the target file system. At step 1632, the source file system may encrypt the session key using FSKa to generate an encrypted session key (ie, DTK), which is then transmitted from the source CP to the target CP.

[0214] At step 1650, the target file system can decrypt the DTK with the help of KMS to obtain the DEK, and then use the DEK to decrypt the downloaded snapshot increment for incremental application. At step 1652, the FSS can generate a target file system key (FSKb) in the target file system based on the target-side master key for encryption / decryption of file keys (e.g., FKb) in the target file system. At step 1654, the target file system can use the target file key (FKa) to encrypt the file data in the downloaded snapshot increment during incremental application to store in its corresponding file.

[0215] Example cloud architecture

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

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

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

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

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

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

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

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

[0224] Fig.17 1700 is a block diagram illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 1702 can be communicatively coupled to a secure host lease 1704 that can include a virtual cloud network (VCN) 1706 and a secure host subnet 1708. In some examples, the service operator 1702 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 gesture input device), and / or a personal messaging device capable of communicating over a network that can access VCN 1706 and / or the Internet.

[0225] VCN 1706 may include a local peer gateway (LPG) 1710, which may be communicatively coupled to a secure shell (SSH) VCN 1712 via LPG 1710 contained in SSH VCN 1712. SSH VCN 1712 may include an SSH subnet 1714, and SSH VCN 1712 may be communicatively coupled to a control plane VCN 1716 via LPG 1710 contained in control plane VCN 1716. In addition, SSH VCN 1712 may be communicatively coupled to a data plane VCN 1718 via LPG 1710. Control plane VCN 1716 and data plane VCN 1718 may be contained in a service lease 1719, which may be owned and / or operated by an IaaS provider.

[0226] The control plane VCN 1716 may include a control plane demilitarized zone (DMZ) layer 1720 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 1720 may include one or more load balancer (LB) subnets 1722, a control plane application layer 1724 that may include (one or more) application subnets 1726, and a control plane data layer 1728 that may include (one or more) database (DB) subnets 1730 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 1722 included in the control plane DMZ layer 1720 may be communicatively coupled to the application subnet(s) 1726 included in the control plane application layer 1724 and the Internet gateway 1734 that may be included in the control plane VCN 1716, and the application subnet(s) 1726 may be communicatively coupled to the DB subnet(s) 1730 included in the control plane data layer 1728 as well as the service gateway 1736 and the network address translation (NAT) gateway 1738. The control plane VCN 1716 may include the service gateway 1736 and the NAT gateway 1738.

[0227] The control plane VCN 1716 may include a data plane mirror application layer 1740, which may include application subnet(s) 1726. The application subnet(s) 1726 included in the data plane mirror application layer 1740 may include a virtual network interface controller (VNIC) 1742 that may execute a compute instance 1744. The compute instance 1744 may communicatively couple the application subnet(s) 1726 of the data plane mirror application layer 1740 to the application subnet(s) 1726 that may be included in the data plane application layer 1746.

[0228] The data plane VCN 1718 may include a data plane application layer 1746, a data plane DMZ layer 1748, and a data plane data layer 1750. The data plane DMZ layer 1748 may include (one or more) LB subnets 1722, which may be communicatively coupled to (one or more) application subnets 1726 of the data plane application layer 1746 and an internet gateway 1734 of the data plane VCN 1718. The (one or more) application subnets 1726 may be communicatively coupled to a service gateway 1736 of the data plane VCN 1718 and a NAT gateway 1738 of the data plane VCN 1718. The data plane data layer 1750 may also include (one or more) DB subnets 1730, which may be communicatively coupled to (one or more) application subnets 1726 of the data plane application layer 1746.

[0229] The internet gateway 1734 of the control plane VCN 1716 and the data plane VCN 1718 may be communicatively coupled to a metadata management service 1752, which may be communicatively coupled to a public Internet 1754. The public Internet 1754 may be communicatively coupled to a NAT gateway 1738 of the control plane VCN 1716 and the data plane VCN 1718. The service gateway 1736 of the control plane VCN 1716 and the data plane VCN 1718 may be communicatively coupled to a cloud service 1756.

[0230] In some examples, service gateway 1736 of control plane VCN 1716 or data plane VCN 1718 can make application programming interface (API) calls to cloud services 1756 without going through public internet 1754. API calls from service gateway 1736 to cloud services 1756 can be one-way: service gateway 1736 can make API calls to cloud services 1756, and cloud services 1756 can send requested data to service gateway 1736. However, cloud services 1756 may not initiate API calls to service gateway 1736.

[0231] In some examples, secure host lease 1704 can be directly connected to service lease 1719, which can otherwise be isolated. Secure host subnet 1708 can communicate with SSH subnet 1714 through LPG 1710, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 1708 to SSH subnet 1714 can enable secure host subnet 1708 to access other entities within service lease 1719.

[0232] Control plane VCN 1716 may allow a user of service lease 1719 to set up or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1716 may be deployed or otherwise used in data plane VCN 1718. In some examples, control plane VCN 1716 may be isolated from data plane VCN 1718, and a data plane mirror application layer 1740 of control plane VCN 1716 may communicate with a data plane application layer 1746 of data plane VCN 1718 via a VNIC 1742, which may be included in both data plane mirror application layer 1740 and data plane application layer 1746.

[0233] 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 1754, which may transmit the request to the metadata management service 1752. The metadata management service 1752 may transmit the request to the control plane VCN 1716 through the internet gateway 1734. The request may be received by the LB subnet(s) 1722 contained in the control plane DMZ layer 1720. The LB subnet(s) 1722 may determine that the request is valid, and in response to the determination, the LB subnet(s) 1722 may transmit the request to the application subnet(s) 1726 contained in the control plane application layer 1724. If the request is validated and a call to the public internet 1754 is required, the call to the public internet 1754 may be transmitted to the NAT gateway 1738, which may make the call to the public internet 1754. The metadata that the request may desire to be stored may be stored in the DB subnet(s) 1730.

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

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

[0236] In other embodiments, the LB subnet(s) 1722 contained in the control plane VCN 1716 can be configured to receive signals from the service gateway 1736. In this embodiment, the control plane VCN 1716 and the data plane VCN 1718 can be configured to be called by customers of the IaaS provider without calling the public Internet 1754. 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 1719, which can be isolated from the public Internet 1754.

[0237] Fig.18 1800 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 1802 (e.g., Fig.17 The service operator 1702) can be communicatively coupled to the secure host lease 1804 (e.g., Fig.17 The secure host lease 1704 may include a virtual cloud network (VCN) 1806 (e.g., Fig.17 VCN 1706) and secure host subnet 1808 (e.g., Fig.17 The VCN 1806 may include a local peer gateway (LPG) 1810 (e.g., Fig.17 1710), which may be communicatively coupled to a secure shell (SSH) VCN 1812 via an LPG 1710 contained in an SSH VCN 1812 (e.g., Fig.17 SSH VCN 1812). SSH VCN 1812 may include SSH subnet 1814 (e.g., Fig.17 SSH subnet 1714 of the control plane VCN 1816), and SSH VCN 1812 can be communicatively coupled to control plane VCN 1816 via LPG 1810 contained in control plane VCN 1816 (e.g., Fig.17 The control plane VCN 1716). The control plane VCN 1816 can be included in the service lease 1819 (e.g., Fig.17 service lease 1719), and a data plane VCN 1818 (e.g., Fig.17 The data plane VCN 1718) may be contained in a customer lease 1821 which may be owned or operated by a user or customer of the system.

[0238] The control plane VCN 1816 may include a control plane DMZ layer 1820 (e.g., Fig.17 , which may include (one or more) LB subnets 1822 (e.g., Fig.17 (one or more) LB subnets 1722), may include (one or more) application subnets 1826 (e.g., Fig.17 (one or more) application subnets 1726) of the control plane application layer 1824 (e.g., Fig.17 The control plane application layer 1724 of FIG. 1724 may include (one or more) database (DB) subnets 1830 (e.g., similar to Fig.17 (one or more) DB subnets 1730) of the control plane data layer 1828 (e.g., Fig.17 1828 of the control plane data layer 1728). The LB subnet(s) 1822 contained in the control plane DMZ layer 1820 may be communicatively coupled to the application subnet(s) 1826 contained in the control plane application layer 1824 and the Internet gateway 1834 (e.g., Fig.17 1734), and the application subnet(s) 1826 may be communicatively coupled to the DB subnet(s) 1830 and the service gateway 1836 (e.g., Fig.17 service gateway 1736) and a network address translation (NAT) gateway 1838 (e.g., Fig.17NAT gateway 1738). The control plane VCN 1816 may include a service gateway 1836 and a NAT gateway 1838.

[0239] The control plane VCN 1816 may include a data plane mirror application layer 1840 (e.g., Fig.17 The data plane image application layer 1740). The (one or more) application subnets 1826 included in the data plane image application layer 1840 may include a computing instance 1844 (e.g., similar to Fig.17 The compute instance 1844 may facilitate the application subnet(s) 1826 of the data plane mirroring application layer 1840 and the application subnets 1826 that may be included in the data plane application layer 1846 (e.g., Fig.17 Communication between (one or more) application subnets 1826 in the data plane application layer 1746) via the VNIC 1842 contained in the data plane mirror application layer 1840 and the VNIC 1842 contained in the data plane application layer 1846.

[0240] The Internet gateway 1834 included in the control plane VCN 1816 can be communicatively coupled to the metadata management service 1852 (e.g., Fig.17 1752), which can be communicatively coupled to the public Internet 1854 (e.g., Fig.17 The public Internet 1854 can be communicatively coupled to a NAT gateway 1838 included in the control plane VCN 1816. The service gateway 1836 included in the control plane VCN 1816 can be communicatively coupled to cloud services 1856 (e.g., Fig.17 Cloud service 1756).

[0241] In some examples, the data plane VCN 1818 may be contained in a customer lease 1821. In this case, the IaaS provider may provide a control plane VCN 1816 for each customer, and the IaaS provider may provision each customer with a unique compute instance 1844 contained in a service lease 1819. Each compute instance 1844 may allow communication between the control plane VCN 1816 contained in the service lease 1819 and the data plane VCN 1818 contained in the customer lease 1821. The compute instance 1844 may allow resources provisioned in the control plane VCN 1816 contained in the service lease 1819 to be deployed or otherwise used in the data plane VCN 1818 contained in the customer lease 1821.

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

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

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

[0245] Fig.19 1900 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 1902 (e.g., Fig.17 The service operator 1702) can be communicatively coupled to the secure host lease 1904 (e.g., Fig.17 The secure host lease 1704 may include a virtual cloud network (VCN) 1906 (e.g., Fig.17 VCN 1706) and secure host subnet 1908 (e.g., Fig.17 VCN 1906 may include LPG 1910 (e.g., Fig.17 1710), which may be communicatively coupled to the SSH VCN 1912 via the LPG 1910 contained in the SSH VCN 1912 (e.g., Fig.17 SSH VCN 1912). SSH VCN 1912 may include SSH subnet 1914 (e.g., Fig.17 SSH subnet 1714 of the control plane VCN 1916), and SSH VCN 1912 can be communicatively coupled to control plane VCN 1916 via LPG 1910 contained in control plane VCN 1916 (e.g., Fig.17The control plane VCN 1716 of FIG. 1714 is coupled to the data plane VCN 1918 via the LPG 1910 included in the data plane VCN 1918 (e.g., Fig.17 The control plane VCN 1916 and the data plane VCN 1918 may be included in a service lease 1919 (e.g., Fig.17 Service lease 1719).

[0246] The control plane VCN 1916 may include a subnet 1922 (e.g., Fig.17 (one or more) LB subnets 1722) of the control plane DMZ layer 1920 (e.g., Fig.17 The control plane DMZ layer 1720 may include (one or more) application subnets 1926 (e.g., similar to Fig.17 (one or more) application subnets 1726) of the control plane application layer 1924 (e.g., Fig.17 A control plane application layer 1724), a control plane data layer 1928 (e.g., Fig.17 The LB subnet(s) 1922 contained in the control plane DMZ layer 1920 may be communicatively coupled to the application subnet(s) 1926 contained in the control plane application layer 1924 and the internet gateway 1934 (e.g., Fig.17 1734), and the application subnet(s) 1926 may be communicatively coupled to the DB subnet(s) 1930 and the service gateway 1936 (e.g., Fig.17 ) and a network address translation (NAT) gateway 1938 (e.g., Fig.17 NAT gateway 1738). The control plane VCN 1916 may include a service gateway 1936 and a NAT gateway 1938.

[0247] The data plane VCN 1918 may include a data plane application layer 1946 (e.g., Fig.17 Data plane application layer 1746), data plane DMZ layer 1948 (e.g., Fig.17 Data plane DMZ layer 1748), and data plane data layer 1950 (e.g., Fig.17The data plane DMZ layer 1948 may include (one or more) trusted application subnets 1960 and (one or more) untrusted application subnets 1962 that may be communicatively coupled to the data plane application layer 1946 and (one or more) LB subnets 1922 of the Internet gateway 1934 included in the data plane VCN 1918. The (one or more) trusted application subnets 1960 may be communicatively coupled to the service gateway 1936 included in the data plane VCN 1918, the NAT gateway 1938 included in the data plane VCN 1918, and (one or more) DB subnets 1930 included in the data plane data layer 1950. The (one or more) untrusted application subnets 1962 may be communicatively coupled to the service gateway 1936 included in the data plane VCN 1918 and (one or more) DB subnets 1930 included in the data plane data layer 1950. The data plane data layer 1950 may include (one or more) DB subnets 1930 that may be communicatively coupled to a service gateway 1936 included in the data plane VCN 1918.

[0248] Untrusted application subnet(s) 1962 may include one or more primary VNICs 1964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1966(1)-(N). Each tenant VM 1966(1)-(N) may be communicatively coupled to a respective application subnet 1967(1)-(N) that may be contained in a respective container egress VCN 1968(1)-(N), which may be contained in a respective customer tenancy 1970(1)-(N). Respective secondary VNICs 1972(1)-(N) may facilitate communications between untrusted application subnet(s) 1962 contained in data plane VCN 1918 and application subnets contained in container egress VCNs 1968(1)-(N). Each container egress VCN 1968(1)-(N) may include a NAT gateway 1938 that may be communicatively coupled to the public Internet 1954 (e.g., Fig.17 of the public Internet 1754).

[0249] An internet gateway 1934 included in control plane VCN 1916 and included in data plane VCN 1918 may be communicatively coupled to a metadata management service 1952 (e.g., Fig.171954) can be communicatively coupled to the public Internet 1954. The public Internet 1954 can be communicatively coupled to the NAT gateway 1938 contained in the control plane VCN 1916 and contained in the data plane VCN 1918. The service gateway 1936 contained in the control plane VCN 1916 and contained in the data plane VCN 1918 can be communicatively coupled to the cloud service 1956.

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

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

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

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

[0254] Fig. 20 2 is a block diagram 2000 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 2002 (e.g., Fig.17 The service operator 1702) can be communicatively coupled to the secure host lease 2004 (e.g., Fig.17 The secure host lease 1704 may include a virtual cloud network (VCN) 2006 (e.g., Fig.17 VCN 1706) and secure host subnet 2008 (e.g., Fig.17 VCN 2006 may include LPG 2010 (e.g., Fig.17 LPG 1710), which LPG 2010 can be included in the SSH VCN 2012 (for example, Fig.17The LPG 2010 in the SSH VCN 1712 of the embodiment is communicatively coupled to the SSH VCN 2012. The SSH VCN 2012 may include an SSH subnet 2014 (e.g., Fig.17 SSH subnet 1714), and SSH VCN 2012 can be communicatively coupled to control plane VCN 2016 via LPG 2010 contained in control plane VCN 2016 (e.g., Fig.17 The control plane VCN 1716 of the data plane VCN 2018 is coupled to the data plane VCN 2018 via the LPG 2010 contained in the data plane VCN 2018 (e.g., Fig.17 The control plane VCN 2016 and the data plane VCN 2018 may be included in a service lease 2019 (e.g., Fig.17 Service lease 1719).

[0255] The control plane VCN 2016 may include a LB subnet 2022 (e.g., Fig.17 LB subnet(s) 1722) of the control plane DMZ layer 2020 (e.g., Fig.17 control plane DMZ layer 1720), may include (one or more) application subnets 2026 (e.g., Fig.17 (one or more) application subnets 1726) of the control plane application layer 2024 (e.g., Fig.17 The control plane application layer 1724 of the embodiment of the present invention may include (one or more) DB subnets 2030 (e.g., Fig.19 (one or more) DB subnets 1930) of the control plane data layer 2028 (e.g., Fig.17 The LB subnet(s) 2022 contained in the control plane DMZ layer 2020 may be communicatively coupled to the application subnet(s) 2026 contained in the control plane application layer 2024 and the Internet gateway 2034 (e.g., Fig.17 1734), and the application subnet(s) 2026 may be communicatively coupled to the DB subnet(s) 2030 and the service gateway 2036 (e.g., Fig.17 ) and a network address translation (NAT) gateway 2038 (e.g., Fig.17 NAT gateway 1738). The control plane VCN 2016 may include a service gateway 2036 and a NAT gateway 2038.

[0256] The data plane VCN 2018 may include a data plane application layer 2046 (e.g., Fig.17 Data plane application layer 1746), data plane DMZ layer 2048 (e.g., Fig.17 Data plane DMZ layer 1748)), and data plane data layer 2050 (e.g., Fig.17 The data plane DMZ layer 2048 may include (one or more) trusted application subnets 2060 (e.g., Fig.19 (one or more) trusted application subnets 1960) and (one or more) untrusted application subnets 2062 (e.g., Fig.19 The (one or more) untrusted application subnets 1962) and the (one or more) LB subnets 2022 of the Internet gateway 2034 included in the data plane VCN 2018. The (one or more) trusted application subnets 2060 can be communicatively coupled to the service gateway 2036 included in the data plane VCN 2018, the NAT gateway 2038 included in the data plane VCN 2018, and the (one or more) DB subnets 2030 included in the data plane data layer 2050. The (one or more) untrusted application subnets 2062 can be communicatively coupled to the service gateway 2036 included in the data plane VCN 2018 and the (one or more) DB subnets 2030 included in the data plane data layer 2050. The data plane data layer 2050 can include the (one or more) DB subnets 2030 that can be communicatively coupled to the service gateway 2036 included in the data plane VCN 2018.

[0257] The untrusted application subnet(s) 2062 may include primary VNICs 2064(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 2066(1)-(N) residing within the untrusted application subnet(s) 2062. Each tenant VM 2066(1)-(N) may run code in a corresponding container 2067(1)-(N) and may be communicatively coupled to an application subnet 2026 that may be included in a data plane application layer 2046 included in a container egress VCN 2068. Corresponding secondary VNICs 2072(1)-(N) may facilitate communications between the untrusted application subnet(s) 2062 included in the data plane VCN 2018 and the application subnets included in the container egress VCN 2068. The container egress VCN may include a primary VNIC that may be communicatively coupled to the public Internet 2054 (e.g., Fig.17 NAT gateway 2038 of the public Internet 1754).

[0258] The Internet gateway 2034 included in the control plane VCN 2016 and included in the data plane VCN 2018 can be communicatively coupled to the metadata management service 2052 (e.g., Fig.17 The metadata management system 1752 of the embodiment of the present invention can be communicatively coupled to the public Internet 2054. The public Internet 2054 can be communicatively coupled to the NAT gateway 2038 contained in the control plane VCN 2016 and contained in the data plane VCN 2018. The service gateway 2036 contained in the control plane VCN 2016 and contained in the data plane VCN 2018 can be communicatively coupled to the cloud service 2056.

[0259] In some examples, Fig. 20 The architecture model shown in the block diagram 2000 can be considered as Fig.19 1900 , and may be desired by customers of the IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer may have real-time access to the corresponding container 2067(1)-(N) contained in each customer's VM 2066(1)-(N). The container 2067(1)-(N) may be configured to make calls to the corresponding secondary VNIC 2072(1)-(N) contained in the (one or more) application subnets 2026 of the data plane application layer 2046, which may be contained in the container egress VCN 2068. The secondary VNIC 2072(1)-(N) may transmit the call to the NAT gateway 2038, which may transmit the call to the public Internet 2054. In this example, containers 2067(1)-(N), which may be accessed by customers in real time, may be isolated from control plane VCN 2016 and may be isolated from other entities contained in data plane VCN 2018. Containers 2067(1)-(N) may also be isolated from resources from other customers.

[0260] In other examples, a customer may use containers 2067(1)-(N) to call cloud service 2056. In this example, a customer may run code in containers 2067(1)-(N) to request a service from cloud service 2056. Containers 2067(1)-(N) may transmit the request to secondary VNICs 2072(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 2054. Public Internet 2054 may transmit the request to LB subnet(s) 2022 contained in control plane VCN 2016 via Internet gateway 2034. In response to determining that the request is valid, LB subnet(s) may transmit the request to application subnet(s) 2026, which may transmit the request to cloud service 2056 via service gateway 2036.

[0261] It should be appreciated that the IaaS architectures 1700, 1800, 1900, 2000 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.

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

[0263] Fig.21 An example computer system 2100 in which various embodiments may be implemented is illustrated. System 2100 may be used to implement any of the computer systems described above. As shown, computer system 2100 includes a processing unit 2104 that communicates with multiple peripheral subsystems via a bus subsystem 2102. These peripheral subsystems may include a processing acceleration unit 2106, an I / O subsystem 2108, a storage subsystem 2118, and a communication subsystem 2124. Storage subsystem 2118 includes a tangible computer-readable storage medium 2122 and a system memory 2110.

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

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

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

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

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

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

[0270] The computer system 2100 may include a storage subsystem 2118 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. The software may include programs, code modules, instructions, scripts, etc., which, when executed by one or more cores or processors of the processing unit 2104, provide the above-described functionality. The storage subsystem 2118 may also provide a repository for storing data used in accordance with the present disclosure.

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

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

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

[0274] Computer-readable storage media 2122 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 2100 (including instructions executable by processing unit 2104 of computer system 2100).

[0275] Computer readable storage media 2122 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.

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

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

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

[0279] In some embodiments, the communication subsystem 2124 may also receive input communications in the form of structured and / or unstructured data feeds 2126 , event streams 2128 , event updates 2130 , and the like on behalf of one or more users who may use the computer system 2100 .

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

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

[0282] The communication subsystem 2124 may also be configured to output structured and / or unstructured data feeds 2126, event streams 2128, event updates 2130, 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 2100.

[0283] Computer system 2100 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.

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

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

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

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

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

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

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

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

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

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

Claims

1. A method comprising: generating, by the computing system, a first security key associated with a source file system based at least in part on the first master key for use in encrypting and decrypting a plurality of file keys in the source file system, the source file system being configured to send snapshot deltas during a replication process, the snapshot deltas being identified between two snapshots of the source file system; generating, by the computing system, a second security key associated with the target file system based at least in part on the second master key for use in encrypting and decrypting a plurality of file keys in the target file system, the target file system being configured to receive snapshot deltas during a replication process; as well as generating, by the computing system, a session key based at least in part on the third master key, for use in encrypting and decrypting snapshot increments transmitted between the source file system and the target file system during the replication process, the session key being valid for the session; The first master key, the second master key and the third master key are different keys.

2. The method of claim 1, wherein the session is a duration between a start of a copy process in a source file system and an end of the copy process in a target file system.

3. A method as claimed in claim 1 or claim 2, wherein the snapshot increment transmitted between the source file system and the target file system also includes an object storage device, which is configured to receive the snapshot increment from the source file system and forward the snapshot increment to the target file system.

4. The method of claim 3 further comprises encrypting the snapshot increment using a session key before transmitting the snapshot increment to the object storage device, and decrypting the snapshot increment using the session key after transmitting the snapshot increment to the target file system.

5. The method of any one of claims 1 to 4, further comprising transmitting a session key from a control plane of the source file system to a control plane of the target file system.

6. The method of any one of claims 1 to 5, wherein the session key is associated with a globally unique resource identifier.

7. The method of claim 1 , wherein each of the plurality of file keys in the source file system is associated with a specific file in the source file system and is used to encrypt and decrypt file data of the specific file in the source file system, and each of the plurality of file keys in the target file system is associated with a specific file in the target file system and is used to encrypt and decrypt file data of the specific file in the target file system.

8. The method according to any one of claims 1 to 7, further comprising: authenticating a key requester in the source file system who requests to use the first security key; as well as A key requester requesting to use the second security key in the target file system is authenticated.

9. The method of claim 8, wherein authenticating the key requester in the source file system comprises checking an identification number of the replication process and an identification number of the source file system.

10. A non-transitory computer-readable medium storing computer-executable instructions, which, when executed by one or more processors, cause the one or more processors to perform operations comprising: generating, by the computing system, a first security key associated with a source file system based at least in part on the first master key for use in encrypting and decrypting a plurality of file keys in the source file system, the source file system being configured to send snapshot deltas during a replication process, the snapshot deltas being identified between two snapshots of the source file system; generating, by the computing system, a second security key associated with the target file system based at least in part on the second master key for use in encrypting and decrypting a plurality of file keys in the target file system, the target file system being configured to receive snapshot deltas during a replication process; as well as generating, by the computing system, a session key based at least in part on the third master key, for use in encrypting and decrypting snapshot increments transmitted between the source file system and the target file system during the replication process, the session key being valid for the session; The first master key, the second master key and the third master key are different keys.

11. The non-transitory computer readable medium of claim 10, wherein the session is a duration between a start of a copy process in a source file system and an end of the copy process in a target file system.

12. A non-transitory computer-readable medium as described in claim 10 or claim 11, wherein the snapshot increment transmitted between the source file system and the target file system also includes an object storage device, which is configured to receive the snapshot increment from the source file system and forward the snapshot increment to the target file system.

13. The non-transitory computer-readable medium of any one of claims 10 to 12, further comprising encrypting the snapshot increment using a session key before transmitting the snapshot increment to the object storage device, and decrypting the snapshot increment using the session key after transmitting the snapshot increment to the target file system.

14. The non-transitory computer-readable medium of any one of claims 10 to 13, further comprising transmitting the session key from a control plane of the source file system to a control plane of the target file system.

15. The non-transitory computer-readable medium of any one of claims 10 to 14, wherein each of the plurality of file keys in the source file system is associated with a specific file in the source file system and is used to encrypt and decrypt file data of the specific file in the source file system, and each of the plurality of file keys in the target file system is associated with a specific file in the target file system to be used to encrypt and decrypt file data of the specific file in the target file system.

16. A system comprising: one or more processors; as well as One or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the system to perform: generating, by the computing system, a first security key associated with a source file system based at least in part on the first master key for use in encrypting and decrypting a plurality of file keys in the source file system, the source file system being configured to send snapshot deltas during a replication process, the snapshot deltas being identified between two snapshots of the source file system; generating, by the computing system, a second security key associated with the target file system based at least in part on the second master key for use in encrypting and decrypting a plurality of file keys in the target file system, the target file system being configured to receive snapshot deltas during a replication process; as well as generating, by the computing system, a session key based at least in part on the third master key, for use in encrypting and decrypting snapshot increments transmitted between the source file system and the target file system during the replication process, the session key being valid for the session; The first master key, the second master key and the third master key are different keys.

17. The system of claim 16, wherein the session is a duration between a start of a copy process in a source file system and an end of the copy process in a target file system.

18. A system as claimed in claim 16 or claim 17, wherein the session key is associated with a globally unique resource identifier.

19. The system of any one of claims 16 to 18, further comprising: authenticating a key requester in the source file system who requests to use the first security key; as well as A key requester requesting to use the second security key in the target file system is authenticated.

20. The system of claim 19, wherein authenticating the key requester in the source file system comprises checking an identification number of the replication process and an identification number of the source file system.

Images