Abstract: Notice of migration of a portion of a data volume from a first location to a second location is received by a first computer system from a second computer system, where the data volume is separated over a network from the first computer system. A third computer system, separated over a network from the first computer system, is caused to invalidate a mapping between the portion and the first location. An indication that the third computer system seeks access to the portion is identified. A third computer system is enabled, by providing a mapping between the portion and the second location, to access portion at the second location.

Abstract: A data storage system includes multiple head nodes and data storage sleds. Volume data is replicated between a primary and one or more secondary head nodes for a volume partition and is further flushed to a set of mass storage devices of the data storage sleds. Volume metadata is maintained in a primary and one or more secondary head nodes for a volume partition and is updated in response to volume data being flushed to the data storage sleds. Also, the primary and secondary head nodes store check-points of volume metadata to the data storage sleds, wherein in response to a failure of a primary or secondary head node for a volume partition, a replacement secondary head node for the volume partition recreates a secondary replica for the volume partition based, at least in part, on a stored volume metadata checkpoint.

Abstract: A data storage system includes a rack, multiple head nodes, multiple data storage sleds, and at least two networking devices. The at least two network devices are configured to implement at least two redundant networks within the data storage system. Also, each of the head nodes is assigned at least two network addresses for communication with the data storage sleds of the data storage system via the at least two networking devices. The data storage sleds each include multiple mass storage devices and a sled controller that is configured to couple with the at least two network switches. IO In some embodiments, the data storage system further includes redundant power systems within a rack in which the head nodes, the data storage sleds, and the at least two networking devices are mounted.

Abstract: Generally described, one or more aspects of the present application correspond to techniques for modifying volume encryption status, either by creating an encrypted copy of an unencrypted source volume or by re-encrypting the replica with a different key than the source volume. This can be accomplished using an intermediary transform fleet that stores the encryption key(s) and performs encryption (and decryption, in cases where the source is encrypted). Further, these techniques can implement a state refresh for any client attached to the volume in order to equip the client to handle the different encryption state of the encrypted volume.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Abstract: 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.

Abstract: First information about regions of storage space in a storage environment available for a volume is provided to a service provider, with the storage environment being external to the service provider. The service provider is notified that information usable to locate a storage destination of a portion of the volume is unavailable. Second information that includes the storage destination in the storage environment is obtained from the service provider. A data operation is performed at the storage destination, with the storage destination determined based at least in part from the second information.

Abstract: A distributed system may implement preventing concentrated selection of resource hosts for placing resources within the distributed system. When a request to place a resource at a resource host is received, an evaluation of load metrics for the resource host is made with respect to rejection criteria. If the rejection criteria is satisfied, then the resource host may reject the request to place the resource. If the rejection criteria is not satisfied, then the resource host may not reject the placement of the resource. Rejection criteria may be provided to resource hosts along with the placement request, in some embodiments. Rejection criteria may be changed, weakened, or removed entirely if initial attempts to place a resource are unsuccessful.

Abstract: 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.

Abstract: Generally described, one or more aspects of the present application correspond to techniques for creating encrypted block store volumes of data from unencrypted object storage snapshots of the volumes. These encryption techniques use a special pool of servers for performing the encryption. These encryption servers are not accessible to users, and they perform encryption and pass encrypted volumes to other block store servers for user access. The encryption context for the volumes can be persisted on the encryption severs for as long as needed for encryption and not shared with the user-facing servers in order to prevent user access to encryption context.

Abstract: A distributed system may include one or more interfaces, such as APIs, allowing a client to request a resource instance and further provide information about the resource instance that can be used to determine a placement domain for resource instance. For example, a compute instance may be placed in a same placement domain as a volume that provides block storage for the compute instance. In some embodiments, a resource placement manager may “jam” place a resource instance in a particular placement domain, wherein the “jam” placement causes one or more placement constraints to be temporarily violated. The resource placement manager may then perform one or more mitigating actions to return the particular placement domain to a state that satisfies the one or more placement constraints.

Abstract: A data storage system includes a rack, multiple head nodes, multiple data storage sleds, and at least two networking devices. The at least two network devices are configured to implement at least two redundant networks within the data storage system. Also, each of the head nodes is assigned at least two network addresses for communication with the data storage sleds of the data storage system via the at least two networking devices. The data storage sleds each include multiple mass storage devices and a sled controller that is configured to couple with the at least two network switches. In some embodiments, the data storage system further includes redundant power systems within a rack in which the head nodes, the data storage sleds, and the at least two networking devices are mounted.

Abstract: Generally described, one or more aspects of the present application correspond to a highly distributed replica of a volume stored in a networked computing environment. First and second replicas of the volume can be synchronously replicated, and some implementations of the tertiary replica can be asynchronously replicated. The highly distributed nature of the tertiary replica supports parallel data transfer of the data of the volume, resulting in faster creation of backups and new copies of the volume.

Abstract: Generally described, one or more aspects of the present application correspond to techniques for creating encrypted block store volumes of data from unencrypted object storage snapshots of the volumes. These encryption techniques use a special pool of servers for performing the encryption. These encryption servers are not accessible to users, and they perform encryption and pass encrypted volumes to other block store servers for user access. The encryption context for the volumes can be persisted on the encryption severs for as long as needed for encryption and not shared with the user-facing servers in order to prevent user access to encryption context.

Abstract: A data storage system stores information indicating a determined sequence for performing operations on a data store. A lock is acquired on a portion of the data store. It is determined that performing the operations comprises performing at least one additional operation on the data store. Uncommitted changes implied by the operations are stored in a transaction buffer according to the determined sequence. Changes implied by the additional operation are determined based on a reentrant call to a data store interface. The logged sequence of changes is applied to the data store and the lock is released.

Abstract: Generally described, one or more aspects of the present application correspond to a highly distributed replica of a volume stored in a networked elastic computing environment. First and second replicas of the volume can be synchronously replicated, and some implementations of the tertiary replica can be asynchronously replicated. The highly distributed nature of the tertiary replica supports parallel data transfer of the data of the volume, resulting in faster creation of backups and new copies of the volume.

Abstract: A data storage system includes multiple head nodes and multiple data storage sleds mounted in a rack. For a particular volume or volume partition one of the head nodes is designated as a primary head node for the volume or volume partition. The primary head node is configured to store data for the volume in a data storage of the primary head node and cause the data to be replicated to a secondary head node. The primary head node is also configured to cause the data for the volume to be stored in a plurality of respective mass storage devices each in different ones of the plurality of data storage sleds of the data storage system.

Abstract: A data storage system includes multiple data storage units and a zonal control plane. The zonal control plane assigns volumes to respective ones of the data storage units. The data storage units include multiple head nodes and data storage sleds. At least one of the head nodes implements a local control plane for the data storage unit. Also, the head nodes of each data storage unit are configured to service read and write requests directed to one or more volumes serviced by the data storage unit independent of the zonal control plane.

Abstract: 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.