Zone segment drive management

Abstract

To provide a method, system and computer readable medium for managing data storage in a distributed storage system.SOLUTION: A method performed by a computer system includes receiving 310 a request to write data to a volume and identifying 330 a zone segment mapped to the volume. The zone segment includes a plurality of zones. The method also includes identifying 340 a segment pointer that indicates a write location within a zone of the zone segment, writing 350 the data to one or more zones of the plurality of zones of the zone segment starting from the write location, and updating 360 the segment pointer according to an end of the data within the zone segment.SELECTED DRAWING: Figure 3

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. Non-Provisional Patent Application No. 17 / 229,709, entitled "ZONE SEGMENT DRIVE MANAGEMENT," filed April 13, 2021. The contents of U.S. Non-Provisional Patent Application No. 17 / 229,709 are incorporated by reference herein in their entirety for all purposes.

[0002] background Cloud-based platforms provide scalable and flexible computing resources for user data. Such cloud-based platforms, also known as infrastructure as a service (IaaS), The platform may offer a full suite of cloud solutions around a customer's data, for example solutions for authoring transformations, loading data, and presenting data. Summary of the Invention [Problem to be solved by the invention]

[0003] Shingled Magnetic Recording (SMR) is a method of recording data by dividing a recording track into parts. Hard disks are stacked or shingled together. This increases the storage capacity on a disk drive. Overlapping tracks can be grouped into zones. By tiling the tracks in such a way that the read path is preserved, tracks can still be read even if they are partially overwritten. In contrast, as a result of tiling, read operations can still be performed randomly within a zone, but write operations must be applied consecutively to the entire zone rather than to a range within the zone.

[0004] overview Techniques (e.g., methods, systems, non-transitory computer-readable media storing code or instructions executable by one or more processors) are provided for managing object storage of cloud resource data on a single magnetic recording drive. [Means for solving the problem]

[0005] In an embodiment, a method may include receiving, by a computer system, a request to write data to a volume. The method may include identifying, by the computer system, a zone segment mapped to the volume. The zone segment may include multiple zones. The method may include identifying, by the computer system, a segment pointer that indicates a write location within a zone of the zone segment. The method may include writing, by the computer system, the data to one or more zones of the multiple zones of the zone segment starting from the write location. The method may also include updating, by the computer system, the segment pointer according to an end point of the data within the zone segment.

[0006] In some embodiments, the method may further include verifying a size of the data identified in the request. The method may include verifying a capacity of the zone, the capacity corresponding to a write path between the write location and an end of the zone. The method may include comparing the capacity of the zone with a size of the data. The method may further include dividing the data into a first block and a second block in response to the size of the data exceeding the capacity of the zone. The method may include dividing the first block into blocks. A size of the first block may correspond to a capacity of the zone. The method may include writing the first block starting from a write location. The method may also include writing the second block to a subsequent zone of the zone segment.

[0007] In some embodiments, updating the segment pointer may include marking the zone segment as a full zone segment in response to the end of the data in the zone segment matching the capacity of the zone segment. Updating the segment pointer may also include identifying a new zone segment mapped to the volume and updating the segment pointer to the start of the new zone segment. Identifying the segment pointer may include scanning the zone segments mapped to the volume for empty or open zones.

[0008] In some embodiments, a computer system includes one or more processors and a memory in communication with the one or more processors, the memory configured to store computer-executable instructions, and executing the computer-executable instructions causes the one or more processors to perform one or more steps of the above-described method or variations thereof. Identifying the segment pointer may further include assigning a new zone segment to the volume in response to the zone segments mapped to the volume not including an empty or open zone. The segment pointer may be a starting location of a first zone of the new zone segment.

[0009] In some embodiments, the method may include verifying a usage percentage of a zone segment. The method may include comparing the usage percentage to a usage threshold. The method may include, in response to the usage percentage not satisfying the usage threshold, identifying stored data in multiple zones of the zone segment, mapping the stored data from one or more source zones to one or more empty or open zones of the multiple zones, writing the stored data to the empty or open zones, and resetting the source zone to an open status. Identifying the stored data in the multiple zones may include receiving mapping metadata describing a mapping of the zone segment to the volume, and locating the stored data in the multiple zones in accordance with the mapping metadata.

[0010] In some embodiments, multiple zones may be implemented in a single magnetic recording storage system.

[0011] In one embodiment, a computer system includes one or more processors and non-transitory computer-readable memory that stores instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more operations of a method described above or variations thereof.

[0012] In one embodiment, a computer-readable storage medium stores computer-executable instructions that, when executed, cause one or more processors of a computer system to perform one or more operations of the method described above or variations thereof. [Brief explanation of the drawings]

[0013] [Figure 1] 1 illustrates an exemplary system for managing object storage servers, according to one or more embodiments. [Figure 2] 1 illustrates an exemplary shingled magnetic recording drive in accordance with one or more embodiments. [Figure 3] 1 illustrates an exemplary flow for writing object data to a zone segment in accordance with one or more embodiments. [Figure 4] 10 illustrates an exemplary flow for reading data from a zone segment in accordance with one or more embodiments. [Figure 5] 1 illustrates an example flow for deleting data from a zone segment according to one or more embodiments. [Figure 6] 1 illustrates an exemplary flow for defragmenting a zone segment, according to one or more embodiments. [Figure 7] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 8] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure-as-a-service system in accordance with at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] Detailed Description In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Additionally, well-known features may be omitted or simplified so as not to obscure the embodiments being described.

[0015] Cloud-based platforms provide scalable and flexible computing resources for users. Also referred to as Infrastructure as a Service (IaaS), these cloud-based platforms can offer a complete suite of cloud solutions for customers' data, such as solutions for transform authoring, data loading, and data presentation. In data replication and backup systems, which may be part of back-end data storage systems, shingled magnetic recording (SMR) drives can increase the storage capacity of data storage systems. SMR drives partially overlap, or tile, recording tracks, allowing more tracks to be written to a given size of hard disk. Overlapping tracks can be organized into zone segments, or grouped into zones. By tiling tracks in a way that preserves read paths, tracks can still be read even if they are partially overwritten. In contrast, as a result of the tiled arrangement, write operations can be applied in an append-only process, where partially overwritten data can be read but not overwritten. Therefore, access to an SMR drive may be provided through a block interface rather than a file system, as described below, due to the additional operations involved in writing to an SMR drive.

[0016] In a distributed storage system, user data may be stored in volume storage (e.g., block volume storage) and in object storage. Users may interact directly with the volume storage system, while a back-end storage subsystem of a database system may use the object storage for, for example, data replication, backup, or other data storage (e.g., to supplement database system capacity). The implementation of SMR drives in a data replication or backup system reduces the relative complexity of writing and rewriting data to the SMR drives. As described in more detail with reference to FIG. 2, organizing partially overwritten tracks within a zone can cause inefficiencies when a system attempts to write data to a zone that exceeds the available capacity of the zone. For example, in a conventional SMR drive, the system may reject a request to write data to a zone that exceeds the capacity of the zone. To address this constraint, zones may be organized into zone segments, and a system managing data storage may address write requests to zone segments rather than individual zones. In this manner, a write location within a zone segment may be identified, and data referenced by a write request may be written across multiple zones within a zone segment.

[0017] In some examples, block storage is often used where fast, efficient, and reliable data transport is desired. Block storage divides data into blocks and can store those blocks as separate pieces (e.g., each block has its own identifier). The blocks can then be stored across different systems, and each block can be configured to work with different systems (e.g., partitioned). Alternatively, object storage divides data files into pieces (e.g., objects) and then stores them in a single repository that can be scattered across multiple networked systems. In the context of block storage, a volume (e.g., a block volume) can be a removable block storage device (e.g., physically or virtually) that allows developers to dynamically expand the storage capacity of an instance. To increase or decrease the size of block volume storage, block volumes can be spun up or down, respectively, without much effort. If a database system implements both volume storage and object storage, I / O requests can reference data by a volume identifier (e.g., a block volume identifier). A volume identifier may be mapped to a storage location within the object storage system through volume metadata stored in a metadata database included as part of the database system. In the case of a write request, the database system may identify a zone segment within the SMR system that stores data mapped to the volume referenced in the write request. Once identified, the database system may identify a zone segment pointer that describes a write location within a zone contained within the zone segment where the new data can be written. Rather than overwriting the zone, the SMR system may write to the zone, split the data into blocks to be written across multiple zones, or, if a zone with capacity to store the data is not available, decline the request or allocate a new zone segment to store the spilled data.In this way, the SMR system can write data to hard disk drives in a manner that increases the effective capacity of the object storage system through the use of SMR storage, while mitigating the impact of zone write failures caused by data size exceeding zone capacity. In a similar manner, read, delete, and defragmentation techniques can also be implemented using the SMR system with reference to volume metadata mapped to data stored within zone segments.

[0018] In an illustrative example, a database system may be configured to store cloud resource data as part of a distributed storage system. The database system may include an SMR system. The SMR system may include an SMR storage server in communication with one or more SMR database systems, which may be or include hard disk drives configured for SMR storage using zones organized within zone segments. In this example, the system receives write requests (also referred to as "put" requests), read requests, and write requests. Read requests (also known as "get" requests), and, without limitation, delete requests or other I / O processes, including defragmentation operations. As part of the SMR configuration, I / O requests can cause the database system to implement improved processes to identify and manage data stored within the SMR system within zone segments.

[0019] The process of performing I / O processes with back-end storage subsystems improves the overall performance of data replication, storage, and backup systems, at least because it enables efficient I / O from SMR-configured storage systems. For example, an SMR system may provide a storage capacity increase of 25% or more without adding hard disk drives to the system by at least partially tiling previously written magnetic tracks. Organizing SMR zones into zone segments may improve I / O processes by enabling improvements in the speed, efficiency, and success rate of fulfilling I / O requests made to SMR drives. Furthermore, by managing zone drives as described with reference to the following figures, a database system may reduce system complexity by enabling the database system to use host-managed drives controlled by a unified block interface that references volume metadata for mapping object data to volume data.

[0020] 1 illustrates an exemplary system 100 for managing object storage servers according to one or more embodiments. Database system 100 may be configured to distribute and store user data across multiple storage systems, which may implement various magnetic recording technologies (e.g., perpendicular magnetic recording (PMR), SMR, or the like), as part of a back-end data storage subsystem. In this manner, database system 100 may serve I / O requests for data stored within object storage as part of data replication, restoring volume data to a block volume system, or defragmenting an SMR system that organizes zones into zone segments as an approach to facilitate improved I / O operations in a distributed data storage system.

[0021] In some embodiments, system 100 may include a load balancer 110 that may be configured to receive I / O requests 120 and send I / O requests 120 to web servers 130. Load balancer 110 may distribute I / O requests across multiple web servers 130 as part of a distributed storage system that may be located in multiple different physical locations and / or may include multiple web servers 130 at a single physical location. Similarly, web servers 130 may communicate with one or more storage systems 140. Storage systems 140 may be configured to store data in a PMR or SMR configuration. For example, storage system 140 may include a storage server 142 that communicates with one or more PMR drives 144. Additionally, web servers 130 may communicate with a storage system that includes an SMR storage server 146 that communicates with one or more SMR drives 148, as described in more detail with reference to FIG. 2. System 100 may be configured to execute I / O requests 120 to data stored within SMR drives 148, for example, through the execution of software by SMR storage server 146.

[0022] System 100 may map data stored in storage system 140 to volume data by referencing volume service 150. Thus, I / O request 120 may include a reference to a volume identifier, which may be mapped to a location in storage of storage system 140 in volume metadata database 160. In one example, a read request may include a volume identifier, a segment pointer, and a zone identifier, which may be mapped to a zone segment in an entry in volume metadata database 160. The printer and read size may be referenced.

[0023] In this manner, system 100 may manage SMR drives 148 as part of a distributed data storage system. Advantageously, system 100 may enable back-end data storage subsystems to benefit from the increased storage capacity of SMR drives 148 while maintaining integration with front-end block volume systems. As described in more detail with reference to FIGS. 3-6 , database system 100 may receive I / O requests 120, for example, as part of data replication or backup, and may fulfill I / O requests 120 by reading, writing, or defragmenting PMR drives 144 and / or SMR drives 148.

[0024] 2 shows an exemplary shingled magnetic recording SMR drive 200 according to one or more embodiments. The physical processes and data structures of the SMR drive 200 are based on overwriting magnetic tracks 210 on the disks of the SMR drive 200. In PMR drives, magnetic tracks are not overwritten. Therefore, data stored in a PMR drive can be randomly accessed (e.g., a PMR drive can be used as random-access hard drive storage). In contrast, SMR drives, which can write data by appending rather than randomly accessing it, are typically configured to efficiently read data that is unlikely to be changed.

[0025] Data in an SMR drive 200 may be stored using a block system, rather than a file system, as part of a write-only I / O system. Therefore, data blocks may be written to fixed-size (e.g., 256 MB) zones 220, which may be organized into zone segments 230. Physically, each zone may be described by a number of magnetic tracks 210 having a fixed write width 240 that are partially overwritten to provide data tracks 250. The data tracks may be described by a data track pitch 260, which may be a parameter of the SMR drive 200 that depends, for example, on the specifications of the read / write heads 270 of the SMR drive 200. The narrower the data track pitch 260, the greater the overall capacity of the SMR drive 200, limited by factors including the ability of the read / write heads 270 to accurately read the data tracks 250.

[0026] Magnetic tracks 210 are shown to have a fixed width to demonstrate the hierarchical organization of zones 220 and zone segments 230. Rather than indexing data to a single location within a discrete track, as is done in a PMR drive, SMR drive 200 may organize data within zones 220 that extend across multiple magnetic tracks 210 and be indexed by pointers that indicate the start of a zone segment 230, the start of a zone 220, and / or the location within zone 220 where the data should be found. For example, the pointers may include a write pointer that describes the last written location within zone 220 to which a subsequent write operation will append new data.

[0027] In some cases, a zone 220 may be described by one or more statuses that may govern whether data can be written to the zone 220. For example, the status of a zone 220 may be, but is not limited to, "empty," "full," "open," "free," "free space," "space ... The status may include "open," "closed," or "finished." An empty status may indicate that zone 220 can be written from the beginning of magnetic track 210 in zone 220 (e.g., the write pointer for zone 220 is at the beginning of zone 220). Similarly, a full status may indicate that zone 220 is not available for additional write operations (e.g., the write pointer for zone 220 is at or near the end of zone 220). An open status may indicate that zone 220 is not available for additional write operations (e.g., the write pointer for zone 220 is at or near the end of zone 220). A 0 may indicate available for a write operation (e.g., zone 220 has available capacity for writing data to magnetic track 210 of zone 220, and SMR drive 220 has resources allocated to perform the write operation). A closed status, in contrast, may indicate that zone 220 is not available for a write operation but may be released. An ended status may indicate that data will not be written to zone 220 (e.g., the write pointer for zone 220 may be moved to the end of the zone to prevent further write operations). An ended zone may be released by setting zone 220 to an empty status (e.g., by moving the write pointer to the beginning of zone 220).

[0028] Organizing zones 220 into zone segments 230 may allow zones 220 to be managed collectively in such a way that a segment pointer may be defined that describes a write location for a zone segment 230, rather than a write location per zone. Within a zone 220 of a zone segment 230, the zone-specific write location may follow the status described above, while the segment pointer may describe a write location within the first available open zone of the zone segment 230. For example, zones 220 may be organized contiguously within the zone segment 230. In this manner, data may be written in blocks across multiple zones 220 within a zone segment 230. Organizing zones in a contiguous manner may allow the SMR drive 200 to better accommodate write requests that reference data whose length exceeds the capacity of an open zone. The SMR drive 200 may open multiple zones within a zone segment and define multiple write operations based on a single write request. As will be described in more detail below with reference to FIG. 3, a write operation may be performed by identifying a segment pointer that indicates where to begin writing data within zone 220 of zone segment 230.

[0029] FIG. 3 illustrates an exemplary flow 300 for writing object data to a zone segment, according to one or more embodiments. The operations of the flow may be implemented as hardware circuitry and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as system 100 of FIG. 1. When implemented, the instructions represent circuitry or modules containing code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform specific operations described herein. Each circuitry or code in combination with the processor performs a respective operation. While the operations are shown in a particular order, it should be understood that this particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0030] In one example, flow 300 includes operation 310, in which a computer system receives a write request. The write request (e.g., I / O request 120 of FIG. 1 ) may be received from a distributed data storage system that manages data replication, archiving, or other storage, for example, based on a user request to store data in object storage rather than in a block volume system. As part of receiving the write request, the computer system may forward the request to other networked systems (e.g., as part of an IaaS infrastructure system), as described in more detail with reference to FIG. 1 . For example, the write request may be forwarded to a web server (e.g., web server 130 of FIG. 1 ), which may select a storage server (e.g., SMR storage server 146 of FIG. 1 ) to process the write request.

[0031] In one example, flow 300 optionally includes operation 320 in which the computer system scans the zone segment for empty or open zones. A zone segment may include a chunk of data, where a chunk is a block of data to be written to a zone segment (e.g., zone segment 230 in FIG. 2). As described in more detail with reference to FIG. 2, a zone segment may include multiple zones (e.g., zone 220 in FIG. 2) that provide a storage capacity equivalent to an integer multiple of the capacity of the zone. One or more zones within a zone segment may be empty or open and therefore available for write operations. Zones may be organized contiguously within a zone segment, such that an open zone may be followed by an empty zone. It should be understood that an empty zone does not necessarily refer to a zone where nothing is recorded on the magnetic track, but rather may refer to a zone where the write position for the zone is at the beginning of the zone.

[0032] In one example, flow 300 optionally includes operation 330, in which the computer system assigns a new zone segment to the volume. In some cases, scanning the zone segments may not identify an empty or open zone before the terminating zone of the zone segment. In some embodiments, the system may assign a new zone segment to a volume referenced in a write request (e.g., by volume identifier) ​​to increase the capacity available for writing data for the referenced volume. The new zone segment may be allocated from a free pool of zone segments maintained for the purpose of reducing the percentage of write requests that are rejected due to lack of capacity. In some embodiments, the new zone segment may be allocated from the same SMR drive that stores the zone segment or from a different SMR drive coordinated through an SMR storage server (e.g., SMR storage server 146 of FIG. 1 ).

[0033] In one example, flow 300 includes operation 340, in which a computer system identifies a segment pointer. Within a zone segment (or a new zone segment), the system may identify the segment pointer by locating the first zone in the zone segment that is described by an open or empty status. For example, if the zones are organized contiguously within the zone segment, the segment pointer may correspond to the write location of the first open zone. In another example, if the zone segment does not include an open zone, the segment pointer may correspond to the start location of the first empty zone.

[0034] In one example, flow 300 includes operation 350, in which a computer system writes data to a zone of a zone segment according to a segment pointer. Starting from the segment pointer, the system may write data referenced by a write request to the zone corresponding to the segment pointer. The write operation may include an initial check by the system whether the zone corresponding to the segment pointer has capacity for the entire chunk referenced by the write request. If the zone has insufficient capacity, the system may define multiple blocks, thereby allowing the chunk to be divided across multiple zones of the zone segment. In an illustrative example, the zones of the zone segment may be organized contiguously, and the chunk may be divided into a first block and a second block in such a way that the size of the first block corresponds to the write capacity of the zone corresponding to the segment pointer. The first block may be written starting from the segment pointer, and the second block may be written to the next zone. Although this example describes contiguous zones, method 300 may be implemented using other approaches.

[0035] In one example, flow 300 includes operation 360, in which the computer system updates a segment pointer. After completion of a write operation, which may include multiple write operations in which data is written to multiple zones, the system may define the segment pointer to the end location of the data. In this manner, the updated segment pointer may point to a write location within a different zone of the zone segment relative to the zone corresponding to the segment pointer before receiving the write request. It can correspond to the position.

[0036] In one example, flow 300 includes operation 370, in which the computer system updates the volume metadata. As described in more detail with reference to FIG. 1, data written to a zone segment may be mapped to a block volume through the volume metadata. The volume metadata may include segment pointers, and therefore, updating the volume metadata may include updating the segment pointers in a volume metadata database (e.g., volume metadata database 160 of FIG. 1) and, if a new zone segment is allocated, updating the volume-zone segment mapping as part of operations 320 and 330. In some examples, the volume metadata may store a starting location pointer where the data was written, which corresponds to the segment pointer value before the pointer was updated in operation 360.

[0037] In one example, flow 300 includes operation 380, in which the computer system outputs the status of the write request. In some embodiments, the system may be configured to output a variety of different types of status reports. For example, resource metadata, such as usage and capacity data, may be collected and managed as part of improving IaaS system operations. As another example, the success or failure of the write request may be returned to the system, which may cause the system to repeat some or all of the operations of method 300. As another example, if the write request originated from a human user, the system may output the status to a user of an IaaS console interface.

[0038] The organization of zone segments can provide significant technical improvements for the operation of database systems incorporating SMR drives. By implementing write techniques to zone segments containing multiple zones, data can be written across zones, allowing the capacity of multiple zones to be shared. In this way, data replication, storage, and backup operations, facilitated by volume metadata mapped to zone segment pointers, can improve the efficiency of SMR write and re / write operations.

[0039] FIG. 4 illustrates an exemplary flow 400 for reading data from a zone segment, according to one or more embodiments. The operations of the flow may be implemented as hardware circuitry and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as system 100 of FIG. 1. When implemented, the instructions represent circuitry or modules containing code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform specific operations described herein. Each circuitry or code in combination with the processor performs a respective operation. While the operations are shown in a particular order, it should be understood that this particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0040] In one example, flow 400 includes operation 410, in which a computer system receives a read request. As described in more detail with reference to FIG. 1 , the read request may reference a volume and a data block to be read. The volume may be referenced by a volume identifier and a block identifier, which may be mapped to an SMR drive in volume metadata. The SMR drive may define zone segments that include zones, which may be organized contiguously within the zone segment. In this manner, the system may receive a read request as part of a data access operation, e.g., as part of a data recovery process, and may be configured to access multiple zones of a zone segment to read data.

[0041] In one example, flow 400 includes operation 420, in which the computer system identifies a stored pointer and read length stored in the volume metadata (e.g., when updating the volume metadata at 370 in FIG. 3). The stored pointer and read length may correspond to a volume identified in the read request. The volume identifier may be mapped to a zone segment and to a zone of the zone segment by the stored pointer. In contrast to the method described with reference to FIG. 3, the stored pointer in flow 400 may reference a read location rather than a write location. Nevertheless, it may be understood to similarly reference a starting location within the zone segment for the SMR drive to read data.

[0042] The read request may also include a reference to the data to be read, which may be mapped to a read length on the SMR drive. The read length may correspond to a dimension or length of the track to be read (e.g., data track 250 of FIG. 2), allowing the system to determine whether the read length overlaps multiple zones within a zone segment. For example, if the zones are organized contiguously within the zone segment, the system may indicate a first read position at the segment pointer and a second read position at the start of the next zone within the zone segment.

[0043] In one example, flow 400 optionally includes operation 430, in which the computer system determines a single read command for each zone in the zone segment. If the read length extends across multiple zones, starting from the segment pointer identified in operation 420, the system may determine multiple read commands for different zones of the zone segment. The multiple single read commands may be cross-referenced, so that data returned by the read commands may be reconstructed according to the read length determined in operation 420. In this way, data written across multiple zones may be read with a single read request that references the zone segment, rather than multiple read requests serviced at individual zones.

[0044] In one example, flow 400 includes operation 440, in which a computer system issues a read command to an SMR drive. As described in more detail with reference to FIG. 1, the system may manage data storage through a storage server (e.g., storage server 142 or SMR server 146 of FIG. 1). The read command may include the segment pointer and read length determined in operation 420, and the system may issue the read command to an SMR storage server referenced by mapping metadata, such as volume metadata, as described in more detail with reference to FIG. 1.

[0045] In one example, flow 400 includes operation 450, in which the computer system outputs the read data and the status of the read request. Outputting the data may include communicating the data from the SMR drive to the destination referenced in the read request. For example, the system may output the data to a volume storage system or from one object storage drive to another as part of a data replication operation. As with flow 300, the status may include success / failure information for the request as well as other information, including, but not limited to, metadata describing the data and zones referenced in the read command.

[0046] Expediting read commands using the operations of flow 400 can result in significant technical improvements for the operation of database systems incorporating SMR drives. By implementing techniques that service read requests serviced in multiple zones organized into zone segments, data can be more efficiently read from SMR drives without multiple read requests generated for each zone within a zone segment.

[0047] FIG. 5 illustrates an example flow 500 for deleting data from a zone segment, according to one or more embodiments. The operations of the flow may be implemented as hardware circuitry and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as system 100 of FIG. 1. When implemented, the instructions represent circuitry or modules containing code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform specific operations described herein. Each circuitry or code in combination with the processor performs a respective operation. While the operations are shown in a particular order, it should be understood that this particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0048] In one example, flow 500 includes operation 510, in which a computer system receives a delete request. In contrast to a read or write operation, a delete operation may proceed without referencing a segment pointer as a starting location. Instead, the delete request may include volume identifier information that may be mapped to object storage in one or more drives, such as an SMR drive (e.g., SMR drive 200 of FIG. 2) as described in more detail with reference to FIG. 2.

[0049] In one example, flow 500 includes operation 520, in which a computer system reads mapping metadata for a volume object. As described in more detail with reference to FIG. 1, the mapping metadata may reference zone segments that store data for the block volume that is the subject of the delete request. In this manner, the system may identify the zone segment or zone segments assigned to the volume identified in the delete request by referencing the mapping metadata.

[0050] In one example, flow 500 includes operation 530, in which the computer system updates the state of the volume object. Updating the state of the volume object may include, without limitation, sending an instruction to a storage server (e.g., SMR storage server 146 of FIG. 1) to change the status of a zone contained within the assigned zone segment from “full” or “open” to “empty” so that the segment pointer corresponds to the start of the first zone within the zone segment for subsequent write requests. Additionally or alternatively, the system may modify volume metadata in a volume metadata database (e.g., volume metadata database 160 of FIG. 1) and remove the mapping information so that a volume identifier contained within a subsequent I / O request (e.g., I / O request 120 of FIG. 1) is not associated with a zone segment within the SMR drive. For example, in the operations of flow 300 described with reference to FIG. 3, identifying a segment pointer may return that a zone segment is not assigned to the referenced volume identifier. In this manner, a delete request may be addressed for the zone portion of the zone segment. Rather than erasing the entire zone, this may allow an SMR drive to operate more similarly to a random access drive rather than a write-once only drive, except that write requests cannot write to a partially overwritten track.

[0051] In one example, flow 500 includes operation 540, in which the computer system outputs the status of the delete request. As with the previous flows in Figures 3-4, the system may return the status of the delete request to, for example, a central metadata management system, to indicate that the resources addressed by the delete request have been released. Additionally, or alternatively, the system may return a status, success / failure message to the originator of the delete request to indicate whether the request should be resent or will be retried.

[0052] FIG. 6 illustrates an example flow 600 for defragmenting zone segments, according to one or more embodiments. The operations of the flow may be implemented as hardware circuitry and / or stored as computer-readable instructions on a non-transitory computer-readable medium of a computer system, such as system 100 of FIG. 1. When implemented, the instructions represent circuitry or modules containing code executable by a processor of the computer system. Execution of such instructions configures the computer system to perform specific operations described herein. Each circuitry or code in combination with the processor performs a respective operation. While the operations are shown in a particular order, it should be understood that this particular order is not required and one or more operations may be omitted, skipped, and / or reordered.

[0053] In addition to improving read / write operations for SMR drives, in some embodiments, defragmentation operations may also be improved through organizing the zones of an SMR drive into zone segments and remapping data stored within the zones to reduce storage inefficiencies. Advantageously, defragmenting zone segments may allow an SMR drive to function like a random-access drive rather than functioning strictly as an append-only drive, but still be limited to append-only write operations. In an illustrative example, a deletion request may modify mapping metadata rather than data written directly to the drive, as described in more detail with reference to FIG. 5. Over the course of operation, an SMR drive (e.g., SMR drive 200 of FIG. 2) may use fractions of a zone segment's capacity, such as when data that begins in one zone and ends in a subsequent zone of the zone segment is deleted. Because data in overlapping tracks cannot be rewritten in an SMR drive, any remaining unused capacity may become unavailable for write operations, which may result in inefficiencies and underutilization of storage capacity on the SMR drive. Defragmenting an SMR drive may allow the system to free up unused storage capacity by rewriting data into new zones and remapping volume metadata.

[0054] In one example, flow 600 includes operation 610, in which a computer system checks the usage percentage of a zone segment. As part of defragmentation, the system may implement an automatic (e.g., no human intervention) process (e.g., periodic checks of usage percentage, refreshing usage percentage after a deletion request, or the like) based on the usage percentage exceeding a threshold to trigger a defragmentation operation. To that end, the system may access volume metadata to check the usage percentage. The usage percentage may describe the portion of storage capacity within a zone of a zone segment mapped within the volume metadata. For example, the volume metadata may reference a beginning, end, chunk length, or the like for data stored within a zone segment that, in total, only amounts to a portion of the zone segment's total capacity, e.g., based on a zone segment having a fixed capacity.

[0055] In one example, flow 600 includes operation 620, in which the computer system compares the utilization percentage to a utilization threshold. The utilization threshold may be expressed as a utilization percentage. For example, if the system is configured to perform defragmentation when the utilization percentage falls below 50%, the utilization threshold may be expressed as 0.5.

[0056] In one example, flow 600 includes operation 630, in which a computer system identifies data stored within a zone of a zone segment. When a defragmentation process is triggered as a result of the comparison of operation 620, the system uses volume metadata to By scanning the zone segments and / or the zone segments, data to be moved may be identified during defragmentation of the zone segments. While defragmentation of a random access drive may allow some data to be moved while other data remains in place on the drive, write-once-only writing of an SMR drive may involve identifying and remapping data to a new zone and erasing the zone form where the data was copied.

[0057] In one example, flow 600 includes operation 640, in which the computer system maps stored data to an empty or open zone. In some cases, this is a two-part operation, with the first part occurring here in operation 640 (e.g., similar to how the write destination location is determined in operation 340 of FIG. 3 ), and the second part occurring after operation 650 (described below). The mapping data identified in operation 630 may include modifying volume metadata so that data associated with the volume is mapped to a new zone in a zone segment, a newly allocated zone, or buffer storage, which may be a zone segment kept open for use in defragmentation on an SMR drive. Similarly, random access memory may be used for the buffer memory. The remapping may include determining the configuration of the stored data for subsequent writing of the stored data to a zone segment.

[0058] In one example, flow 600 includes operation 650, in which a computer system writes stored data to an empty or open zone. Writing the stored data may include the operations of flow 300, as described in more detail with reference to FIG. 3. For example, the system may send a write command to an SMR storage server (e.g., SMR storage server 146 of FIG. 1) to write the stored data to one or more empty open zones. If the write operation is performed to a zone not reserved for defragmentation, the data may remain where written, and the mapping may be maintained as provided by operation 640.

[0059] In one example, the second part of the two-part operation described above in operation 640 occurs in operation 655 of flow 600 after the data is copied in operation 650. For example, once the data is safe in the new location, the volume metadata is updated (e.g., similar to operation 370 in FIG. 3 ).

[0060] In one example, flow 600 includes operation 660, in which the computer system resets the source zone of the stored data. In addition, the system may reset the source zone of a zone segment for a subsequent I / O operation (e.g., I / O operation 120 of FIG. 1). Resetting the source zone may include updating the status of the zone from "full" to "empty" or other changes to reflect the new configuration of the data within the zone segment.

[0061] In one example, flow 600 optionally includes operation 670, in which the computer system frees the excess zone. As described for operation 330 of flow 300 with reference to FIG. 3, a write operation in which the data to be written exceeds the capacity of the referenced zone segment may include allocating a new zone segment to provide additional storage capacity. In this manner, defragmentation may adjust the data so that it can be stored in a single zone segment by reducing the unused portion of the data capacity within the zone segment. Thus, a zone segment previously used to store data for the zone segment may be freed. In some embodiments, the excess zone is identified as part of the mapping operation of 640 and allocated to a new zone segment as described with reference to operation 650. According to the mapping, the stored data can be written and then released.

[0062] In one example, flow 600 optionally includes operation 680, in which the computer system outputs the status of the defragmentation process. Similar to the output operations of previous Figures 3-5, operation 680 may include reporting the resource usage status to a central database of resource metadata and / or indicating the success / failure of the defragmentation process. In some embodiments, operation 680 may also include confirming the new usage percentage of the zone or resetting a timer or other trigger condition.

[0063] Defragmentation by zone segments can provide significant technical improvements for the operation of database systems incorporating SMR drives. Implementing zone segment defragmentation techniques can improve the efficient use of SMR drive capacity by at least improving the utilization ratio of zone segments, where data can be written across zones of a zone segment. In this way, the constraints imposed by the append-only write operations characteristic of SMR drives can be reduced.

[0064] As mentioned above, Infrastructure as a Service (IaaS) is one 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), or the like). In some cases, an IaaS provider can also provide various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) associated with those infrastructure components. Therefore, these services can be policy-driven, allowing IaaS users to implement policies to drive load balancing to maintain application availability and performance.

[0065] In some cases, IaaS customers may access resources and services through a wide area network (WAN), such as the Internet, The remaining elements of the application stack can be installed using the cloud provider's services. For example, a user logs into an IaaS platform, creates a virtual machine (VM), and installs an operating system (OS). system) on each VM and deploy middleware such as databases. They can create storage buckets for workloads and backups, and even install enterprise software within the VMs. Customers 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, etc.

[0066] In most cases, the cloud computing model will require the involvement of a cloud provider, which can be, but need not be, a third-party service that specializes in supplying (e.g., providing, renting, selling) IaaS. An entity could also choose to deploy a private cloud and become its own provider of infrastructure services.

[0067] In some cases, IaaS deployment is the process of putting a new application, or a new version of an application, onto a prepared application server or similar. It also prepares the server (e.g., by adding libraries, demos, etc.). This may include the process of installing the underlying infrastructure (e.g., installing applications, etc.), which is often managed below the hypervisor layer by the cloud provider (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may be responsible for handling the (OS), middleware, and / or application deployment (e.g., on top of self-service virtual machines (e.g., which may be spun up on demand), or the like).

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

[0069] In some cases, there are two distinct problems for IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before any of it is running. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) after everything is provisioned. In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be specified declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be specified by one or more configuration files. Hence, the overall topology of the infrastructure (e.g., which resources depend on which and how they each work together) can be described declaratively. In some cases, once the topology is specified, workflows can be generated to create and / or manage the different components described in the configuration files.

[0070] In some examples, the infrastructure may have many interconnected elements, such as one or more virtual private clouds (VPCs) (e.g., configurable and / or shared clouds), also known as a core network. There may be a network infrastructure (a potentially on-demand pool of computing resources). In some examples, there may also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how the network's security will be set up. Other infrastructure elements, such as load balancers, databases, or the like, may also be provisioned. The infrastructure may evolve over time as more infrastructure elements are desired and / or added.

[0071] In some cases, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. In addition, the above-described techniques may enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often multiple, different production environments (e.g., across a variety of different geographic locations, sometimes spanning the globe). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning may be done manually, and provisioning tools may be utilized to provision the resources, and / or deployment tools may be utilized to deploy the code once the infrastructure is provisioned.

[0072] FIG. 7 illustrates an exemplary pattern for an IaaS architecture in accordance with at least one embodiment. 7 is a block diagram 700 illustrating a service operator 702. A service operator 702 can be communicatively coupled to a secure host tenancy 704, which can include a virtual cloud network (VCN) 706 and a secure host subnet 708. In some examples, the service operator 702 can run software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 7, Palm OS, and the like, and can provide internet, email, short message service (SMS), Blackberry ( Portable handheld devices (e.g., iPhone®, cellular phones, iPad®, computing tablets, personal digital assistants (PDAs)) that are capable of using the IEEE 802.11b / g or other communication protocols. The VCN 706 may use one or more client computing devices, which may be a personal computer, a personal assistant, or a wearable device (e.g., a Google Glass® head-mounted display). Alternatively, the client computing devices may be general-purpose personal computers, including, by way of example, personal and / or laptop computers running various versions of the Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing devices may be workstation computers running any of a variety of commercially available UNIX® or UNIX-like operating systems, including, by way of example, but not limited to, various GNU / Linux operating systems, such as Google Chrome OS. Alternatively, or in addition, the client computing devices may be thin-client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox gaming consoles with or without Kinect® gesture input devices), and / or personal computers capable of communicating over a network that can access the VCN 706 and / or the Internet. It may be any other electronic device, such as a personal messaging device.

[0073] The VCN 706 may include a local peering gateway (LPG) 710 that may be communicatively coupled to a secure shell (SSH) VCN 712 via an LPG 710 contained within the SSH VCN 712. The H VCN 712 can include an SSH subnet 714, and the SSH VCN 712 can be communicatively coupled to a control plane VCN 716 via an LPG 710 that is contained within the control plane VCN 716. The SSH VCN 712 can also be communicatively coupled to a data plane VCN 718 via the LPG 710. The control plane VCN 716 and the data plane VCN 718 can be contained within a service tenancy 719, which can be owned and / or operated by an IaaS provider.

[0074] The control plane VCN 716 may include a control plane demilitarized zone (DMZ) tier 720 that serves as a perimeter network (e.g., the portion of the enterprise network between the enterprise intranet and external networks). DMZ-based servers have limited responsibilities and may help contain security breaches. Additionally, the DMZ tier 720 may include one or more load balancer (LB) subnets 724. 22, a control plane app layer 724 that can include an app subnet 726, and a control plane data layer 728 that can include a database (DB) subnet 730 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 722 contained within the control plane DMZ layer 720 can be communicatively coupled to the app subnet 726 contained within the control plane app layer 724 and to an Internet gateway 734 that can be contained within the control plane VCN 716, and the app subnet 726 can be communicatively coupled to the DB subnet 730 contained within the control plane data layer 728, as well as to a service gateway 736 and a network gateway 738. Network Address Translation (NAT) gateway 738 The control plane VCN 716 may include a service gateway 736 and a NAT gateway 738.

[0075] The control plane VCN 716 can include a data plane mirror app layer 740 that can include an app subnet 726. The app subnet 726 contained within the data plane mirror app layer 740 can include a virtual network interface controller (VNIC) 742 that can run a compute instance 744. The compute instance 744 can communicatively couple the app subnet 726 of the data plane mirror app layer 740 to the app subnet 726 that can be contained within the data plane app layer 746.

[0076] The data plane VCN 718 can include a data plane app layer 746, a data plane DMZ layer 748, and a data plane data layer 750. The data plane DMZ layer 748 can include a LB subnet 722, which can be communicatively coupled to an app subnet 726 of the data plane app layer 746 and an internet gateway 734 of the data plane VCN 718. The app subnet 726 can be communicatively coupled to a service gateway 736 of the data plane VCN 718 and a NAT gateway 738 of the data plane VCN 718. The data plane data layer 750 can also include a DB subnet 730, which can be communicatively coupled to the app subnet 726 of the data plane app layer 746.

[0077] The internet gateways 734 of the control plane VCNs 716 and of the data plane VCNs 718 may be communicatively coupled to a metadata management service 752, which may be communicatively coupled to the public internet 754. The public internet 754 may be communicatively coupled to NAT gateways 738 of the control plane VCNs 716 and of the data plane VCNs 718. The service gateways 736 of the control plane VCNs 716 and of the data plane VCNs 718 may be communicatively coupled to cloud services 756.

[0078] In some examples, a service gateway 736 in the control plane VCN 716 or in the data plane VCN 718 can make application programming interface (API) calls to cloud services 756 without traversing the public Internet 754. API calls from the service gateway 736 to the cloud service 756 can be one-way: the service gateway 736 can make an API call to the cloud service 756, and the cloud service 756 can send the requested data to the service gateway 736. However, the cloud service 756 cannot initiate an API call to the service gateway 736.

[0079] In some examples, secure host tenancy 704 may be directly connected to service tenancy 719, which may otherwise be isolated. Secure host subnet 708 may communicate with SSH subnet 714 through LPG 710, which may allow bidirectional communication through otherwise isolated systems. Connecting secure host subnet 708 to SSH subnet 714 may give secure host subnet 708 access to other entities within service tenancy 719.

[0080] The control plane VCN 716 may enable users of the service tenancy 719 to set up or otherwise provision desired resources. The desired resources provisioned within the control plane VCN 716 are then passed to the data plane VCN 716. The control plane VCN 716 may be deployed or otherwise used within the data plane VCN 718. In some examples, the control plane VCN 716 may be isolated from the data plane VCN 718, and the data plane mirror app layer 740 of the control plane VCN 716 may communicate with the data plane app layer 746 of the data plane VCN 718 via a VNIC 742, which may be contained within the data plane mirror app layer 740 and the data plane app layer 746.

[0081] In some examples, a user, or customer, of the system may make a request, such as a create, read, update, or delete (CRUD) operation, over the public Internet 754, which may communicate the request to a metadata management service 752. The metadata management service 752 may communicate the request to the control plane VCN 716 through an Internet gateway 734. The request may be received by a LB subnet 722 contained within the control plane DMZ layer 720. The LB subnet 722 may determine that the request is valid, and in response to this determination, the LB subnet 722 may transmit the request to an app subnet 726 contained within the control plane app layer 724. If the validity of the request is verified and requires a call to the public Internet 754, the call to the public Internet 754 may be transmitted to a NAT gateway 738 that may make the call to the public Internet 754. Memory that may be desired to be stored with the request may be stored in the DB subnet 730.

[0082] In some examples, data plane mirror app layer 740 can facilitate direct communication between control plane VCN 716 and data plane VCN 718. For example, it may be desired that configuration modifications, updates, or other suitable changes be applied to resources contained within data plane VCN 718. Via VNIC 742, control plane VCN 716 can communicate directly with resources contained within data plane VCN 718, thereby performing configuration modifications, updates, or other suitable changes thereon.

[0083] In some embodiments, the control plane VCN 716 and the data plane VCN 718 may be subsumed within the service tenancy 719. In this case, a user or customer of the system may not own or operate either the control plane VCN 716 or the data plane VCN 718. Instead, an IaaS provider may own or operate the control plane VCN 716 and the data plane VCN 718, both of which may be subsumed within the service tenancy 719. This embodiment may enable network isolation that may prevent users or customers from interacting with the resources of other users or customers. This embodiment may also enable users or customers of the system to store databases privately without having to rely on the public Internet 754 for storage, which may not have the desired level of security.

[0084] In other embodiments, LB subnet 722 contained within control plane VCN 716 may be configured to receive signals from service gateway 736. In this embodiment, control plane VCN 716 and data plane VCN 718 may be configured to be called by customers of the IaaS provider without calling the public Internet 754. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored on the service tenancy 719, which may be controlled by the IaaS provider and isolated from the public Internet 754.

[0085] 8 is a block diagram 800 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 802 (e.g., service operator 702 of FIG. 7) configures a virtual cloud network (VCN) 806 (e.g., VCN 706 of FIG. 7) and a secure host subnet 808 (e.g., secure host subnet 808 of FIG. 7). VCN 806 may be communicatively coupled to a secure host tenancy 804 (e.g., secure host tenancy 704 in FIG. 7 ), which may include a local peering gateway (LPG) 810 (e.g., LPG 710 in FIG. 7 ), which may be communicatively coupled to a secure shell (SSH) VCN 812 (e.g., SSH VCN 712 in FIG. 7 ) via an LPG 710 contained within SSH VCN 812. SSH VCN 812 may include an SSH subnet 814 (e.g., SSH subnet 714 in FIG. 7 ), which may be communicatively coupled to a control plane VCN 816 (e.g., control plane VCN 716 in FIG. 7 ) via an LPG 810 contained within control plane VCN 816. The control plane VCN 816 may be contained within a service tenancy 819 (e.g., service tenancy 719 in FIG. 7), and the data plane VCN 818 (e.g., data plane VCN 718 in FIG. 7) may be contained within a customer tenancy 821, which may be owned or operated by a user, or customer, of the system.

[0086] The control plane VCN 816 may include a control plane DMZ layer 820 (e.g., control plane DMZ layer 720 of FIG. 7 ) that may include a LB subnet 822 (e.g., LB subnet 722 of FIG. 7 ), a control plane app layer 824 (e.g., control plane app layer 724 of FIG. 7 ) that may include an app subnet 826 (e.g., app subnet 726 of FIG. 7 ), and a control plane data layer 828 (e.g., control plane data layer 728 of FIG. 7 ) that may include a database (DB) subnet 830 (e.g., similar to DB subnet 730 of FIG. 7 ). The LB subnet 822 contained within the control plane DMZ layer 820 may be communicatively coupled to an app subnet 826 contained within the control plane app layer 824 and to an Internet gateway 834 (e.g., Internet gateway 734 in FIG. 7 ), which may be contained within the control plane VCN 816; the app subnet 826 may be communicatively coupled to a DB subnet 830 contained within the control plane data layer 828, as well as to a service gateway 836 (e.g., service gateway in FIG. 7 ), and a network address translation (NAT) gateway 838 (e.g., NAT gateway 738 in FIG. 7 ). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0087] Control plane VCN 816 can include a data plane mirror app layer 840 (e.g., data plane mirror app layer 740 of FIG. 7 ), which can include an app subnet 826. The app subnet 826 contained within data plane mirror app layer 840 can include a virtual network interface controller (VNIC) 842 (e.g., VNIC 742) on which a compute instance 844 (e.g., similar to compute instance 744 of FIG. 7 ) can run. Compute instance 844 can facilitate communication between app subnet 826 of data plane mirror app layer 840 and app subnet 826, which can be contained within data plane app layer 846 (e.g., data plane app layer 746 of FIG. 7 ), via VNIC 842 contained within data plane mirror app layer 840 and VNIC 842 contained within data plane app layer 846.

[0088] The internet gateway 834 contained within the control plane VCN 816 may be communicatively coupled to a metadata management service 852 (e.g., metadata management service 752 in FIG. 7), which may be communicatively coupled to the public internet 854 (e.g., public internet 754 in FIG. 7). The public internet 854 may be communicatively coupled to a NAT gateway 838 contained within the control plane VCN 816. The service gateway 836 contained within the control plane VCN 816 can be communicatively coupled to cloud services 856 (e.g., cloud services 756 in FIG. 7).

[0089] In some examples, the data plane VCN 818 may be contained within the customer tenancy 821. In this case, the IaaS provider may provide a control plane VCN 816 per customer, and for each customer, the IaaS provider may set up a unique compute instance 844 contained within the service tenancy 819. Each compute instance 844 may enable communication between the control plane VCN 816 contained within the service tenancy 819 and the data plane VCN 818 contained within the customer tenancy 821. The compute instance 844 may enable resources provisioned within the control plane VCN 816 contained within the service tenancy 819 to be deployed or otherwise used within the data plane VCN 818 contained within the customer tenancy 821.

[0090] In another example, a customer of the IaaS provider may have a database that is based within customer tenancy 821. In this example, control plane VCN 816 may include data plane mirror app tier 840, which may include app subnet 826. Data plane mirror app tier 840 may reside within data plane VCN 818, but data plane mirror app tier 840 may not be based within data plane VCN 818. That is, while data plane mirror app tier 840 may have access to customer tenancy 821, data plane mirror app tier 840 may not reside within data plane VCN 818 or be owned or operated by the IaaS provider's customer. Data plane mirror app tier 840 may be configured to make calls to data plane VCN 818, but may not be configured to make calls to any entities contained within control plane VCN 816. A customer may desire to deploy or otherwise use resources in the data plane VCN 818 provisioned in the control plane VCN 816, and the data plane mirror app layer 840 can facilitate the customer's desired deployment or other use of the resources.

[0091] In some embodiments, an IaaS provider's customer can apply filters to the data plane VCN 818. In this embodiment, the customer can determine what the data plane VCN 818 can access, and the customer may restrict access from the data plane VCN 818 to the public internet 854. The IaaS provider may not be able to apply filters or otherwise control the data plane VCN 818's access to any external networks or databases. Applying filters and controls by the customer to the data plane VCN 818, which is contained within the customer tenancy 821, can help isolate the data plane VCN 818 from other customers and from the public internet 854.

[0092] In some embodiments, cloud services 856 may be called by service gateway 836 to access services that may not reside on the public internet 854, on the control plane VCN 816, or on the data plane VCN 818. The connection between cloud services 856 and the control plane VCN 816 or data plane VCN 818 may not be live or continuous. Cloud services 856 may reside on different networks owned or operated by the IaaS provider. Cloud services 856 may be configured to receive calls from service gateway 836 and may be configured not to receive calls from the public internet 854. Some cloud services 856 may be isolated from other cloud services 856, and control plane VCN 816 may be isolated from cloud services 856 that may not be in the same region as control plane VCN 816. For example, control plane VCN 816 may be located in “Region 1,” and cloud service “Deployment 6” may be located in Region 1 and “Region 2.” If a call is made to deployment 6 by service gateway 836 contained within control plane VCN 816 located in region 1, the call may be routed to deployment 6 in region 1. In this example, control plane VCN 816, or region 1, The deployments 6 in may be communicatively coupled to the deployments 6 in region 2 or may not otherwise communicate with them.

[0093] 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., service operator 702 of FIG. 7) may be communicatively coupled to a secure host tenancy 904 (e.g., secure host tenancy 704 of FIG. 7), which may include a virtual cloud network (VCN) 906 (e.g., VCN 706 of FIG. 7) and a secure host subnet 908 (e.g., secure host subnet 708 of FIG. 7). VCN 906 may include an LPG 910 (e.g., LPG 710 of FIG. 7), which may be communicatively coupled to an SSH VCN 912 (e.g., SSH VCN 712 of FIG. 7) via an LPG 910 contained within SSH VCN 912. SSH VCN 912 can include an SSH subnet 914 (e.g., SSH subnet 714 in FIG. 7 ), which can be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 716 in FIG. 7 ) via an LPG 910 contained within the control plane VCN 916, and to a data plane VCN 918 (e.g., data plane 718 in FIG. 7 ) via an LPG 910 contained within the data plane VCN 918. The control plane VCN 916 and the data plane VCN 918 can be contained within a service tenancy 919 (e.g., service tenancy 719 in FIG. 7 ).

[0094] The control plane VCN 916 may include a control plane DMZ layer 920 (e.g., control plane DMZ layer 720 of FIG. 7 ) that may include a load balancer (LB) subnet 922 (e.g., LB subnet 722 of FIG. 7 ), a control plane app layer 924 (e.g., control plane app layer 724 of FIG. 7 ) that may include an app subnet 926 (e.g., similar to app subnet 726 of FIG. 7 ), and a control plane data layer 928 (e.g., control plane data layer 728 of FIG. 7 ) that may include a DB subnet 930. The LB subnet 922 contained within the control plane DMZ layer 920 may be communicatively coupled to an app subnet 926 contained within the control plane app layer 924 and to an internet gateway 934 (e.g., internet gateway 734 in FIG. 7 ), which may be contained within the control plane VCN 916; the app subnet 926 may be communicatively coupled to a DB subnet 930 contained within the control plane data layer 928, as well as to a service gateway 936 (e.g., service gateway in FIG. 7 ), and a network address translation (NAT) gateway 938 (e.g., NAT gateway 738 in FIG. 7 ). The control plane VCN 916 may include the service gateway 936 and the NAT gateway 938.

[0095] Data plane VCN 918 may include a data plane app layer 946 (e.g., data plane app layer 746 of FIG. 7 ), a data plane DMZ layer 948 (e.g., data plane DMZ layer 748 of FIG. 7 ), and a data plane data layer 950 (e.g., data plane data layer 750 of FIG. 7 ). Data plane DMZ layer 948 may include a trusted app subnet 960 and an untrusted app subnet 962 of data plane app layer 946, as well as an LB subnet 922 that may be communicatively coupled to an Internet gateway 934 contained within data plane VCN 918. Trusted app subnet 960 may be communicatively coupled to a service gateway 936 contained within data plane VCN 918, a NAT gateway 938 contained within data plane VCN 918, and a DB subnet 930 contained within data plane data layer 950. The untrusted app subnet 962 may be communicatively coupled to a service gateway 936 contained within the data plane VCN 918 and to a DB subnet 930 contained within the data plane data layer 950. The data plane data layer 950 may be communicatively coupled to a service gateway 936 contained within the data plane VCN 918. 936.

[0096] The untrusted app subnet 962 may include one or more primary VNICs 964(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N). Each tenant VM 966(1)-(N) may be communicatively coupled to a respective app subnet 967(1)-(N), which may be contained within a respective container egress VCN 968(1)-(N), which may be contained within a respective customer tenancy 970(1)-(N). Each secondary VNIC 972(1)-(N) may facilitate communication between the untrusted app subnet 962 contained within the data plane VCN 918 and the app subnet contained within the container egress VCN 968(1)-(N). Each container egress VCN 968(1)-(N) may include a NAT gateway 938, which may be communicatively coupled to the public internet 954 (e.g., public internet 754 in FIG. 7 ).

[0097] An internet gateway 934 contained within the control plane VCN 916 and contained within the data plane VCN 918 may be communicatively coupled to a metadata management service 952 (e.g., metadata management system 752 of FIG. 7 ), which may be communicatively coupled to the public internet 954. The public internet 954 may be communicatively coupled to a NAT gateway 938 contained within the control plane VCN 916 and contained within the data plane VCN 918. A service gateway 936 contained within the control plane VCN 916 and contained within the data plane VCN 918 can be communicatively coupled to cloud services 956.

[0098] In some embodiments, data plane VCN 918 may be integrated with customer tenancy 970. This integration may be useful or desirable for an IaaS provider's customers in some cases, such as when they may want support in executing code. A customer may provide code for execution that may be destructive, communicate with other customer resources, or otherwise cause undesirable effects. In response, the IaaS provider may determine whether to execute code provided to the IaaS provider by the customer.

[0099] In some examples, an IaaS provider's customer may grant temporary network access to the IaaS provider and request that a function be attached to data plane layer app 946. The code to perform the function may run within VMs 966(1)-(N), and the code may not be configured to run anywhere else on data plane VCN 918. Each VM 966(1)-(N) may be connected to one customer tenancy 970. Each container 971(1)-(N) contained within VM 966(1)-(N) may be configured to run code. In this case, double isolation may exist (e.g., container 971(1)-(N) may execute code, and container 971(1)-(N) may be contained within VMs 966(1)-(N) that are contained within at least untrusted app subnet 962), which may help prevent erroneous or otherwise unwanted code from damaging the IaaS provider's network or a different customer's network. Containers 971(1)-(N) may be communicatively coupled to customer tenancy 970 and may be configured to transmit or receive data from customer tenancy 970. Containers 971(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 918. Upon completing code execution, the IaaS provider may kill or otherwise dispose of containers 971(1)-(N).

[0100] In some embodiments, the trusted app subnet 960 is a In this embodiment, trusted app subnet 960 may be communicatively coupled to DB subnet 930 and may be configured to perform CRUD operations within DB subnet 930. Untrusted app subnet 962 may be communicatively coupled to DB subnet 930, but in this embodiment, the untrusted app subnet may be configured to perform read operations within DB subnet 930. Containers 971(1)-(N) may be contained within each customer's VMs 966(1)-(N) and may execute code from the customer, but may not be communicatively coupled to DB subnet 930.

[0101] In other embodiments, the control plane VCN 916 and the data plane VCN 918 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 916 and the data plane VCN 918. However, communication may occur indirectly through at least one method. An LPG 910 may be established by the IaaS provider that can facilitate communication between the control plane VCN 916 and the data plane VCN 918. In another example, the control plane VCN 916 or the data plane VCN 918 may make a call to a cloud service 956 through a service gateway 936. For example, a call from the control plane VCN 916 to the cloud service 956 may include a request for a service that can communicate with the data plane VCN 918.

[0102] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 1002 (e.g., service operator 702 of FIG. 7) may be communicatively coupled to a secure host tenancy 1004 (e.g., secure host tenancy 704 of FIG. 7), which may include a virtual cloud network (VCN) 1006 (e.g., VCN 706 of FIG. 7) and a secure host subnet 1008 (e.g., secure host subnet 708 of FIG. 7). VCN 1006 may include an LPG 1010 (e.g., LPG 710 of FIG. 7), which may be communicatively coupled to an SSH VCN 1012 (e.g., SSH VCN 712 of FIG. 7) via an LPG 1010 contained within SSH VCN 1012. SSH VCN 1012 can include SSH subnet 1014 (e.g., SSH subnet 714 in FIG. 7 ), and SSH VCN 1012 can be communicatively coupled to control plane VCN 1016 (e.g., control plane VCN 716 in FIG. 7 ) via LPG 1010 contained within control plane VCN 1016, and to data plane VCN 1018 (e.g., data plane 718 in FIG. 7 ) via LPG 1010 contained within data plane VCN 1018. Control plane VCN 1016 and data plane VCN 1018 can be contained within service tenancy 1019 (e.g., service tenancy 719 in FIG. 7 ).

[0103] The control plane VCN 1016 may include a control plane DMZ layer 1020 (e.g., control plane DMZ layer 720 of FIG. 7 ) that may include a LB subnet 1022 (e.g., LB subnet 722 of FIG. 7 ), a control plane app layer 1024 (e.g., control plane app layer 724 of FIG. 7 ) that may include an app subnet 1026 (e.g., app subnet 726 of FIG. 7 ), and a control plane data layer 1028 (e.g., control plane data layer 728 of FIG. 7 ) that may include a DB subnet 1030 (e.g., DB subnet 930 of FIG. 9 ). The LB subnet 1022 contained within the control plane DMZ layer 1020 may be communicatively coupled to an app subnet 1026 contained within the control plane app layer 1024 and to an Internet gateway 1034 (e.g., Internet gateway 734 of FIG. 7 ) which may be contained within the control plane VCN 1016, and the app subnet 1026 is communicatively coupled to a DB subnet 1030 contained within the control plane data layer 1028, as well as to a service gateway 1036 (e.g., service gateway of FIG. 7 ) and a network address translation (NAT) gateway 1038 (e.g., For example, the control plane VCN 1016 may be communicatively coupled to a service gateway 1036 and a NAT gateway 1038.

[0104] The data plane VCN 1018 may include a data plane app layer 1046 (e.g., data plane app layer 746 in FIG. 7 ), a data plane DMZ layer 1048 (e.g., data plane DMZ layer 748 in FIG. 7 ), and a data plane data layer 1050 (e.g., data plane data layer 750 in FIG. 7 ). The data plane DMZ layer 1048 may include a trusted app subnet 1060 (e.g., trusted app subnet 960 in FIG. 9 ) and an untrusted app subnet 1062 (e.g., untrusted app subnet 962 in FIG. 9 ) of the data plane app layer 1046, as well as an LB subnet 1022 that may be communicatively coupled to an Internet gateway 1034 contained within the data plane VCN 1018. The trusted app subnet 1060 may be communicatively coupled to a service gateway 1036 contained within the data plane VCN 1018, a NAT gateway 1038 contained within the data plane VCN 1018, and a DB subnet 1030 contained within the data plane data layer 1050. The untrusted app subnet 1062 may be communicatively coupled to a service gateway 1036 contained within the data plane VCN 1018 and to a DB subnet 1030 contained within the data plane data layer 1050. The data plane data layer 1050 may include a DB subnet 1030 that may be communicatively coupled to a service gateway 1036 contained within the data plane VCN 1018.

[0105] The untrusted app subnet 1062 may include primary VNICs 1064(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N) residing within the untrusted app subnet 1062. Each tenant VM 1066(1)-(N) executes code within a respective container 1067(1)-(N), which may be communicatively coupled to the app subnet 1026, which may be contained within a data plane app tier 1046, which may be contained within a container egress VCN 1068. Each secondary VNIC 1072(1)-(N) may facilitate communication between the untrusted app subnet 1062, which is contained within the data plane VCN 1018, and the app subnet contained within the container egress VCN 1068. The container egress VCN may include a NAT gateway 1038, which may be communicatively coupled to the public internet 1054 (e.g., public internet 754 in FIG. 7 ).

[0106] The internet gateway 1034 contained within the control plane VCN 1016 and contained within the data plane VCN 1018 may be communicatively coupled to a metadata management service 1052 (e.g., metadata management system 752 of FIG. 7 ), which may be communicatively coupled to the public internet 1054. The public internet 1054 may be communicatively coupled to a NAT gateway 1038 contained within the control plane VCN 1016 and contained within the data plane VCN 1018. The service gateway 1036 contained within the control plane VCN 1016 and contained within the data plane VCN 1018 can be communicatively coupled to cloud services 1056.

[0107] In some examples, the pattern illustrated by the architecture of block diagram 1000 of FIG. 10 may be considered an exception to the pattern illustrated by the architecture of block diagram 900 of FIG. 9 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1067(1)-(N) contained within each customer's VM 1066(1)-(N) can be accessed by the customer in real time. Containers 1067(1)-(N) The containers 1067(1)-(N) may be configured to place calls to respective secondary VNICs 1072(1)-(N) contained within the app subnet 1026 of the data plane app tier 1046, which may be contained within the container egress VCN 1068. The secondary VNICs 1072(1)-(N) may transmit the calls to the NAT gateway 1038, which may transmit the calls to the public Internet 1054. In this example, the containers 1067(1)-(N), which may be accessed in real time by the customer, may be isolated from the control plane VCN 1016 and from other entities contained within the data plane VCN 1018. The containers 1067(1)-(N) may also be isolated from resources from other customers.

[0108] In another example, a customer can call cloud service 1056 using container 1067(1)-(N). In this example, the customer can execute code within container 1067(1)-(N) that requests a service from cloud service 1056. Container 1067(1)-(N) can transmit the request to secondary VNICs 1072(1)-(N), which can transmit the request to a NAT gateway, which can transmit the request to public Internet 1054. Public Internet 1054 can transmit the request via Internet gateway 1034 to LB subnet 1022, which is contained within control plane VCN 1016. In response to determining that the request is valid, the LB subnet can transmit the request to app subnet 1026, which can transmit the request to cloud service 1056 via service gateway 1036.

[0109] It should be understood that the IaaS architectures 700, 800, 900, 1000 depicted in the figures may have components other than those shown. Additionally, the depicted embodiments are merely examples of some of the cloud infrastructure systems that may incorporate an embodiment of the present disclosure. In other embodiments, the IaaS system may have more or fewer components than depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

[0110] In one embodiment, the IaaS system described herein may include a suite of applications, middleware, and database service offerings that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the present assignee.

[0111] 11 illustrates an exemplary computer system 1100 upon which various embodiments may be implemented. System 1100 may be used to implement any of the computer systems described above. As shown, computer system 1100 includes a processing unit 1104 that communicates with a number of peripheral subsystems via a bus subsystem 1102. These peripheral subsystems may include a processing acceleration unit 1106, an I / O subsystem 1108, a storage subsystem 1118, and a communication subsystem 1124. Storage subsystem 1118 includes a tangible computer-readable storage medium 1122 and a system memory 1110.

[0112] Bus subsystem 1102 provides a mechanism for allowing the various components and subsystems of computer system 1100 to communicate with each other as intended. Although bus subsystem 1102 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1102 may include a memory bus or memory controller, a peripheral bus, and any of a variety of bus architectures. The bus structure may be any of several types, including a local bus using the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the B-bus, the CISCO bus ... VESA: Video Electronics Standards Association ) local bus, and a Peripheral Component InterConnect (PCI) bus, which may be implemented as a mezzanine bus manufactured to the IEEE P1386.1 standard.

[0113] A processing unit 1104, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 1100. One or more processors may be included within processing unit 1104. These processors may include single-core or multi-core processors. In some embodiments, processing unit 1104 may be implemented as one or more independent processing units 1132 and / or 1134, with a single or multi-core processor included within each processing unit. In other embodiments, processing unit 1104 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0114] In various embodiments, processing unit 1104 may execute various programs according to program code and may maintain multiple simultaneously executing programs or processes. At any one time, some or all of the program code to be executed may reside within processor 1104 and / or within storage subsystem 1118. Through suitable programming, processor 1104 may provide the various functionality described above. Computer system 1100 may additionally include a processing acceleration unit 1106, which may include a digital signal processor (DSP), a special purpose processor, and / or the like.

[0115] The I / O subsystem 1108 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice command recognition system, an audio input device using a microphone, and other types of input devices. User interface input devices may include, for example, a motion-sensing and / or gesture-recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device, such as a Microsoft Xbox® 360 game controller, through a natural user interface using gestures and spoken commands. User interface input devices may also include an eye-gesture recognition device such as a Google Glass® blink detector that detects eye activity from a user (e.g., “blinking” while taking a picture and / or making a menu selection) and translates the eye gesture as input into an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0116] User interface input devices also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, and the like. The user interface input devices may include audio / visual devices such as digital 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, the user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound devices, etc. The user interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0117] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. Display subsystems may be flat-panel devices, such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touch screens, and the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1100 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey text, graphics, and audio / video information, such as, but not limited to, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0118] Computer system 1100 may include a storage subsystem 1118 that includes software elements shown as currently located within system memory 1110. System memory 1110 may store program instructions that are loadable and executable on processing unit 1104, as well as data generated during the execution of these programs.

[0119] Depending on the configuration and type of computer system 1100, the system memory 1110 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by the processing unit 1104. In some implementations, the system memory 1110 may be static random access memory (SRAM). In some implementations, the boot process may include multiple different types of memory, such as boot memory (BRAM) or dynamic random access memory (DRAM). A basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1100, such as during system operation, is typically stored in ROM. By way of example, and not limitation, system memory 1100 may be used. 110 also includes application programs 1112, program data, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc. 11. The computer 1114 and operating system 1116 are shown. By way of example, the operating system 1116 may be any of various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems, Google Chrome (registered trademark), and the like. (Registered trademarks) OS, and the like), and / or iOS, Windows (Registered trademarks) The operating systems may include mobile operating systems such as the BlackBerry® Phone, Android® OS, BlackBerry® 11 OS, and Palm® OS operating systems.

[0120] The storage subsystem 1118 also includes the underlying protocols that provide the functionality of some embodiments. The storage subsystem 1118 may provide a tangible computer-readable storage medium for storing programming and data structures. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in the storage subsystem 1118. These software modules or instructions may be executed by the processing unit 1104. The storage subsystem 1118 may also provide a repository for storing data used in accordance with the present disclosure.

[0121] Storage subsystem 1100 may also include computer-readable storage medium reader 1120, which may be further connected to computer-readable storage medium 1122. Together, and optionally in combination with system memory 1110, computer-readable storage medium 1122 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for containing, storing, transmitting, and retrieving computer-readable information on a temporary and / or more permanent basis.

[0122] The computer-readable storage medium 1122 containing the code or portions of code may also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and nonvolatile, removable and non-removable media, implemented in any method or technology for information storage and / or transmission. 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 cassette, magnetic tape, magnetic disk storage, or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media, such as a data signal, data transmission, or any other medium that may be used to transmit desired information and that can be accessed by computing system 1100.

[0123] By way of example, the computer-readable storage medium 1122 may include hard disk drives that read from or write to non-removable, non-volatile magnetic media, magnetic disk drives that read from or write to removable, non-volatile magnetic disks, and optical disk drives that read from or write to removable, non-volatile optical disks, such as CD-ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer-readable storage medium 1122 may include, but is not limited to, Zip® drives, flash memory cards, universal serial bus (USB) flash drives, secure digital (SD) cards, DVD disks, digital video tapes, and the like. The computer-readable storage medium 1122 may also include solid-state drives (SSDs) based on non-volatile memory, such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, and the like, solid-state RAM, dynamic RAM, and the like. M, static RAM, DRAM-based SSDs, magneto-resistive RAM (MRAM) SSDs, and other SSDs based on volatile memory, as well as DRAM and The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1100.

[0124] The communications subsystem 1124 provides an interface to other computer systems and networks. The communications subsystem 1124 is an interface for receiving data from other systems and transmitting data from the computer system 1100 to other systems. For example, the communications subsystem 1124 may enable the computer system 1100 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1124 may provide radio frequency (RF) transceiver services for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution), WiFi (IEEE 602.11 family of standards, or other mobile communications technologies, or any combination thereof). Components, global positioning system (GPS) receivers In some embodiments, the communications subsystem 1124 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0125] In some embodiments, the communications subsystem 1124 may also receive incoming communications in the form of structured and / or unstructured data feeds 1126, event streams 1128, event updates 1130, and the like for one or more users who may be using the computer system 1100.

[0126] For example, the communication subsystem 1124 may provide a Twitter feed, Facebook feed, Registered trademark) updates, Rich Site Summary (RSS) feeds, etc. It may be configured to receive data feeds 1126 in real time from users of social networks and / or other communication services, such as web feeds and / or real-time updates from one or more third-party sources.

[0127] Additionally, the communications subsystem 1124 may also be configured to receive data in the form of continuous data streams, which may include event streams 1128 of real-time events, which may be continuous, or unbounded, essentially without a clear end, and / or event updates 1130. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0128] The communications subsystem 1124 may also be configured to output structured and / or unstructured data feeds 1126, event streams 1128, event updates 1130, and the like to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1100.

[0129] The computer system 1100 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® cellular phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0130] Due to the ever-changing nature of computers and networks, the description of the computer system 1100 shown in the figure is intended to be illustrative only. Many other configurations may exist having more or fewer components than the system shown in the figure. For example, customized hardware could also be used and / or particular elements could be implemented in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices, such as network input / output devices, could be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other ways and / or methods to implement the various embodiments.

[0131] While certain embodiments have been described, various modifications, variations, alternative constructions, and equivalents are encompassed within the scope of the present disclosure. The embodiments are not limited to operation in any particular data processing environment, but can freely operate in multiple data processing environments. In addition, while the embodiments have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0132] Furthermore, while embodiments have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented solely in hardware, solely in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or different processors in any combination. Thus, when a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using various 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.

[0133] Accordingly, the specification and drawings are to be regarded in an illustrative and not a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other changes and modifications may be made thereto without departing from the broader spirit and scope as set forth in the claims. Accordingly, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the appended claims.

[0134] Use of the terms "a," "an," and "the" and similar referents in the context of describing embodiments of the present disclosure (particularly in the context of the appended claims) should be construed to encompass both the singular and the plural, unless otherwise stated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are used in particular Unless otherwise expressly stated, terms should be construed as open-ended terms (i.e., meaning "including, but not limited to"). The term "connected" means that even if there is some intervening Partly or wholly contained within, taken up in The recitation of ranges of values ​​herein, unless otherwise stated herein, is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, and each separate value is incorporated into the specification as if it were individually set forth herein. All methods described herein may be used interchangeably unless otherwise stated herein or otherwise clearly contradicted by context. Unless otherwise specified, the steps may be performed in any suitable order. Any and all examples given herein, or the use of exemplary language (e.g., "such as"), are merely examples of implementations. It is intended merely to facilitate understanding of the embodiments and does not impose limitations on the scope of the disclosure unless otherwise specified. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0135] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is generally intended to be understood in context as being used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0136] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art will be able to adopt such variations as necessary, and the present disclosure may be practiced in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, this disclosure encompasses any combination of the above-described elements in all possible variations thereof.

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

[0138] In the foregoing specification, aspects of the disclosure have been described with reference to certain embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative and not restrictive.

Claims

1. 1. A method comprising: receiving, by a computer system, a request to write data to a volume; and identifying, by the computer system, a zone segment mapped to the volume, the zone segment comprising a plurality of zones, the method further comprising: identifying, by the computer system, a segment pointer that indicates a write location within a zone of the zone segment; writing, by the computer system, the data to one or more of the plurality of zones of the zone segment starting from the write location; updating, by the computer system, the segment pointer according to the end of the data within the zone segment; A method comprising:

2. ascertaining the size of the data identified in the request; and determining a capacity of the zone, the capacity corresponding to a write path between the write location and an end point of the zone, the method further comprising: comparing the capacity of the zone to the size of the data; and dividing the data into a first block and a second block in response to the size of the data exceeding the capacity of the zone, the size of the first block corresponding to the capacity of the zone, the method further comprising: writing the first block starting from the write location; writing the second block to a subsequent zone of the zone segment; The method of claim 1 , comprising:

3. Updating the segment pointers includes: marking the zone segment as a full zone segment in response to the end of the data within the zone segment matching a capacity of the zone segment; identifying new zone segments mapped to the volume; and updating the segment pointer to the start of the new zone segment; 3. The method of claim 1 or 2, comprising:

4. 10. The method of any one of the preceding claims, wherein identifying the segment pointer comprises scanning the zone segments mapped to the volume for empty or open zones.

5. Identifying the segment pointer comprises:

5. The method of claim 4, further comprising: allocating a new zone segment to the volume in response to the zone segments mapped to the volume not including an empty or open zone, wherein the segment pointer is the start of a first zone of the new zone segment.

6. determining a utilization rate of the zone segment; comparing the usage percentage to a usage threshold; In response to the usage rate not satisfying the usage threshold, identifying stored data within the plurality of zones of the zone segment; The stored data is transferred from one or more source zones to one of the plurality of zones. mapping the image data to one or more empty or open zones of the image data; writing said stored data into said empty or open zone; resetting the source zone to an open status; 10. The method of any one of the preceding claims, further comprising:

7. Identifying stored data within the plurality of zones comprises: receiving mapping metadata describing the mapping of the zone segments to the volume; and locating the stored data within the plurality of zones according to the mapping metadata; The method of claim 6, comprising:

8. 10. The method of claim 1, wherein the plurality of zones is implemented in a single magnetic recording storage system.

9. 1. A system comprising: a memory configured to store computer-executable instructions; one or more processors configured to access the memory and execute the computer-executable instructions to at least: receiving a request to write data to a volume; and identifying a zone segment mapped to the volume, the zone segment comprising a plurality of zones, the at least identifying a segment pointer that indicates a write location within a zone of said zone segment; writing the data to one or more of the plurality of zones of the zone segment starting from the write location; updating the segment pointer according to an end point of the data within the zone segment.

10. The one or more processors are further configured to execute the computer-executable instructions to at least: ascertaining the size of the data identified in the request; determining a capacity of the zone, the capacity corresponding to a write path between the write location and an end point of the zone; comparing the capacity of the zone to the size of the data; dividing the data into a first block and a second block in response to the size of the data exceeding the capacity of the zone, wherein a size of the first block corresponds to the capacity of the zone; writing the first block starting from the write location; and writing the second block to a subsequent zone of the zone segment.

11. Updating the segment pointers includes: marking the zone segment as a full zone segment in response to the end of the data within the zone segment matching a capacity of the zone segment; identifying new zone segments mapped to the volume; and updating the segment pointer to the start of the new zone segment; 11. The system of claim 9 or 10, comprising:

12. The system of claim 9 , wherein identifying the segment pointer comprises scanning the zone segments mapped to the volume for empty or open zones.

13. Identifying the segment pointer comprises:

13. The system of claim 12, further comprising: in response to the zone segments mapped to the volume not including an empty or open zone, allocating a new zone segment to the volume, wherein the segment pointer is the start of a first zone of the new zone segment.

14. The one or more processors execute the computer-executable instructions to perform at least determining a utilization rate of the zone segment; comparing the usage percentage to a usage threshold; In response to the usage rate not satisfying the usage threshold, identifying stored data within the plurality of zones of the zone segment; mapping the stored data from one or more source zones to one or more empty or open zones of the plurality of zones; writing said stored data into said empty or open zone; resetting the source zone to an open status; 14. The system of claim 9, further configured to:

15. Identifying stored data within the plurality of zones comprises: receiving mapping metadata describing the mapping of the zone segments to the volume; and locating the stored data within the plurality of zones according to the mapping metadata; The system of claim 14 , comprising:

16. 1. A computer-readable storage medium storing instructions executable by a computer system, the instructions, when executed by one or more processors of the computer system, causing the one or more processors to: receiving, by a computer system, a request to write data to a volume; identifying, by the computer system, a zone segment mapped to the volume, the zone segment including a plurality of zones; identifying, by the computer system, a segment pointer that indicates a write location within a zone of the zone segment; writing, by the computer system, the data to one or more of the plurality of zones of the zone segment starting from the write location; updating, by the computer system, the segment pointer according to the end of the data within the zone segment; 1. A computer-readable storage medium for causing a computer to perform a plurality of operations, including:

17. The plurality of operations include: ascertaining the size of the data identified in the request; and determining a capacity of the zone, the capacity corresponding to a write path between the write location and an end point of the zone, the plurality of operations further comprising: comparing the capacity of the zone to the size of the data; and dividing the data into a first block and a second block in response to the size of the data exceeding the capacity of the zone, the size of the first block corresponding to the capacity of the zone, and the plurality of operations further comprising: writing the first block starting from the write location; writing the second block to a subsequent zone of the zone segment; 17. The computer-readable storage medium of claim 16, comprising:

18. Updating the segment pointers includes: marking the zone segment as a full zone segment in response to the end of the data within the zone segment matching a capacity of the zone segment; identifying new zone segments mapped to the volume; and updating the segment pointer to the start of the new zone segment; 18. The computer-readable medium of claim 16 or 17, comprising:

19. 19. The computer-readable medium of claim 16, wherein identifying the segment pointer comprises scanning the zone segments mapped to the volume for empty or open zones.

20. Identifying the segment pointer comprises:

20. The computer-readable medium of claim 19, further comprising: allocating a new zone segment to the volume in response to the zone segments mapped to the volume not including an empty or open zone, wherein the segment pointer is the start of a first zone of the new zone segment.

Images