Amazon Technologies, Inc.

Benjamin Arthur Hawks

Danny Wei

James Michael Thompson

Norbert Paul Kusters

Marc Stephen Olson

Nachiappan Arumugam

John Luther Guthrie, Ii

Jianhua Fan

John Luther Guthrie

Marc John Brooker

John Robert Smiley

Jeevan Shankar

Kerry Quintin Lee

Bhavesh Anil Doshi

Ganesh Viswanathan

Valentin Gabriel Priescu

Jiahua He

Norbert P Kusters

Ii John Luther Guthrie

A block-based storage system may implement page cache write logging. Write requests for a data volume maintained at a storage node may be received at a storage node. A page cache for may be updated in accordance with the request. A log record describing the page cache update may be stored in a page cache write log maintained in a persistent storage device. Once the write request is performed in the page cache and recorded in a log record in the page cache write log, the write request may be acknowledged. Upon recovery from a system failure where data in the page cache is lost, log records in the page cache write log may be replayed to restore to the page cache a state of the page cache prior to the system failure.

Page cache write logging at block-based storage

A slave storage is provisioned using metadata of a master B-tree and updates to references (e.g., offsets) pertaining to data operations of the master B-tree. Master-slave pairs can be used to provide data redundancy, and a master copy can include the master B-tree with references to corresponding data. When provisioning a slave copy, the master sends a B-tree copy to the slave, which stores the slave B-tree copy, allocates the necessary space on local storage, and updates respective offsets of the slave B-tree copy to point to the local storage. Data from the master can then be transferred to the slave and stored according to a note and commit process that ensures operational sequence of the data. Operations received to the master during the process can be committed to the slave copy until the slave is consistent with the master and able to take over as master in the event of a failure.

System and method for provisioning slave storage including copying a master reference to slave storage and updating a slave reference

Systems and methods for provisioning a slave copy for redundant data storage and for writing data to persistent storage in a block-based storage system using sequential operation numbers are provided. In one embodiment, the method includes maintaining a master copy and a slave copy of a data volume, the master copy including data generated by a plurality of operations having respective sequential operation numbers, receiving a write instruction for second data to be added to the master copy, and recording the second data as a note that is not readable. The method may further include sending a copy of the note from the master copy to the slave copy, committing the note to the master copy with a sequential operation number, and committing the copy of the note to the slave copy based in part on the sequential operation number. A B-tree may be created based at least in part on an offset for a write instruction associated with the second data, a length, and an operation number included in the note.

Systems and methods including committing a note to master and slave copies of a data volume based on sequential operation numbers

Techniques are described for formally expressing whether sequences of operations performed on block storage devices are sequential or random. In embodiments, determinations of whether these sequences of operations are sequential or random may be used to predict latencies involved with running particular workloads, and to predict representative workloads for particular latencies.

Block device modeling

Master-slave pairs can be used to provide data redundancy in an electronic data environment. A master peer can include a B-tree with references to the corresponding data. When provisioning a slave, the master can send a point-in-time copy of the B-tree to the slave, which can allocate the necessary space on local storage and update the references of the B-tree to point to the local storage for the slave. If the master and slave become disconnected, one of the peers can function as a solo master until the peers are again connected, at which point the old peer can be brought current or a new slave provisioned. A log peer can also be provisioned by a solo master, which can store data for operations received during the disconnect for use in catching up a slave peer, which could be the old slave, the log peer, or a new peer.

Catch-up replication with log peer

At a first client-side component of a storage service, a metric of a storage workload directed from the first client-side component towards server components of the storage service is determined. The metric is transmitted to a particular server component, which is configured to propagate the metric to a different client-side component of the storage service. The first client-side component receives, from a server component, a different metric of a storage workload of a second client-side component. The first client-side component reschedules at least one storage request based at least in part on the different metric.

Storage workload management using redirected messages

Persistent storage for a master copy is provided using operation numbers. A master copy can include a persistent key-value store such as a B-tree with references to corresponding data. When provisioning a slave copy, the master copy sends a point-in-time copy of the B-tree to the slave copy, which stores a copy of the B-tree, allocates the necessary space, and updates the references of the B-tree to point to a local storage before the data is transferred. When writing the data to persistent storage, a snapshot created on the master copy is an operation that is replicated to the slave copy. The snapshot is generated using a volume view that includes changes to chunks of data of the master copy since a previous snapshot, as determined using the operation number for the previous snapshot. Data (and metadata) for the snapshot is written to persistent storage while new input/output operations are processed.

Data replication snapshots for persistent storage using operation numbers

The estimated rate of work requests expected during a time period at a first block storage device, implemented at a particular server of a storage service, exceeds a provisioned rate of the first device. At a client-side component of the storage service, a different storage server is identified, at which the rate of work requests directed during the time period to a second block storage device is anticipated to be less than the provisioned rate of the second device. At least one admission control parameter of the first device is modified to enable the first storage server to accept work requests at a rate that exceeds the provisioned rate of the first device.

Coordinated admission control for network-accessible block storage

The current document describes a storage system that provides a storage volume with a block-data interface to one or more clients. The storage system provides a key-value store that is associated with the storage volume. The clients access the key-value store via a key-value interface that provides a number of key-value operations to read, write, list, and delete key-value records from the key-value store. In some implementations, the key-value interface provides additional key-value operations that support the use of the key-value store by more than one client at a time. An environment in which the key-value store is used by the clients to retain I/O throttling parameters is described.

Volume-based key-value store

Systems and methods are described providing detailed input/output (I/O) metric information that is collected and gathered by an agent of the storage volume. An I/O request is received by a storage volume, and the agent associates primary and secondary identifiers with that I/O request. For example, a trace may be associated with that I/O request. The agent may store this I/O metric information in a ring buffer. Further, after collection and aggregation, statistics may be published by an I/O metric service that further processes the data provided by the agent. Advantageously, interdependent relationships associated with the I/O request or I/O operations of that request may be included in those statistics. This may allow an operator to evaluate the performance of I/O requests for a network.

Managing I/O requests

Block device workload analysis

Systems and methods are described for dynamically detecting outliers in a set of input/output (I/O) metrics collected and aggregated by a storage volume network. An I/O request is received by a storage volume network, and an agent of the storage volume network associates primary and secondary identifiers with that I/O request. For example, a trace may be associated with a request to write data to a storage volume network, and spans may be associated with the individual operations required to fulfill that request. Once gathered, I/O metrics may be aggregated based on the associated identifiers. I/O metric information regarding outliers may be received from the storage volume network, processed, and published by an I/O metrics service to identify the outliers among the primary and secondary identifiers. These outliers may then be stored for further analysis, and may be utilized to determine improvements to the performance of a storage volume network.

Computer system for managing I/O metric information by identifying one or more outliers and comparing set of aggregated I/O metrics

Persistent storage for a master copy is provided using operation numbers. A master copy can include a persistent key-value store such as a B-tree with references to corresponding data. When provisioning a slave copy, the master copy sends a point-in-time copy of the B-tree to the slave copy, which stores a copy of the B-tree, allocates the necessary space, and updates the references of the B-tree to point to a local storage before the data is transferred. When writing the data to persistent storage, a snapshot created on the master copy is an operation that is replicated to the slave copy. The snapshot is generated using a volume view that includes changes to chunks of data of the master copy since a previous snapshot, as determined using the operation number for the previous snapshot. Data (and metadata) for the snapshot is written to persistent storage while new EO operations are processed.

Growing community of inventors

Seattle, WA, United States of America

Benjamin Arthur Hawks