EP2426605A1 - Ausführenden Programmen zuverlässigen Zugriff auf nichtlokalen Blockdatenspeicher gewährleisten - Google Patents

Ausführenden Programmen zuverlässigen Zugriff auf nichtlokalen Blockdatenspeicher gewährleisten Download PDF

Info

Publication number
EP2426605A1
EP2426605A1 EP11009559A EP11009559A EP2426605A1 EP 2426605 A1 EP2426605 A1 EP 2426605A1 EP 11009559 A EP11009559 A EP 11009559A EP 11009559 A EP11009559 A EP 11009559A EP 2426605 A1 EP2426605 A1 EP 2426605A1
Authority
EP
European Patent Office
Prior art keywords
data storage
block data
volume
program
copy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP11009559A
Other languages
English (en)
French (fr)
Other versions
EP2426605B1 (de
Inventor
Peter N. Desantes
Matthew S. Garmen
Atle Normann Jorgensen
Roland Paterson-Jones
Tate Andrew Certain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amazon Technologies Inc
Original Assignee
Amazon Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/188,943 external-priority patent/US8015343B2/en
Priority claimed from US12/188,949 external-priority patent/US8019732B2/en
Application filed by Amazon Technologies Inc filed Critical Amazon Technologies Inc
Publication of EP2426605A1 publication Critical patent/EP2426605A1/de
Application granted granted Critical
Publication of EP2426605B1 publication Critical patent/EP2426605B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2056—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring
    • G06F11/2071—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant by mirroring using a plurality of controllers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space

Definitions

  • Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as with the computing systems being co-located (e.g., as part of a local network) or instead located in multiple distinct geographical locations (e.g., connected via one or more private or public intermediate networks).
  • data centers housing significant numbers of co-located interconnected computing systems have become commonplace, such as private data centers that are operated by and on behalf of a single organization, and public data centers that are operated by entities as businesses.
  • Some public data center operators provide network access, power, and secure installation facilities for hardware owned by various customers, while other public data center operators provide "full service" facilities that also include hardware resources made available for use by their customers.
  • the scale and scope of typical data centers and computer networks has increased, the task of provisioning, administering, and managing the associated physical computing resources has become increasingly complicated.
  • virtualization technologies such as those provided by XEN, VMWare, or User-Mode Linux may allow a single physical computing system to be shared among multiple users by providing each user with one or more virtual machines hosted by the single physical computing system, with each such virtual machine being a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators and administrators of a given hardware computing resource, while also providing application isolation and security among the various virtual machines.
  • some virtualization technologies provide virtual resources that span one or more physical resources, such as a single virtual machine with multiple virtual processors that actually spans multiple distinct physical computing systems.
  • Figure 1 is a network diagram illustrating an example embodiment in which multiple computing systems execute programs and access reliable non-local block data storage.
  • FIGS 2A-2F illustrate examples of providing reliable non-local block data storage functionality to clients.
  • Figure 3 is a block diagram illustrating example computing systems suitable for managing the provision to and use by clients of reliable non-local block data storage functionality.
  • Figure 4 illustrates a flow diagram of an example embodiment of a Block Data Storage System Manager routine.
  • Figure 5 illustrates a flow diagram of an example embodiment of a Node Manager routine.
  • Figure 6 illustrates a flow diagram of an example embodiment of a Block Data Storage Server routine.
  • Figures 7A-7B illustrate a flow diagram of an example embodiment of a Program Execution Service System Manager routine.
  • Figure 8 illustrates a flow diagram of an example embodiment of a Block Data Storage Archival Manager routine.
  • the techniques include providing a block data storage service that uses multiple server storage systems to reliably store block data that may be accessed and used over one or more networks by programs executing on other physical computing systems.
  • Users of the block data storage service may each create one or more block data storage volumes that each have a specified amount of block data storage space, and may initiate use of such a block data storage volume (also referred to as a "volume" herein) by one or more executing programs, with at least some such volumes having copies stored by two or more of the multiple server storage systems so as to enhance volume reliability and availability to the executing programs.
  • the multiple server block data storage systems that store block data may in some embodiments be organized into one or more pools or other groups that each have multiple physical server storage systems co-located at a geographical location, such as in each of one or more geographically distributed data centers, and the program(s) that use a volume stored on a server block data storage system in a data center may execute on one or more other physical computing systems at that data center. Additional details related to embodiments of a block data storage service are included below, and at least some of the described techniques for providing a block data storage service may be automatically performed by embodiments of a Block Data Storage ("BDS") System Manager module.
  • BDS Block Data Storage
  • executing programs that access and use one or more such non-local block data storage volumes over one or more networks may each have an associated node manager that manages the access to those non-local volumes by the program, such as a node manager module that is provided by the block data storage service and/or that operates in conjunction with one or more BDS System Manager modules.
  • a first user who is a customer of the block data storage service may create a first block data storage volume, and execute one or more program copies on one or more computing nodes that are instructed to access and use the first volume ( e.g ., in a serial manner, in a simultaneous or other overlapping manner, etc.).
  • a program executing on a computing node may mount or otherwise be provided with a logical block data storage device that is local to the computing node and that represents the non-local volume, such as to allow the executing program to interact with the local logical block data storage device in the same manner as any other local hard drive or other physical block data storage device that is attached to the computing node ( e.g ., to perform read and write data access requests, to implement a file system or database or other higher-level data structure on the volume, etc.).
  • a representative logical local block data storage device may be made available to an executing program via use of GNBD ("Global Network Block Device") technology.
  • the associated node manager may manage those interactions by communicating over one or more networks with at least one of the server block data storage systems that stores a copy of the associated non-local volume (e.g ., in a manner transparent to the executing program and/or computing node) so as to perform the interactions on that stored volume copy on behalf of the executing program.
  • at least some of the described techniques for managing access of executing programs to non-local block data storage volumes are automatically performed by embodiments of a Node Manager module.
  • At least some block data storage volumes may further be stored on one or more remote archival storage systems that are distinct from the server block data storage systems used to store volume copies.
  • the one or more remote archival storage systems may be provided by the block data storage service (e.g ., at a location remote from a data center or other geographical location that has a pool of co-located server block data storage systems), or instead may be provided by a remote long-term storage service and used by the block data storage, and in at least some embodiments the archival storage system may store data in a format other than block data (e.g. , may store one or more chunks or portions of a volume as distinct objects).
  • Such archival storage systems may be used in various manners in various embodiments to provide various benefits, as discussed in greater detail below.
  • users of the block data storage service e.g ., customers of the block data storage service who pay fees to use the block data storage service
  • users of the remote long-term storage service e.g ., customers of the remote long-term storage service who pay fees to use the remote long-term storage service
  • a single organization may provide at least some of both block data storage service capabilities and remote long-term storage service capabilities (e.g.
  • the block data storage service may be provided in environments that do not include the use of archival data storage systems.
  • the use of the archival storage systems is automatically performed under control of one or more archival manager modules, such as an archival manager module provided by the block data storage service or otherwise provided to operate in conjunction with modules of the block data storage service ( e.g ., provided by the remote long-term storage service to interact with the block data storage service).
  • the described techniques are performed on behalf of a program execution service that manages execution of multiple programs on behalf of multiple users of the program execution service.
  • the program execution service may have groups of multiple co-located physical host computing systems in or more geographic locations, such as in one or more geographically distributed data centers, and may execute users' programs on those physical host computing systems, such as under control of a program execution service ("PES") system manager, as discussed in greater detail below.
  • PES program execution service
  • users of the program execution service e.g ., customers of the program execution service who pay fees to use the program execution service
  • who are also users of the block data storage service may execute programs that access and use non-local block data storage volumes provided via the block data storage service.
  • a single organization may provide at least some of both program execution service capabilities and block data storage service capabilities (e.g ., in an integrated manner, such as part of a single service), while in yet other embodiments the block data storage service may be provided in environments that do not include a program execution service (e.g. , internally to a business or other organization to support operations of the organization).
  • host computing systems on which programs execute may have various forms in various embodiments. Multiple such host computing systems may, for example, be co-located in a physical location (e.g ., a data center), and may be managed by multiple node manager modules that are each associated with a subset of one or more of the host computing systems.
  • At least some of the host computing systems may each include sufficient computing resources (e.g ., volatile memory, CPU cycles or other CPU usage measure, network bandwidth, swap space, etc.) to execute multiple programs simultaneously, and, in at least some embodiments, some or all of the computing systems may each have one or more physically attached local block data storage devices (e.g ., hard disks, tape drives, etc.) that can be used to store local copies of programs to be executed and/or data used by such programs. Furthermore, at least some of the host computing systems in some such embodiments may each host multiple virtual machine computing nodes that each may execute one or more programs on behalf of a distinct user, with each such host computing system having an executing hypervisor or other virtual machine monitor that manages the virtual machines for that host computing system.
  • sufficient computing resources e.g ., volatile memory, CPU cycles or other CPU usage measure, network bandwidth, swap space, etc.
  • some or all of the computing systems may each have one or more physically attached local block data storage devices (e.g ., hard disks, tape drives, etc.)
  • the associated node manager module for the host computing system may in some embodiments execute on at least one of multiple hosted virtual machines (e.g ., as part of or in conjunction with the virtual machine monitor for the host computing system), while in other situations a node manager may execute on a physical computing system distinct from one or more other host computing systems being managed.
  • the server block data storage systems on which volumes are stored may also have various forms in various embodiments.
  • multiple such server block data storage systems may, for example, be co-located in a physical location (e.g. , a data center), and may be managed by one or more BDS System Manager modules.
  • some or all of the server block data storage systems may be physical computing systems similar to the host computing systems that execute programs, and in some such embodiments may each execute server storage system software to assist in the provision and maintenance of volumes on those server storage systems.
  • one or more of such server block data storage computing systems may execute at least part of the BDS System Manager, such as if one or more BDS System Manager modules are provided in a distributed peer-to-peer manner by multiple interacting server block data storage computing systems.
  • at least some of the server block data storage systems may be network storage devices that may lack some I/O components and/or other components of physical computing systems, such as if at least some of the provision and maintenance of volumes on those server storage systems is performed by other remote physical computing systems (e.g. , by a BDS System Manager module executing on one or more other computing systems).
  • At least some server block data storage systems each maintains multiple local hard disks, and stripes at least some volumes across a portion of each of some or all of the local hard disks.
  • various types of techniques for creating and using volumes may be used, including in some embodiments to use LVM ("Logical Volume Manager") technology.
  • some or all block data storage volumes each have copies stored on two or more distinct server block data storage systems, such as to enhance reliability and availability of the volumes.
  • failure of a single server block data storage system may not cause access of executing programs to a volume to be lost, as use of that volume by those executing programs may be switched to another available server block data storage system that has a copy of that volume.
  • consistency may be maintained between the multiple copies of a volume on the multiple server block data storage systems in various ways.
  • one of the server block data storage systems is designated as storing the primary copy of the volume
  • the other one or more server block data storage systems are designated as storing mirror copies of the volume
  • the server block data storage system that has the primary volume copy (referred to as the primary server block data storage system" for the volume) may receive and handle data access requests for the volume, and in some such embodiments may further take action to maintain the consistency of the other mirror volume copies (e.g ., by sending update messages to the other server block data storage systems that provide the mirror volume copies when data in the primary volume copy is modified, such as in a master-slave computing relationship manner).
  • volume consistency techniques may be used, with additional details included below.
  • the described techniques include providing reliable and available access of an executing program on a computing node to a block data storage volume by managing use of the primary and mirror copies of the volume.
  • the node manager for the executing program may in some embodiments interact solely with the primary volume copy via the primary server block data storage system, such as if the primary volume copy is responsible for maintaining the mirror volume copies or if another replication mechanism is used.
  • the node manager may automatically switch its interactions to one of the mirror volume copies on a mirror server block data storage system (e.g ., with the executing program being unaware of the switch, other than possibly waiting for a slightly longer time to obtain a response to a data access request made by the executing program if it was that data access request that timed out and initiated the switch to the mirror volume copy).
  • a request sent by the node manager e.g ., a data access request initiated by the executing program, a ping message or other request initiated by the node manager to periodically check that the primary server block data storage system is available, etc.
  • the node manager may automatically switch its interactions to one of the mirror volume copies on a mirror server block data storage system (e.g ., with the executing program being unaware of the switch, other than possibly waiting for a slightly longer time to obtain a response to a data access request made by the executing program if it was that data access request that timed out and initiated the switch to the mirror volume copy).
  • the mirror volume copy may be selected in various ways, such as if it is the only one, if an order in which to access multiple mirror volume copies was previously indicated, by interacting with the BDS System Manager to request an indication of which mirror volume copy is promoted to act as the primary volume copy, etc.
  • at least some volumes may have multiple primary copies, such as if a volume is available for simultaneous read access by multiple executing programs and the resulting data access load is spread across multiple primary copies of the volume - in such embodiments, a node manager may select one of the multiple primary volume copies with which to interact in various ways ( e.g ., in a random manner, based on an instruction from a BDS System Manager module, etc.).
  • the BDS System Manager may take various actions in various embodiments to maintain reliable and available access of an executing program on a computing node to a block data storage volume.
  • the BDS System Manager may take various actions for some or all volumes stored by that server block data storage system (or for the particular unavailable volume) to maintain its availability. For example, for each stored primary volume copy on the unavailable server block data storage system, the BDS System Manager may promote one of the existing mirror volume copies to be the new primary volume copy, and optionally notify one or more node managers of the change ( e.g., the node managers for any executing programs that are currently using the volume).
  • the BDS System Manager may initiate creation of at least one other new mirror copy of the volume on a different server block data storage system, such as by replicating an existing copy of the volume on another available server block data storage system that has an existing copy (e.g. , by replicating the primary volume copy).
  • other benefits may be achieved in at least some situations by using at least portions of a volume that are stored on remote archival storage systems to assist in replicating a new mirror copy of the volume (e.g. , greater data reliability, an ability to minimize an amount of storage used for mirror volume copies and/or ongoing processing power used to maintain full mirror copies of volumes, etc.), as discussed in greater detail below.
  • the BDS System Manager may become aware of the unavailability of a server block data storage system in various ways, such as based on a message from a node manager that cannot contact the server block data storage system, based on a message from the server block data storage system (e.g ., to indicate that it has suffered an error condition, has begun a shutdown or failure mode operation, etc.), based on an inability to contact the server block data storage system (e.g ., based on periodic or constant monitoring of some or all of the server block data storage systems), etc.
  • unavailability of a server block data storage system may be caused by various occurrences in various embodiments, such as failure of one or more hard disks or other storage mediums on which the server block data storage system stores at least a portion of one or more volumes, failure of one or more other components of the server block data storage system (e.g. , the CPU, memory, a fan, etc.), an electrical power failure to the server block data storage system (e.g ., a power failure to a single server block data storage system, to a rack of multiple server block data storage systems, to an entire data center, etc.), a network or other communication failure that prevents the server block data storage system from communicating with a node manager and/or the BDS System Manager, etc.
  • failure of one or more hard disks or other storage mediums on which the server block data storage system stores at least a portion of one or more volumes failure of one or more other components of the server block data storage system (e.g. , the CPU, memory, a fan, etc.), an electrical power failure to the
  • failure of or problems with any component of a server block data storage system may be considered to be an unavailability condition for the entire server block data storage system (e.g ., in embodiments in which a server block data storage system maintains multiple local hard disks, failure of or problems with any of the local hard disks may be considered to be an unavailability condition for the entire server block data storage system), while in other embodiments a server block data storage system will not be considered to be unavailable as long as it is able to respond to data access requests.
  • the BDS System Manager may in some embodiments decide to move one or more volumes from an existing server block data storage system to a different server block data storage system and/or decide to create a new copy of one or more volumes at various other times and for various other reasons.
  • Such a movement of or creation of a new copy of a volume may be performed in a manner similar to that discussed in greater detail elsewhere ( e.g ., by replicating the primary copy of the volume to create a new copy, and by optionally removing the prior copy of the volume in at least some situations, such as when the volume copy is being moved).
  • a particular server block data storage system may become over-utilized (e.g ., based on usage of CPU, network bandwidth, I/O access, storage capacity, etc.), such as to trigger movement of one or more volumes from that server block data storage system;
  • a particular server block data storage system may lack sufficient resources for a desired modification of an existing volume (e.g ., may lack sufficient available storage space if the size of an existing volume is requested to be expanded), such as to trigger movement of one or more volumes from that server block data storage system;
  • a particular server block data storage system may need maintenance or upgrades that will cause it to be unavailable for a period of time, such as to trigger temporary or permanent movement of one or more volumes from that server block data storage system; based on recognition that usage patterns for a particular volume or other characteristics of a volume may be better accommodated on other server block data storage systems, such as another server block data storage system with additional capabilities (e.g ., for volumes
  • the BDS System Manager may in some embodiments and situations update one or more node managers as appropriate (e.g ., only node managers for executing programs currently using the volume, all node managers, etc.).
  • various information about volumes may be maintained in other manners, such as by having one or more copies of a volume information database that is network-accessible to node managers and/or the BDS System Manager.
  • a non-exclusive list of types of information about volumes that may be maintained includes the following: an identifier for a volume, such as an identifier that is unique for the server block data storage systems that store copies of the volume or that is globally unique for the block data storage service; restricted access information for a volume, such as passwords or encryption keys, or lists or other indications of authorized users for the volume; information about the primary server block data storage system for the volume, such as a network address and/or other access information; information about one or more mirror server block data storage systems for the volume, such as information about an ordering that indicates which mirror server block data storage system will be promoted to be the primary system if the existing primary server storage system becomes unavailable, a network address and/or other access information, etc.; information about any snapshot volume copies that have been created for the volume, as described in greater detail below; information about whether the volume is to be available to users other than the creator of the volume, and if so under what circumstances (e.g. , for read access only, for other users to make their own volumes that are copies of this volume,
  • the block data storage service may perform other actions in other situations to maintain access of executing programs to block data storage volumes. For example, if a first executing program unexpectedly becomes unavailable, in some embodiments the block data storage service and/or program execution service may take actions to have a different second executing program (e.g. , a second copy of the same program that is executing on a different host computing system) attach to some or all block data storage volumes that were in use by the unavailable first program, so that the second program can quickly take over at least some operations of the unavailable first program.
  • a different second executing program e.g. , a second copy of the same program that is executing on a different host computing system
  • the second program may in some situations be a new program whose execution is initiated by the unavailability of the existing first program, while in other situations the second program may already be executing ( e.g ., if multiple program copies are concurrently executed to share an overall load of work, such as multiple Web server programs that receive different incoming client requests as mediated by a load balancer, with one of the multiple program copies being selected to be the second program; if the second program is a standby copy of the program that is executing to allow a "hot" swap from the existing first program in the event of unavailability, such as without the standby program copy being actively used until the unavailability of the existing first program occurs; etc.).
  • a second program to which an existing volume's attachment and ongoing use is switched may be on another host physical computing system in the same geographical location (e.g ., the same data center) as the first program, while in other embodiments the second program may be at a different geographical location (e.g ., a different data center, such as in conjunction with a copy of the volume that was previously or concurrently moved to that other data center and will be used by that second program).
  • other related actions may be taken to further facilitate the switch to the second program, such as by redirecting some communications intended for the unavailable first program to the second program.
  • other techniques may be used to provide reliable and available access to block data storage volumes, as well as other benefits, such as to allow a copy of an indicated volume to be saved to one or more remote archival storage systems (e.g ., at a second geographical location that is remote from a first geographical location at which the server block data storage systems store the active primary and mirror copies of the volume and/or that is remote from the host physical computing systems that execute the programs that use the volume), such as for long-term backups and/or other purposes.
  • the archival storage systems may be provided by a remote network-accessible storage service.
  • the copies of a volume that are saved to the archival storage systems may in at least some situations be snapshot copies of the volume at a particular point in time, but which are not automatically updated as ongoing use of the volume causes its stored block data contents to change, and/or which are not available to be attached to and used by executing programs in the same manner as volumes.
  • a long-term snapshot copy of a volume may be used, for example, as a backup copy of a volume, and may further in some embodiments serve as the basis of one or more new volumes that are created from the snapshot copy ( e.g ., such that the new volumes begin with the same block data storage contents as the snapshot copy).
  • the snapshot copies of a volume at the archival storage systems may be stored in various manners, such as to represent smaller chunks of a volume (e.g., if the archival storage systems store data as smaller objects rather than a large linear sequential block of data).
  • a volume may be represented as a series of multiple smaller chunks (with a volume having a size of, for example, one gigabyte or one terabyte, and with a chunk having a size that is, for example, a few megabytes), and information about some or all chunks (e.g ., each chunk that is modified) may be stored separately on the archival storage systems, such as by treating each chunk as a distinct stored object.
  • a second and later snapshot copy of a particular volume may be created in such a manner as to store only incremental changes from a prior snapshot copy of the volume, such as by including stored copies of new storage chunks that have been created or modified since the prior snapshot copy, but sharing stored copies of some previously existing chunks with the prior snapshot copy if those chunks have not changed.
  • a prior snapshot copy is later deleted, the previously existing chunks stored by that prior snapshot copy that are shared by any later snapshot copies may be retained for use by those later snapshot copies, while non-shared previously existing chunks stored by that prior snapshot copy may be deleted.
  • access to the primary volume copy by executing programs may be allowed to continue, including allowing modifications to the data stored in the primary volume copy, but without any such ongoing data modifications being reflected in the snapshot copy, such as if the snapshot copy is based on volume chunks stored on the archival storage systems that are not updated once the snapshot copy creation begins until the snapshot copy creation is completed.
  • copy-on-write techniques are used when creation of a snapshot copy of a volume is initiated and a chunk of the volume is subsequently modified, such as to initially maintain stored copies of both the unmodified chunk and the modified chunk on the primary server block data storage system that stores the primary volume copy (and optionally as well on the mirror server block data storage systems that store one or more of the mirror copies of the volume).
  • the archival storage systems When confirmation is received that the archival storage systems have successfully stored the snapshot copy of the volume (including a copy of the unmodified chunk), the unmodified chunk copy on the primary server block data storage system (and optionally on the mirror server block data storage systems) may then be deleted.
  • volume chunks or other volume data stored on the archival storage systems may be used in other manners in at least some embodiments, such as to use the archival storage systems as a backing store for the primary and/or mirror copies of some or all volumes.
  • volume data stored on the archival storage systems may be used to assist in maintaining consistency between multiple copies of a volume on multiple server block data storage systems in at least some situations.
  • one or more mirror copies of a volume may be created or updated based at least in part on volume chunks stored on the archival storage systems, such as to minimize or eliminate a need to access the primary volume copy to obtain at least some of the volume chunks.
  • a new mirror volume copy may be created by using at least some volume chunks stored on the archival storage systems that are known to be accurate (e.g ., from a recent snapshot volume copy), and by accessing the primary volume copy only to obtain portions of the volume that correspond to chunks that may have been modified subsequent to creation of the snapshot volume copy.
  • the modified chunks on the archival storage systems reliably reflect a current state of a primary volume copy, a mirror volume copy may be updated using those modified chunks rather than via interactions by or with the primary volume copy.
  • the amount of data that is stored in a mirror volume copy may be much less than that of the primary copy of the volume, such as if volume information on the archival storage systems is used in place of at least some data that would otherwise be stored in such a minimal mirror volume copy.
  • a minimal mirror copy of a volume need not in such embodiments store any of the volume data that is present in the snapshot volume copy.
  • some or all of those data modifications may also be made to the minimal mirror volume copy (e.g ., all of the data modifications, only the data modifications that are not reflected in modified volume chunks stored on the archival storage systems, etc.) - then, if access to the minimal mirror volume copy is later needed, such as if the minimal mirror volume copy is promoted to be the primary volume copy, the other data that is missing from the minimal mirror volume copy (e.g. , the non-modified portions of the volume) may be restored by retrieving it from the archival storage systems (e.g. , from the prior snapshot volume copy). In this manner, volume reliability may be enhanced, while also minimizing the amount of storage space used on the server block data storage systems for the mirror volume copies.
  • the definitive or master copy of a volume may be maintained on the archival storage systems, and the primary and mirror copies of the volume may reflect a cache or other subset of the volume (e.g ., a subset that has been recently accessed and/or that is expected to be accessed soon) - in such embodiments, the non-local block data storage volume of the block data storage service may be used to provide a more proximate source of volume data for access by executing programs than the remote archival storage systems.
  • a volume may be described to users as being of a particular size that corresponds to the master copy maintained on the archival storage systems, but with the primary and mirror copies being a smaller size.
  • lazy updating techniques may be used to immediately update a copy of data in a first data store (e.g ., a primary volume copy on a server block data storage system) but to update the copy of that same data in a distinct second data store (e.g. , the archival storage systems) later, such as in a manner to maintain strict data consistency at the second data store by ensuring that write operations or other data modifications to a portion of a volume are updated at the second data store before performing any subsequent read operation or other access of that portion of the volume from the second data store ( e.g. , by using write-back cache updating techniques).
  • a first data store e.g ., a primary volume copy on a server block data storage system
  • a distinct second data store e.g. , the archival storage systems
  • Such lazy updating techniques may be used, for example, when updating modified chunks of a volume on archival storage systems, or when updating a mirror volume copy from modified chunks of the volume that are stored on archival storage systems.
  • other techniques may be used when updating modified chunks of a volume on archival storage systems, such as to use write-through cache techniques to immediately update the copy of data in the second data store ( e.g ., on the archival storage systems) when the copy of the data in the first data store is modified.
  • snapshot volume copies stored on archival storage systems provide various other benefits as well. For example, if all primary and mirror copies of a volume are stored on multiple server block data storage systems at a single geographical location (e.g., a data center), and the computing and storage systems at that geographical location become unavailable (e.g., electricity is lost to an entire data center), the existence of a recent snapshot copy of the volume at a different remote storage location may ensure that a recent version of the volume is available when the computing and storage systems at the geographical location later become available again (e.g., when electricity is restored), such as if data from one or more server storage systems at the geographical location is lost.
  • one or more new copies of the volume may be created at one or more new geographical locations based on a recent long-term snapshot copy of the volume from the remote archival storage systems, such as to allow one or more executing program copies outside an unavailable geographical location to access and use those new volume copies. Additional details related to archival storage systems and their use are included below.
  • some or all block data storage volumes each have copies stored on two or more distinct server block data storage systems at a single geographical location, such as within the same data center in which executing programs will access the volume - by locating all of the volume copies and executing programs at the same data center or other geographical location, various desired data access characteristics may be maintained (e.g., based on one or more internal networks at that data center or other geographical location), such as latency and throughput.
  • the described techniques may provide access to non-local block data storage that has access characteristics that are similar to or better than access characteristics of local physical block data storage devices, but with much greater reliability that is similar to or exceeds reliability characteristics of RAID ("Redundant Array of Independent/Inexpensive Disks") systems and/or dedicated SANs ("Storage Area Networks”) and at much lower cost.
  • RAID Redundant Array of Independent/Inexpensive Disks
  • SANs Storage Area Networks
  • the primary and mirror copies for at least some volumes may instead be stored in other manners, such as at different geographical locations (e.g., different data centers), such as to further maintain availability of a volume even if an entire data center becomes unavailable.
  • volume copies may be stored at different geographical locations
  • a user may in some situations request that a particular program be executed proximate to a particular volume (e.g., at the same data center at which the primary volume copy is located), or that a particular volume be located proximate to a particular executing program, such as to provide relatively high network bandwidth and low latency for communications between the executing program and primary volume copy.
  • access to some or all of the described techniques may in some embodiments be provided in a fee-based or other paid manner to at least some users.
  • users may pay one-time fees, periodic (e.g ., monthly) fees and/or one or more types of usage-based fees to use the block data storage service to store and access volumes, to use the program execution service to execute programs, and/or to use archival storage systems ( e.g ., provided by a remote long-term storage service) to store long-term backups or other snapshot copies of volumes.
  • Fees may be based on one or more factors and activities, such as indicated in the following non-exclusive list: based on the size of a volume, such as to create the volume ( e.g.
  • volume e.g ., a monthly fee
  • server block data storage systems e.g. , data access rates, storage sizes, etc.
  • a first group of one or more users may provide data to other users on a fee-based basis, such as to charge the other users for receiving access to current volumes and/or historical snapshot volume copies created by one or more users of the first group ( e.g. , by allowing them to make new volumes that are copies of volumes and/or of snapshot volume copies; by allowing them to use one or more created volumes; etc.), whether as a one-time purchase fee, an ongoing rental fee, or on another ongoing subscription basis.
  • one or more APIs may be provided by the block data storage service, program execution service and/or remote long-term storage service, such as to allow other programs to programmatically initiate various types of operations to be performed ( e.g. , as directed by users of the other programs).
  • Such operations may allow some or all of the previously described types of functionality to be invoked, and include, but are not limited to, the following types of operations: to create, delete, attach, detach, or describe volumes; to create, delete, copy or describe snapshots; to specify access rights or other metadata for volumes and/or snapshots; to manage execution of programs; to provide payment to obtain other types of functionality; to obtain reports and other information about use of capabilities of one or more of the services and/or about fees paid or owed for such use; etc.
  • the operations provided by the API may be invoked by, for example, executing programs on host computing systems of the program execution service and/or by computing systems of customers or other users that are external to the one or more geographical locations used by the block data storage service and/or program execution service.
  • Figure 1 is a network diagram illustrating an example embodiment in which multiple computing systems execute programs and access reliable non-local block data storage, such as under the control of a block data storage service and/or program execution service.
  • a program execution service manages the execution of programs on various host computing systems located within a data center 100
  • a block data storage service uses multiple other server block data storage systems at the data center to provide reliable non-local block data storage to those executing programs.
  • Multiple remote archival storage systems external to the data center may also be used to store additional copies of at least some portions of at least some block data storage volumes.
  • data center 100 includes a number of racks 105, and each rack includes a number of host computing systems, as well as an optional rack support computing system 122 in this example embodiment.
  • the host computing systems 110a-c on the illustrated rack 105 each host one or more virtual machines 120 in this example, as well as a distinct Node Manager module 115 associated with the virtual machines on that host computing system to manage those virtual machines.
  • One or more other host computing systems 135 also each host one or more virtual machines 120 in this example.
  • Each virtual machine 120 may act as an independent computing node for executing one or more program copies (not shown) for a user (not shown), such as a customer of the program execution service.
  • this example data center 100 further includes additional host computing systems 130a-b that do not include distinct virtual machines, but may nonetheless each act as a computing node for one or more programs (not shown) being executed for a user.
  • a Node Manager module 125 executing on a computing system (not shown) distinct from the host computing systems 130a-b and 135 is associated with those host computing systems to manage the computing nodes provided by those host computing systems, such as in a manner similar to the Node Manager modules 115 for host computing systems 110.
  • the rack support computing system 122 may provide various utility services for other computing systems local to its rack 105 (e.g ., long-term program storage, metering and other monitoring of program execution and/or of non-local block data storage access performed by other computing systems local to the rack, etc.), as well as possibly to other computing systems located in the data center.
  • Each computing system 110, 130 and 135 may also have one or more local attached storage devices (not shown), such as to store local copies of programs and/or data created by or otherwise used by the executing programs, as well as various other components.
  • an optional computing system 140 is also illustrated that executes a PES System Manager module for the program execution service to assist in managing the execution of programs on the computing nodes provided by the host computing systems located within the data center (or optionally on computing systems located in one or more other data centers 160, or other remote computing systems 180 external to the data center).
  • a PES System Manager module may provide a variety of services in addition to managing execution of programs, including the management of user accounts (e.g ., creation, deletion, billing, etc.); the registration, storage, and distribution of programs to be executed; the collection and processing of performance and auditing data related to the execution of programs; the obtaining of payment from customers or other users for the execution of programs; etc.
  • the PES System Manager module may coordinate with the Node Manager modules 115 and 125 to manage program execution on computing nodes associated with the Node Manager modules, while in other embodiments the Node Manager modules 115 and 125 may not assist in managing such execution of programs.
  • This example data center 100 also includes a computing system 175 that executes a Block Data Storage ("BDS") System Manager module for the block data storage service to assist in managing the availability of non-local block data storage to programs executing on computing nodes provided by the host computing systems located within the data center (or optionally on computing systems located in one or more other data centers 160, or other remote computing systems 180 external to the data center).
  • BDS Block Data Storage
  • the data center 100 includes a pool of multiple server block data storage systems 165, which each have local block storage for use in storing one or more volume copies 155. Access to the volume copies 155 is provided over the internal network(s) 185 to programs executing on computing nodes 120 and 130.
  • a BDS System Manager module may provide a variety of services related to providing non-local block data storage functionality, including the management of user accounts (e.g. , creation, deletion, billing, etc.); the creation, use and deletion of block data storage volumes and snapshot copies of those volumes; the collection and processing of performance and auditing data related to the use of block data storage volumes and snapshot copies of those volumes; the obtaining of payment from customers or other users for the use of block data storage volumes and snapshot copies of those volumes; etc.
  • the BDS System Manager module may coordinate with the Node Manager modules 115 and 125 to manage use of volumes by programs executing on associated computing nodes, while in other embodiments the Node Manager modules 115 and 125 may not be used to manage such volume use.
  • one or more BDS System Manager modules may be structured in other manners, such as to have multiple instances of the BDS System Manager executing in a single data center ( e.g. , to share the management of non-local block data storage by programs executing on the computing nodes provided by the host computing systems located within the data center), and/or such as to have at least some of the functionality of a BDS System Manager module being provided in a distributed manner by software executing on some or all of the server block data storage systems 165 ( e.g. , in a peer-to-peer manner, without any separate centralized BDS System Manager module on a computing system 175).
  • the data center 100 is connected via the external network 170 to one or more other data centers 160 that each may include some or all of the computing systems and storage systems illustrated with respect to data center 100, as well as other remote computing systems 180 external to the data center.
  • the other computing systems 180 may be operated by various parties for various purposes, such as by the operator of the data center 100 or third parties (e.g. , customers of the program execution service and/or of the block data storage service).
  • one or more of the other computing systems 180 may be archival storage systems (e.g ., as part of a remote network-accessible storage service) with which the block data storage service may interact, such as under control of one or more archival manager modules (not shown) that execute on the one or more other computing systems 180 or instead on one or more computing systems of the data center 100, as described in greater detail elsewhere.
  • archival storage systems e.g ., as part of a remote network-accessible storage service
  • archival manager modules not shown
  • At least some of the server block data storage systems 165 may further be inter-connected with one or more other networks or other connection mediums, such as a high-bandwidth connection over which the server storage systems 165 may share volume data (e.g ., for purposes of replicating copies of volumes and/or maintaining consistency between primary and mirror copies of volumes), with such a high-bandwidth connection not being available to the various host computing systems 110, 130 and 135 in at least some such embodiments.
  • a high-bandwidth connection over which the server storage systems 165 may share volume data (e.g ., for purposes of replicating copies of volumes and/or maintaining consistency between primary and mirror copies of volumes), with such a high-bandwidth connection not being available to the various host computing systems 110, 130 and 135 in at least some such embodiments.
  • Figure 1 has been simplified for the purposes of explanation, and that the number and organization of host computing systems, server block data storage systems and other devices may be much larger than what is depicted in Figure 1 .
  • there may be approximately 4000 computing systems per data center with at least some of those computing systems being host computing systems that may each host 15 virtual machines, and/or with some of those computing systems being server block data storage systems that may each store several volume copies. If each hosted virtual machine executes one program, then such a data center may execute as many as sixty thousand program copies at one time.
  • hundreds or thousands (or more) volumes may be stored on the server block data storage systems, depending on the number of server storage systems, size of the volumes, and number of mirror copies per volume. It will be appreciated that in other embodiments, other numbers of computing systems, programs and volumes may be used.
  • Figures 2A-2F illustrate examples of providing reliable non-local block data storage functionality to clients.
  • Figures 2A and 2B illustrate examples of server block data storage computing systems that may be used to provide reliable non-local block data storage functionality to clients (e.g. , executing programs), such as on behalf of a block data storage service
  • Figures 2C-2F illustrate examples of using archival storage systems to store at least some portions of some block data storage volumes.
  • Figure 2A illustrates several server block data storage systems 165 that each store one or more volume copies 155, such as with each volume having a primary copy and at least one mirror copy.
  • other arrangements may be used, as discussed in greater detail elsewhere, such as by having multiple primary volume copies (e.g.
  • the example server block data storage systems 165 and volume copies 155 may, for example, correspond to a subset of the server block data storage systems 165 and volume copies 155 of Figure 1 .
  • server block data storage system 165a to access the primary copy 155A-a for volume A, such as via server storage system software (not shown) that executes on the server block data storage system 165a.
  • server block data storage systems 165b and 165n respectively, to access the primary copies 155B-b for volume B and 155D-n for volume D, respectively.
  • other server block data storage systems may further be present (e.g.
  • each server block data storage system may store more than one volume copy, and may store a combination of primary and mirror volume copies, although in other embodiments volumes may be stored in other manners.
  • Figure 2B illustrates server block data storage systems 165 similar to those of Figure 2A , but at a later point in time after server storage system 165b of Figure 2A has failed or otherwise become unavailable.
  • the stored volume copies of the server storage systems 165 of Figure 2B have been modified to maintain availability of volumes B and D.
  • the prior mirror copy 155B-a of volume B on server storage system 165a has been promoted to be the new primary copy for volume B.
  • mirror copy 155A-n of volume A of server storage system 165n of Figure 2A is not illustrated in Figure 2B for the sake of brevity, it continues to be available on server storage system 165n along with the primary copy 155D-n of volume D, and thus any programs that were previously attached to or otherwise interacting with the primary copy 155D-n of volume D when server storage system 165b became unavailable will continue to interact with that same primary volume D copy 155D-n on server storage system on server storage system 165n without modification.
  • Figure 2B illustrates that at least some volumes may have multiple mirror copies, such as volume D that also includes a previously existing (but not shown in Figure 2A ) volume D mirror copy 155D-c on server storage system 165c.
  • Figures 2C-2F illustrate examples of using archival storage systems to store at least some portions of some block data storage volumes.
  • Figure 2C illustrates multiple server block data storage systems 165 that each store one or more volume copies 155, such as to correspond to the example server block data storage systems 165 illustrated in Figure 2A at a time before server block data storage system 165b becomes unavailable.
  • Figure 2C further illustrates multiple archival storage systems 180, which may, for example, correspond to a subset of the computing systems 180 of Figure 1 .
  • Figure 2C illustrates server block data storage systems 165a and 165b of Figure 2A , although in this example only the primary and mirror copies of volume B are illustrated for those server block data storage systems.
  • the server storage system 165b stores the primary copy 155B-b of volume B
  • server storage system 165a stores the mirror copy 155B-a of volume B.
  • volume B has been separated into multiple chunk portions that will each be stored separately by the archival storage systems, such as to correspond to a typical or maximum storage size for the archival storage systems, or instead in another manner as determined by the block data storage service.
  • the primary copy 155B-b of volume B has been separated into N chunks 155B-b1 through 155B-bN, and the mirror copy 155B-a of volume B similarly stores the same data using chunks 155B-a1 through 155BaN.
  • Each of the N chunks of volume B is stored as a separate data object on one of two example archival storage systems 180a and 180b, and thus those multiple corresponding stored data objects in aggregate form the initial snapshot volume copy for volume B.
  • chunk 1 155B-b1 of the primary volume B copy is stored as data object 180B1 on archival storage system 180a
  • chunk 2 155B-b2 is stored as data object 180B2 on archival storage system 180b
  • chunk 3 155B-b3 is stored as data object 180B3 on archival storage system 180a
  • chunk N 155B-bN is stored as data object 180BN on archival storage system 180a.
  • volume B is separated into multiple chunks by the block data storage service, such that individual chunks of volume B may be individually transferred to the archival storage systems, although in other embodiments the entire volume B may instead be sent to the archival storage systems, which may then separate the volume into multiple chunks or otherwise process the volume data if so desired.
  • the archival storage system 180b is an archival storage computing system that executes an Archival Manager module 190 to manage operations of the archival storage systems, such as to manage the storage and retrieval of data objects, to track which stored data objects correspond to which volumes, to separate transferred volume data into multiple data objects, to meter and otherwise track use of the archival storage systems, etc.
  • the Archival Manager module 190 may, for example, maintain a variety of information about the various data objects that correspond to a particular volume, such as for each snapshot copy of the volume, as discussed in greater detail with respect to Figure 2F , while in other embodiments such snapshot volume copy information may instead be maintained in other manners ( e.g. , by the server block data storage systems or other modules of the block data storage service).
  • each archival storage system may execute at least part of an archival manager module, such as for each archival storage system to have a distinct archival manager module, or for all of the archival storage systems to provide the functionality of the archival manager module in a distributed peer-to-peer manner.
  • one or more archival manager modules may instead execute on one or more computing systems that are local to the other block data storage service modules (e.g ., on the same computing system or a proximate computing system to one that executes a BDS System Manager module), or the operations of the archival storage systems may instead be managed directly by one or more other modules of the block data storage service without using an archival manager module (e.g ., by a BDS System Manager module).
  • the archival storage systems may perform various operations to enhance reliability of stored data objects, such as to replicate some or all data objects on multiple archival storage systems.
  • the other data objects 182b of archival storage system 180b may include mirror copies of one or more of the data objects 180B1, 180B3, and 180BN of archival storage system 180a, and the other data objects 182a of archival storage system 180a may similarly store a mirror copy of data object 180B2 of archival storage system 180b.
  • At least some chunks of volume B may already be stored on the archival storage systems before the request to create the initial snapshot copy of volume B is received, such as if the data objects stored on the archival storage systems to represent the volume B chunks are used as a backing store or other remote long-term backup for volume B. If so, the snapshot copy on the archival storage systems may instead be created without transferring any additional volume data at that time, such as if the data objects on the archival storage systems represent a current state of the volume B chunks, while in other embodiments additional steps may be taken to ensure that the already stored data objects are up to date with respect to the volume B chunks.
  • Figure 2D continues the example of Figure 2C , and reflects modifications to volume B that are performed after the initial snapshot copy is stored with respect to Figure 2C .
  • volume B is modified, such as by one or more programs (not shown) that are attached to the volume.
  • data is modified in at least two portions of volume B that correspond to chunk 3 155B-b3 and chunk N 155B-bN of the primary volume B copy, with the modified chunk data being illustrated as data 3a and Na, respectively.
  • the server storage system 165b initiates corresponding updates of the mirror volume B copy 155B-a on server storage system 165a, such that chunk 3 155B-a3 of the mirror copy is modified to include the modified 3a data, and chunk N 1558-aN of the mirror copy is modified to include the modified Na data.
  • the mirror volume B copy is maintained in the same state as that of the primary volume B copy in this example.
  • data on the archival storage systems may be further modified to reflect the changes to volume B, even though those new volume B data modifications are not currently part of any snapshot volume copy for volume B.
  • the corresponding data objects 180B3 and 180BN are not modified to reflect the changes to the volume B data that occurs subsequent to the initial snapshot volume copy creation.
  • copies are optionally made of the modified volume B data, they are instead stored in this example as additional data objects, such as optional data object 180B3a to correspond to the modified 3a data of chunk 3 155B-b3, and such as optional data object 180BNa to correspond to the modified Na data of chunk N 155B-bN.
  • additional data objects such as optional data object 180B3a to correspond to the modified 3a data of chunk 3 155B-b3, and such as optional data object 180BNa to correspond to the modified Na data of chunk N 155B-bN.
  • the optional data objects 180B3a and 180BNa are created, that creation may be initiated in various ways, such as by the server block data storage system 165b in a similar manner to the updates that are initiated for the mirror volume B copy 155B-a.
  • Figure 2E illustrates an alternative embodiment with respect to the embodiment described previously with respect to Figure 2D .
  • volume B is again modified after the initial snapshot copy of the volume is stored on the archival storage systems in a manner similar to that discussed with respect to Figure 2D , and accordingly the primary copy 155B-b of volume B on server storage system 165b is updated so that chunk 3 155B-b3 and chunk N 155B-bN are updated to include the modified data 3a and Na, respectively.
  • the mirror copy 155B-a of volume B on server storage system 165a is not maintained as a full copy of volume B.
  • the snapshot volume copy of volume B on the archival storage systems is used in conjunction with the mirror copy 155B-a to maintain a copy of volume B.
  • modifications are made to the primary copy 155B-b of volume B after the creation of the initial snapshot volume copy, those modifications are also made for the mirror copy 155B-a on server storage system 165a, such that the mirror copy stores the modified 3a data for chunk 3 155B-a3 and the modified Na data for chunk N 155B-aN.
  • the mirror copy of volume B does not initially store copies of the other chunks of volume B that have not been modified since the initial snapshot volume copy was created, since the snapshot volume copy of volume B on the archival storage systems includes copies of that data.
  • the mirror copy 155B-a of volume B on server storage system 165a may be promoted to be the new primary copy of volume B.
  • the remaining portions of the mirror copy 155B-a of volume B are restored using the initial snapshot volume copy of volume B on the archival storage systems, such as to use the stored data object 180B1 to restore chunk 155B-a1, to use the stored data object 180B2 to restore the chunk 155B-a2, etc.
  • the data objects 180B3a and 180BNa may similarly be optionally stored on the archival storage systems to represent the modified 3a and Na data.
  • the modified 3a and Na data will also not be initially stored on the server block data storage system 165a for the mirror copy 155B-a, and instead the mirror copy chunks 155B-a3 and 155B-aN may similarly be restored from the archival storage system data objects 180B3a and 180BNa in a manner similar to that previously described for the other mirror copy chunks.
  • the snapshot volume copy of volume B is used in the prior example to restore the mirror copy of volume B when the mirror copy is promoted to be the new primary volume copy
  • the snapshot volume copy on the archival storage systems may be used in other manners in other embodiments.
  • a new copy of volume B that matches the initial snapshot volume copy may be created using the snapshot volume copy on the archival storage systems in a manner similar to that previously described for restoring the mirror volume copy, such as to create a new mirror copy of volume B as of the time of the snapshot volume copy, to create an entirely new volume that is based on the snapshot volume copy of volume B, to assist in moving volume B from one server block storage system to another, etc.
  • the remote archival storage systems may be available to all those server block data storage systems, and thus may be used to create a new volume copy based on a snapshot volume copy in any of those geographical locations.
  • Figure 2F continues the examples of Figures 2C and 2D , continuing at a later point in time after additional modifications are made to volume B.
  • a second snapshot volume copy of volume B is created on the archival storage systems. Subsequently, additional modifications are made to data in volume B that are stored in chunks 2 and 3.
  • the primary copy of volume B 155B-b as illustrated in Figure 2F includes original data 1 in chunk 1 155B-b1, data 2a in chunk 2 155B-b2 that is modified subsequent to creation of the second snapshot volume copy, data 3b in chunk 3 155B-b3 that is also modified subsequent to creation of the second snapshot volume copy, and data Na in chunk N 155B-bN that was modified after creation of the initial first snapshot volume copy but subsequent to creation of the second snapshot volume copy.
  • additional data objects are created in the archival storage systems to correspond to the two chunks modified since the creation of the second snapshot volume copy, with data object 180B2a corresponding to chunk 155B-b2 and including modified data 2a, and chunk 180B3b corresponding to chunk 155B-b3 and including modified data 3b.
  • the server block data storage system 165a is not shown, but a copy of information 250 maintained by the Archival Manager module 190 (e.g., stored on the archival storage system 180b or elsewhere) is shown to provide information about snapshot volume copies stored on the archival storage systems.
  • the information 250 includes multiple rows 250a-250d, which each correspond to a distinct snapshot volume copy.
  • Each of the rows of information in this example includes a unique identifier for the volume copy, an indication of the volume to which the snapshot volume copy corresponds, and an indication of an ordered list of the data objects stored on the archival storage systems that comprise the snapshot volume copy.
  • row 250a corresponds to the initial snapshot volume copy of volume B discussed with respect to Figure 2C , and indicates that the initial snapshot volume copy includes stored data objects 180B1, 180B2, 180B3, and so on through 180BN.
  • Row 250b corresponds to an example snapshot volume copy for a different volume A that includes various stored data objects that are not shown in this example.
  • Row 250c corresponds to the second snapshot volume copy of volume B
  • row 250d corresponds to the third snapshot volume copy of volume B.
  • the second and third volume copies for volume B are incremental copies rather than full copies, such that chunks of volume B that have not changed since a prior snapshot volume copy will continue to be represented using the same stored data objects.
  • the second snapshot copy of volume B in row 250c indicates that the second snapshot volume copy shares data objects 180B1 and 180B2 with that of the initial snapshot volume copy of volume B (and possibly some or all of the data objects for chunks 4 through chunks N-1, not shown).
  • the third snapshot copy of volume B shown in row 250d also continues to use the same data object 180B1 as the initial and second snapshot volume copies.
  • snapshot volume copies By sharing common data objects between multiple snapshot volume copies, the amount of storage on the archival storage systems is minimized, since a new copy of an unchanging volume chunk such as chunk 1 does not have separate copies on the archival storage systems for each snapshot volume copy.
  • some or all snapshot volume copies may not be incremental, instead each including a separate copy of each volume chunk regardless of whether the data in the chunk has changed.
  • incremental snapshot volume copies when incremental snapshot volume copies are used that may share one or more overlapping data objects with one or more other snapshot volume copies, the overlapping data objects are managed when additional types of operations are taken with respect to the snapshot volume copies.
  • the information 250 may include a variety of other types of information about the snapshot volume copies, including information about which archival storage system stores each of the data objects, information about who is allowed to access the snapshot volume copy information and under what circumstances, etc.
  • some users may create snapshot volume copies and make access to those snapshot volume copies available to at least some other users in at least some circumstances, such as on a fee-based basis to allow the other users to create copies of one or more particular snapshot volume copies. If so, such access-related information may be stored in information 250 or elsewhere, and the archival manager module 190 may use such information to determine whether to satisfy requests made for information corresponding to particular snapshot volume copies.
  • the access to the snapshot volume copies may instead be managed by other modules of the block data storage service (e.g., a BBS System Manager module), such as to prevent requests from being sent to the archival storage systems unless those requests are authorized.
  • a BBS System Manager module e.g., a BBS System Manager module
  • Figures 2A-2F have been simplified for the purposes of explanation, and that the number and organization of server block data storage systems; archival storage systems, and other devices may be much larger than what is depicted. Similarly, in other embodiments, primary volume copies, mirror volume copies, and/or snapshot volume copies may be stored and managed in other manners.
  • FIG. 3 is a block diagram illustrating example computing systems suitable for managing the provision and use of reliable non-local block data storage functionality to clients.
  • a server computing system 300 executes an embodiment of a BDS System Manager module 340 to manage provision of non-local block data storage functionality to programs executing on host computing systems 370 and/or on at least some other computing systems 390, such as to block data storage volumes (not shown) provided by the server block data storage systems 360.
  • Each of the host computing systems 370 in this example also executes an embodiment of a Node Manager module 380 to manage access of programs 375 executing on the host computing system to at least some of the non-local block data storage volumes, such as in a coordinated manner with the BDS System Manager module 340 over a network 385 (e.g., an internal network of a data center, not shown, that includes the computing systems 300, 360, 370, and optionally at least some of the other computing systems 390).
  • a network 385 e.g., an internal network of a data center, not shown, that includes the computing systems 300, 360, 370, and optionally at least some of the other computing systems 390.
  • some or all of the Node Manager modules 380 may instead manage one or more other computing systems (e.g., other computing systems 390).
  • server block data storage systems 360 are illustrated that each store at least some of the non-local block data storage volumes (not shown) used by the executing programs 375, with access to those volumes also provided over the network 385 in this example.
  • One or more of the server block data storage systems 360 may also each store a server software component (not shown) that manages operation of one or more of the server block data storage systems 360, as well as various information (not shown) about the data that is stored by the server block data storage systems 360.
  • the server computing system 300 of Figure 3 may correspond to the computing system 175 of Figure 1
  • one or more of the Node Manager modules 115 and 125 of Figure 1 may correspond to the Node Manager modules 380 of Figure 3
  • one or more of the server block data storage computing systems 360 of Figure 3 may correspond to server block data storage systems 165 of Figure 1
  • multiple archival storage systems 350 are illustrated, which may store snapshot copies and/or other copies of at least portions of at least some block data storage volumes stored on the server block data storage systems 360.
  • the archival storage systems 350 may also interact with some or all of the computing systems 300, 360, and 370, and in some embodiments may be remote archival storage systems (e.g ., of a remote storage service, not shown) that interact with the computing systems 300, 360, and 370 over one or more other external networks (not shown).
  • remote archival storage systems e.g ., of a remote storage service, not shown
  • the other computing systems 390 may further include other proximate or remote computing systems of various types in at least some embodiments, including computing systems via which customers or other users of the block data storage service interact with the computing systems 300 and/or 370. Furthermore, one or more of the other computing systems 390 may further execute a PES System Manager module to coordinate execution of programs on the host computing systems 370 and/or other host computing systems 390, or computing system 300 or one of the other illustrated computing systems may instead execute such a PES System Manager module, although a PES System Manager module is not illustrated in this example.
  • computing system 300 includes a CPU (“central processing unit”) 305, local storage 320, memory 330, and various I/O ("input/output") components 310, with the illustrated I/O components in this example including a display 311, a network connection 312, a computer-readable media drive 313, and other I/O devices 315 ( e.g ., a keyboard, mouse, speakers, microphone, etc.).
  • the BDS System Manager module 340 is executing in memory 330, and one or more other programs (not shown) may also optionally be executing in memory 330.
  • Each computing system 370 similarly includes a CPU 371, local storage 377, memory 374, and various I/O components 372 (e.g ., I/O components similar to I/O components 310 of server computing system 300).
  • a Node Manager module 380 is executing in memory 374 in order to manage one or more other programs 375 executing in memory 374 on the computing system, such as on behalf of customers of the program execution service and/or block data storage service.
  • some or all of the computing systems 370 may host multiple virtual machines, and if so, each of the executing programs 375 may be an entire virtual machine image (e.g ., with an operating system and one or more application programs) executing on a distinct hosted virtual machine computing node.
  • the Node Manager module 380 may similarly be executing on another hosted virtual machine, such as a privileged virtual machine monitor that manages the other hosted virtual machines.
  • the executing program copies 375 and the Node Manager module 380 may execute as distinct processes on a single operating system (not shown) executed on computing system 370.
  • Each archival storage system 350 in this example is a computing system that includes a CPU 351, local storage 357, memory 354, and various I/O components 352 (e.g ., I/O components similar to I/O components 310 of server computing system 300).
  • an Archival Manager module 355 is executing in memory 354 in order to manage operation of one or more of the archival storage systems 350, such as on behalf of customers of the block data storage service and/or of a distinct storage service that provides the archival storage systems.
  • the Archival Manager module 355 may instead be executing on another computing system, such as one of the other computing systems 390 or on computing system 300 in conjunction with the BDS System Manager module 340.
  • each of the server block data storage systems 360 and/or other computing systems 390 may similarly include some or all of the types of components illustrated with respect to the archival storage systems 350, such as a CPU, local storage, memory, and various I/O components.
  • the BDS System Manager module 340 and Node Manager modules 380 may take various actions to manage the provision and use of reliable non-local block data storage functionality to clients (e.g ., executing programs), as described in greater detail elsewhere.
  • the BDS System Manager module 340 may maintain a database 325 on storage 320 that includes information about volumes stored on the server block data storage systems 360 and/or on the archival storage systems 350 (e.g., for use in managing the volumes), and may further store various other information (not shown) about users or other aspects of the block data storage service.
  • information about volumes may be stored in other manners, such as in a distributed manner by Node Manager modules 380 on their computing systems and/or by other computing systems.
  • each Node Manager module 380 on a host computing system 370 may store information 378 on local storage 377 about the current volumes attached to the host computing system and used by the executing programs 375 on the host computing system, such as to coordinate interactions with the server block data storage systems 360 that provide the primary copies of the volumes, and to determine how to switch to a mirror copy of a volume if the primary volume copy becomes unavailable.
  • each host computing system may further include a distinct logical local block data storage device interface for each volume attached to the host computing system and used by a program executing on the computing system, which may further appear to the executing programs as being indistinguishable from one or more other local physically attached storage devices that provide local storage 377.
  • computing systems 300, 350, 360, 370 and 390 are merely illustrative and are not intended to limit the scope of the present invention.
  • computing systems 300, 350, 360, 370 and/or 390 may be connected to other devices that are not illustrated, including through network 385 and/or one or more other networks, such as the Internet or via the World Wide Web ("Web").
  • a computing node or other computing system or data storage system may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation desktop or other computers, database servers, network storage devices and other network devices, PDAs, cellphones, wireless phones, pagers, electronic organizers, Internet appliances, television-based systems (e.g.
  • the functionality provided by the illustrated modules may in some embodiments be combined in fewer modules or distributed in additional modules. Similarly, in some embodiments, the functionality of some of the illustrated modules may not be provided and/or other additional functionality may be available.
  • some or all of the systems and/or modules may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to, one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers ( e.g ., by executing appropriate instructions, and including microcontrollers and/or embedded controllers), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc.
  • ASICs application-specific integrated circuits
  • controllers e.g ., by executing appropriate instructions, and including microcontrollers and/or embedded controllers
  • FPGAs field-programmable gate arrays
  • CPLDs complex programmable logic devices
  • Some or all of the modules, systems and data structures may also be stored (e.g. , as software instructions or structured data) on a computer-readable medium, such as a hard disk, a memory, a network, or a portable media article to be read by an appropriate drive or via an appropriate connection.
  • the systems, modules and data structures may also be transmitted as generated data signals (e.g. , as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (e.g ., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames).
  • Such computer program products may also take other forms in other embodiments. Accordingly, the present invention may be practiced with other computer system configurations.
  • Figure 4 is a flow diagram of an example embodiment of a Block Data Storage System Manager routine 400.
  • the routine may be provided by, for example, execution of the Block Data Storage System Manager module 175 of Figure 1 and/or the BDS System Manager module 340 of Figure 3 , such as to provide a block data storage service for use by executing programs.
  • the routine may interact with multiple server block data storage systems at a single data center or other geographical location (e.g. , if each such data center or other geographical location has a distinct embodiment of the routine executing at the geographical location), although in other embodiments a single routine 400 may support multiple distinct data centers or other geographical locations.
  • the illustrated embodiment of the routine begins at block 405, where a request or other information is received.
  • the routine continues to block 410 to determine whether the received request was to create a new block data storage volume, such as from a user of the block data storage service and/or from an executing program that would like to access the new volume, and if so continues to block 415 to perform the volume creation.
  • the routine in block 415 selects one or more server block data storage system on which copies of the volume will be stored ( e.g ., based at least in part on location of and/or capabilities of the selected server storage systems), initializes the volume copies on those selected server storage systems, and updates stored information about volumes to reflect the new volume.
  • the creation of a new volume may include initializing a specified size of linear storage on each of the selected servers in a specified manner, such as to be blank, to include a copy of another indicated volume (e.g. , another volume at the same data center or other geographical location, or instead a volume stored at a remote location), to include a copy of an indicated snapshot volume copy (e.g ., a snapshot volume copy stored by one or more archival storage systems, such as by interacting with the archival storage systems to obtain the snapshot volume copy), etc.
  • another indicated volume e.g., another volume at the same data center or other geographical location, or instead a volume stored at a remote location
  • an indicated snapshot volume copy e.g ., a snapshot volume copy stored by one or more archival storage systems, such as by interacting with the archival storage systems to obtain the snapshot volume copy
  • a logical block of linear storage of a specified size for a volume may be created on one or more server block data storage systems, such as by using multiple non-contiguous storage areas that are presented as a single logical block and/or by striping a logical block of linear storage across multiple local physical hard disks.
  • the routine may, for example, coordinate with another instance of the routine 400 that supports block data storage service operations at that location.
  • at least some volumes will each have multiple copies that include at least one primary volume copy and one or more mirror copies on multiple distinct server storage systems, and if so multiple server storage systems may be selected and initialized.
  • the routine continues instead to block 420 to determine whether the received request is to attach an existing volume to an executing program copy, such as a request received from the executing program copy or from another computing system operated on behalf of a user associated with the executing program copy and/or the indicated volume. If so, the routine continues to block 425 to identify at least one of the server block data storage systems that stores a copy of the volume, and to associate at least one of the identified server storage systems with the executing program ( e.g ., to associate the primary server storage system for the volume with the computing node on which the program executes, such as by causing a logical local block storage device to be mounted on the computing node that represents the primary volume copy).
  • an executing program copy such as a request received from the executing program copy or from another computing system operated on behalf of a user associated with the executing program copy and/or the indicated volume. If so, the routine continues to block 425 to identify at least one of the server block data storage systems that stores a copy of the volume, and to associate at least one of
  • the volume to be attached may be identified in various ways, such as by a unique identifier for the volume and/or an identifier for a user who created or is otherwise associated with the volume.
  • the routine may further update stored information about the volume to indicate the attachment of the executing program, such as if only a single program is allowed to be attached to the volume at a time, or if only a single program is allowed to have write access or other modification access to the volume at a time.
  • information about at least one of the identified server storage systems may be provided to a node manager associated with the executing program, such as to facilitate the actual attachment of the volume to the executing program, although in other embodiments the node manager may have other access to such information.
  • a snapshot volume copy may be created of a volume regardless of whether the volume is attached or in use by any executing programs, and/or regardless of whether the volume is stored at the same data center or other geographical location at which the routine 400 executes.
  • the routine continues to block 435 to initiate creation of a snapshot volume copy of the indicated volume, such as by interacting with one or more archival manager modules that coordinate operations of one or more archival storage systems (e.g ., archival storage systems at a remote storage location, such as in conjunction with a remote long-term storage service that is accessible over one or more networks,
  • the snapshot volume copy creation may be performed by a third-party remote storage service in response to an instruction from the routine 400, such as if the remote storage service already stores at least some chunks of the volume.
  • various other parameters may further be specified in at least some embodiments, such as whether the snapshot volume copy is to be incremental with respect to one or more other snapshot volume copies, etc.
  • the routine continues instead to block 440 to determine whether the information received in block 405 is an indication of failure or other unavailability of one or more server block data storage systems (or of one or more volumes, in other embodiments). For example, as described below with respect to block 485, the routine may in some embodiments monitor the status of some or all of the server block data storage systems and determine unavailability on that basis, such as by periodically or constantly sending ping messages or other messages to server block data storage systems to determine if a response is received, or by otherwise obtaining information about the status of the server storage systems.
  • routine continues to block 445 to take actions to maintain the availability of the one or more volumes stored on the indicated one or more server storage systems.
  • the routine in block 445 determines whether any such volumes stored on the indicated one or more server storage systems are primary volume copies, and for each such primary volume copy, promotes one of the mirror copies for that volume on another server storage system to be the new primary copy for that volume.
  • the routine then causes at least one new copy of each volume to be replicated on one or more other server storage systems, such as by using an existing copy of the volume that is available on a server storage system other than one of those indicated to be unavailable.
  • the promotion of mirror copies to primary copies and/or the creation of new mirror copies may instead be performed in other manners, such as in a distributed manner by the server block data storage systems (e.g ., using an election protocol between the mirror copies of a volume).
  • the mirror volume copies may be minimal copies that include only portions of a primary copy of a volume (e.g. , only portions that have been modified since a snapshot copy of the volume was previously created), and the promotion of a mirror copy to a primary copy may further include gathering information for the new primary copy to make it complete (e.g., from the most recent snapshot copy).
  • the routine then optionally initiates attachments of one or more executing programs to any new primary volume copies that were promoted from mirror copies, such as for executing programs that were previously attached to primary volume copies on the one or more unavailable server storage systems, although in other embodiments such re-attachment to new primary volume copies will instead be performed in other manners ( e.g ., by a node manager associated with the executing program for which the re-attachment will occur).
  • the routine then updates information about the volumes on the unavailable server storage systems, such as to indicate the new volume copies created in block 450 and the new primary volume copies promoted in block 445.
  • new primary volume copies may be created in other manners, such as by creating a new volume copy as a primary volume copy, rather than promoting an existing mirror volume copy, although doing so may take longer than promoting an existing mirror volume copy.
  • the routine may in some embodiments attempt to obtain information for the volume to use in such replication in other manners, such as from one or more recent snapshot volume copies for the volume that are available on archival storage systems, from a copy of the volume at another data center or other geographical location, etc.
  • the routine continues instead to block 460 to determine whether information received in block 405 indicates to move one or more volumes to one or more new server block data storage systems.
  • Such volume movement may be performed for a variety of reasons, as discussed in greater detail elsewhere, including to other server block data storage systems at the same geographical location (e.g ., to move existing volumes to storage systems that are better equipped to support the volumes) and/or to one or more server data storage systems at one or more other data centers or other geographical locations.
  • movement of a volume may be initiated in various ways, such as due to a request from a user of the block data storage system that is associated with the volume, to a request from a human operator of the block data storage service, based on an automated detection of a better server storage system for a volume than the current server storage system being used ( e.g. , due to over-utilization of the current server storage system and/or under-utilization of the new server storage system), etc.
  • the routine continues to block 465 and creates a copy of each indicated volume on one or more new server block data storage systems, such as in a manner similar to that previously discussed with respect to block 415 ( e.g ., by using an existing volume copy on a server block data storage system, by using a snapshot or other copy of the volume on one or more archival storage systems, etc.), and further updates stored information for the volume in block 465.
  • the routine may take additional actions to support the movement, such as to delete the prior volume copy from a server block data storage system after the new volume copy is created.
  • the routine may initiate the detachment of the prior volume copy being moved for an executing program and/or may initiate a re-attachment of such an executing program to the new volume copy being created, such as by sending associated instructions to a node manager for the executing program, although in other embodiments the node manager may instead perform such actions.
  • routine continues instead to block 485 to perform one or more other indicated operations as appropriate.
  • Other operations may have various forms in various embodiments, such as one or more of the following non-exclusive list: to perform monitoring of some or all server block data storage systems (e.g ., by sending ping messages or other status messages to the server block data storage systems and waiting for a response); by initiating creation of a replacement primary volume copy and/or mirror volume copy in response to determining that a primary or mirror copy of a volume is unavailable, such as based on monitoring that is performed, on a message received from a primary server block data storage system that stores a primary copy of a volume but is unable to update one or more mirror copies of that volume, on a message received from a node manager module, etc.; detaching, deleting, and/or describing one or more volumes; deleting, describing and/or copying one or more snapshot volume copies; tracking use of volumes and/or snapshot volume copies
  • routine continues to block 495 to determine whether to continue, such as until an explicit termination instruction is received. If so, the routine returns to block 405, and if not the routine continues to block 499 and ends.
  • the routine may in some embodiments further verify that the requester is authorized to make the request, such as based on access rights specified for the requester and/or an associated target of the request (e.g ., an indicated volume).
  • the verification of authorization may further include obtaining payment from the requester for the requested functionality (or verifying that any such payment has already been provided), such as to not perform the request if the payment is not provided.
  • types of request that may have associated payment in at least some embodiments and situations include requests to create a volume, attach a volume, create a snapshot copy, move an indicated volume (e.g., to a premium server storage system), and other types of indicated operations.
  • some or all types of actions taken on behalf of users may be monitored and metered, such as for later use in determining corresponding usage-based fees for at least some of those actions.
  • Figure 5 is a flow diagram of an example embodiment of a Node Manager routine 500.
  • the routine may be provided by, for example, execution of a Node Manager module 115 and/or 125 of Figure 1 , and/or execution of a Node Manager module 380 of Figure 3 , such as to manage the use by one or more executing programs of non-local block data storage.
  • the block data storage service provides functionality through a combination of one or more BDS System Manager modules and multiple Node Manager modules and optionally one or more Archival Manager modules, although in other embodiments other configurations may be used (e.g ., a single BDS System Manager module without any Node Manager modules and/or Archival Manager modules, multiple Node Manager modules executing together in a coordinated manager without a BDS System Manager module, etc.).
  • the illustrated embodiment of the routine begins in block 505, where a request is received related to program execution on an associated computing node.
  • the routine continues to block 510 to determine whether the request is related to executing one or more indicated programs on an indicated associated computing node, such as a request from a program execution service and/or a user associated with those programs. If so, the routine continues to block 515 to obtain a copy of the indicated program(s) and to initiate execution of the program(s) on an associated computing node.
  • the one or more indicated programs may be obtained in block 515 based on the indicated programs being sent to the routine 500 as part of the request received in block 505, while in other embodiments the indicated programs may be retrieved from local or non-local storage (e.g ., from a remote storage service).
  • the routine 500 may instead not perform operations related to executing programs, such as if another routine that supports the program execution service instead performs those operations on behalf of associated computing nodes.
  • routine continues instead to block 520 to determine whether a request is received to attach an indicated volume to an indicated executing program, such as from the executing program, from the routine 400 of Figure 4 , and/or from a user associated with the indicated volume and/or the indicated executing program. If so, the routine continues to block 525 to obtain an indication of a primary copy of the volume, and to associate that primary volume copy with a representative logical local block data storage device for the computing node.
  • the representative local logical block data storage device may be indicated to the executing program and/or computing node by the routine 500, while in other embodiments, the executing program may instead initiate the creation of the local logical block data storage device.
  • the routine 500 may use GNBD ("Global Network Block Device") technology to make the logical local block data storage device available to a virtual machine computing node by importing a block device into a particular virtual machine and mounting that logical local block data storage device.
  • the routine may take further actions at block 525, such as to obtain and store indications of one or more mirror volume copies for the volume, such as to allow the routine to dynamically attach to a mirror volume copy if the primary volume copy later becomes unavailable.
  • the routine continues instead to block 530 to determine whether the received request is a data access request by an executing program for an attached volume, such as a read request or a write request. If so, the routine continues to block 535, where the routine identifies the associated primary volume copy that corresponds to the data access request (e.g. , based on the representative local logical block data storage device used by the executed program for the data access request), and initiates the requested data access to the primary volume copy.
  • the routine identifies the associated primary volume copy that corresponds to the data access request (e.g. , based on the representative local logical block data storage device used by the executed program for the data access request), and initiates the requested data access to the primary volume copy.
  • a lazy write scheme may be used, such as by immediately modifying the actual primary and/or mirror volume copies to reflect a write data access request (e.g., to always update the mirror volume copy, to update a mirror volume copy only if the mirror volume copy is being promoted to be the primary volume copy, etc.), but not immediately modifying a corresponding chunk stored on one or more archival storage systems to reflect the write data access request (e.g ., so as to eventually update the copy stored on the archival storage systems when sufficient modifications have been made and/or when read access to corresponding information is requested, etc.).
  • the maintaining of mirror volume copies is performed by a routine other than the routine 500 (e.g., by the primary server block data storage system that stores the primary volume copy), although in other embodiments the routine 500 may in block 535 further assist in maintaining one or more of the mirror volume copies by sending similar or identical data access requests to those mirror volume copies.
  • a volume may not be stored on the archival storage systems until explicitly requested by a corresponding user ( e.g ., as part of a request to create a snapshot copy of the volume), while in other embodiments a copy may be maintained on the archival storage systems of at least some portions of at least some volumes (e.g. , if the archival storage systems' copy is used as a backing store for the primary and/or mirror volume copies).
  • the routine continues to block 540 to determine whether a response is received from the primary server block data storage system for the request sent in block 535 within a predefined time limit, such as to indicate success of the operation. If not, the routine determines that the primary server block data storage system is unavailable, and continues to block 545 to initiate a change to attach one of the mirror volume copies as the new primary volume copy, and to associate the server block data storage system for that mirror volume copy as the new primary server block data storage system for the volume.
  • routine similarly sends the data access request to the new primary volume copy in a manner similar to that indicated above with respect to block 535, and may further in some embodiments monitor whether an appropriate response is received and proceed to block 545 again if not (e.g ., to promote another mirror volume copy and repeat the process).
  • the initiating of the change to a mirror volume copy as a new primary volume copy may be performed in coordination with routine 400, such as by initiating contact with routine 400 to determine which mirror volume copy should become the new primary volume copy, by receiving instructions from routine 400 when a mirror volume copy is promoted to be a primary volume copy by the routine 500 ( e.g ., as prompted by an indication sent by the routine 500 in block 545 that the primary volume copy is unavailable), etc.
  • routine 500 may further perform one or more other actions of a virtual machine monitor, such as if the routine 500 operates as part of or otherwise in conjunction with a virtual machine monitor that manages one or more associated virtual machine computing nodes.
  • routine continues to block 595 to determine whether to continue, such as until an explicit termination instruction is received. If so, the routine returns to block 505, and if not continues to block 599 and ends.
  • the routine may in some embodiments further verify that the requester is authorized to make the request, such as based on access rights specified for the requester and/or an associated target of the request (e.g ., an indicated volume).
  • the verification of authorization may further include obtaining payment from the requester for the requested functionality (or verifying that any such payment has already been provided), such as to not perform the request if the payment is not provided.
  • types of request that may have associated payment in at least some embodiments and situations include requests to execute indicated programs, attach a volume, perform some or all types of data access requests, and other types of indicated operations.
  • some or all types of actions taken on behalf of users may be monitored and metered, such as for later use in determining corresponding usage-based fees for at least some of those actions.
  • FIG. 6 is a flow diagram of an example embodiment of a Server Block Data Storage System routine 600.
  • the routine may be provided by, for example, execution of a software component on a server block data storage system, such as to manage the storage of block data on one or more block data storage volumes on that server storage system ( e.g. , for server block data storage systems 165 of Figure 1 and/or of Figure 2 ).
  • some or all of the functionality of the routine may be provided in other manners, such as by software executing on one or more other computing systems to manage one or more server block data storage systems.
  • the illustrated embodiment of the routine begins at block 605, where a request is received.
  • the routine continues to block 610 to determine whether the received request is related to creating a new volume, such as by associating a block of available storage space for the server storage system (e.g ., storage space on one or more local hard disks) with a new indicated volume.
  • the request may, for example, be from routine 400 and/or from a user associated with the new volume being created. If so, the routine continues to block 615 to store information about the new volume, and in block 620 initializes storage space for the new volume (e.g., a logical linear block of storage space of an indicated size).
  • new volumes may be created based on another existing volume or snapshot volume copy, and if so the routine may in block 620 initialize the storage space for the new volume by copying appropriate data to the storage space, while in other embodiments may initialize new volume storage space in other manners (e.g ., such as to initialize the storage space to a default value, such as all zeros).
  • the routine continues instead to block 625 to determine whether a data access request has been received for an existing volume stored on the server storage system, such as from a node manager associated with an executing program that initiated the data access request. If so, the routine continues to block 630 to perform the data access request on the indicated volume. The routine then continues to block 635 to, in the illustrated embodiment, optionally initiate corresponding updates for one or more mirror copies of the volume, such as if the indicated volume on the current server storage system is the primary volume copy for the volume. In other embodiments, consistency between a primary volume copy and mirror volume copies may be maintained in other manners.
  • At least some modifications to the stored data contents of at least some volumes may also be performed to one or more archival storage systems (e.g. , at a remote storage service), such as to maintain a backing copy or other copy of those volumes, and if so the routine may further initiate updates to the archival storage systems to initiate corresponding updates for one or more copies of the volume on the archival storage systems.
  • archival storage systems e.g. , at a remote storage service
  • the routine may initiate actions to create a new mirror copy of a volume, such as by sending a corresponding message to the routine 400 of Figure 4 or instead by directly initiating the mirror volume copy creation.
  • routine continues to block 685 to perform one or more other indicated operations as appropriate.
  • Such other operations may have various forms in various embodiments, such as one or more of the following non-exclusive list: to delete a volume (e.g.
  • the routine continues to block 695 to determine whether to continue, such as until an explicit termination instruction is received. If so, the routine returns to block 605, and if not continues to block 699 and ends.
  • the routine may in some embodiments further verify that the requester is authorized to make the request, such as based on access rights specified for the requester and/or an associated target of the request (e.g., an indicated volume), while in other embodiments the routine may assume that requests have been previously authorized by a routine from which it receives requests (e.g., a Node Manager routine and/or a BDS System Manager routine).
  • a routine from which it receives requests e.g., a Node Manager routine and/or a BDS System Manager routine.
  • some or all types of actions taken on behalf of users may be monitored and metered, such as for later use in determining corresponding usage-based fees for at least some of those actions.
  • Figures 7A and 7B are a flow diagram of an example embodiment of a PES System Manager routine 700.
  • the routine may be provided by, for example, execution of a PES System Manager module 140 of Figure 1 .
  • some or all of the functionality of the routine 700 may instead be provided in other manners, such as by routine 400 as part of the block data storage service.
  • the routine begins at block 705, where a status message or other request related to the execution of a program is received.
  • the routine continues to block 710 to determine the type of the received message or request. If it is determined in block 710 that the type is a request to execute a program, such as from a user or executing program, the routine continues to block 720 to select one or more host computing systems on which to execute the indicated program, such as from a group of candidate host computing systems available for program execution. In some embodiments, the one or more host computing systems may be selected in accordance with user instructions or other indicated criteria of interest. The routine then continues to block 725 to initiate execution of the program by each of the selected host computing systems, such as by interacting with a Node Manager associated with the selected host computing system. In block 730, the routine then optionally performs one or more housekeeping tasks (e.g., monitoring program execution by users, such as for metering and/or other billing purposes).
  • housekeeping tasks e.g., monitoring program execution by users, such as for metering and
  • routine continues instead to block 740 to store an indication of the program and associated administrative information for its use (e.g., access control information related to users who are authorized to use the program and/or authorized types of uses), and may further store at least one centralized copy of the program in some situations.
  • the routine then continues to block 745 to optionally initiate distribution of copies of the indicated program to one or more host computing systems for later use, such as to allow rapid startup of the program by those host computing systems by retrieving the stored copy from local storage of those host computing systems.
  • one or more copies of the indicated program may be stored in other manners, such as on one or more remote archival storage systems.
  • the routine continues instead to block 750 to update information concerning those host computing systems, such as to track usage of executing programs and/or other status information about host computing systems (e.g., use of non-local block data storage volumes).
  • status messages will be sent periodically by node manager modules, while in other embodiments, status messages may be sent at other times (e.g., whenever a relevant change occurs).
  • the routine 700 may instead request information from node manager modules and/or host computing systems as desired.
  • Status messages may include a variety of types of information, such as the number and identity of programs currently executing on a particular computing system, the number and identity of copies of programs currently stored in the local program repository on a particular computing system, attachments and/or other use of non-local block data storage volumes, performance-related and resource-related information (e.g., utilization of CPU, network, disk, memory, etc.) for a computing system, configuration information for a computing system, and reports of error or failure conditions related to hardware or software on a particular computing system.
  • performance-related and resource-related information e.g., utilization of CPU, network, disk, memory, etc.
  • routine determines in block 705 that another type of request or message is received, the routine continues instead to block 785 to perform one or more other indicated operations as appropriate.
  • Such other operations may include, for example, suspending or terminating execution of currently executing programs, and otherwise managing administrative aspects of the program execution service (registration of new users, determining and obtaining of payment for use of the program execution service, etc.).
  • block 730 to optionally perform one or more housekeeping tasks.
  • the routine then continues to block 795 to determine whether to continue, such as until an explicit termination instruction is received. If so, the routine returns to block 705, and if not continues to block 799 and ends.
  • a variety of additional types of functionality to execute programs may be provided by a program execution service, such as in conjunction with a block data storage service.
  • the execution of one or more copies or instances of a program on one or more computing systems may be initiated in response to a current execution request for immediate execution of those program instances. Alternatively, the initiation may be based on a previously received program execution request that scheduled or otherwise reserved the then-future execution of those program instances for the now-current time.
  • Program execution requests may be received in various ways, such as directly from a user (e.g., via an interactive console or other GUI provided by the program execution service), or from an executing program of a user that automatically initiates the execution of one or more instances of other programs or of itself (e.g., via an API provided by the program execution service, such as an API that uses Web services).
  • Program execution requests may include various information to be used in the initiation of the execution of one or more instances of a program, such as an indication of a program that was previously registered or otherwise supplied for future execution, and a number of instances of the program that are to be executed simultaneously (e.g., expressed as a single desired number of instances, as a minimum and maximum number of desired instances, etc.).
  • program execution requests may include various other types of information, such as the following: an indication of a user account or other indication of a previously registered user (e.g., for use in identifying a previously stored program and/or in determining whether the requested program instance execution is authorized); an indication of a payment source for use in providing payment to the program execution service for the program instance execution; an indication of a prior payment or other authorization for the program instance execution (e.g., a previously purchased subscription valid for an amount of time, for a number of program execution instances, for an amount of resource utilization, etc.); and/or an executable or other copy of a program to be executed immediately and/or stored for later execution.
  • an indication of a user account or other indication of a previously registered user e.g., for use in identifying a previously stored program and/or in determining whether the requested program instance execution is authorized
  • an indication of a payment source for use in providing payment to the program execution service for the program instance execution
  • an indication of a prior payment or other authorization for the program instance execution e
  • program execution requests may further include a variety of other types of preferences and/or requirements for execution of one or more program instances.
  • preferences and/or requirements may include indications that some or all of the program instances be executed in an indicated geographical and/or logical location, such as in one of multiple data centers that house multiple computing systems available for use, on multiple computing systems that are proximate to each other, and/or on one or more computing system that are proximate to computing systems having other indicated characteristics (e.g., that provide a copy of an indicated block data storage volume).
  • Figure 8 is a flow diagram of an example embodiment of an Archival Manager routine 800.
  • the routine may be provided by, for example, execution of one of the Archival Manager modules 355 of Figure 3 , of the Archival Manager module 190 of Figures 2C-2F and/or of one or more archival manager modules (not shown) on the computing systems 180 of Figure 1 .
  • some or all of the functionality of the routine 800 may instead be provided in other manners, such as by routine 400 as part of the block data storage service.
  • the archival storage systems store data in chunks that each correspond to a portion of a block data storage volume, but in other embodiments may store data in other manners.
  • the illustrated embodiment of the routine 800 begins in block 805, where information or a request is received.
  • the routine then continues to block 810 to determine if the request or information is authorized, such as if the requester has provided payment for fee-based access, or otherwise has access rights to have an indicated request be performed. If it is determined in block 815 that the request or information is authorized, the routine continues to block 820, and otherwise returns to block 805.
  • the routine determines if the received request is to store a new snapshot copy for an indicated volume. If so, the routine continues to block 825 to obtain multiple volume chunks for the volume, store each chunk as an archival storage system data object, and then store information about the data objects for the chunks that are associated with the snapshot volume copy.
  • the chunks of the volume may be obtained in various ways, such as by being received in block 805 as multiple distinct blocks, received in block 805 as a single large group of block data that is separated into chunks in block 825, retrieved in block 825 as individual chunks or a single large group of block data to be separated into chunks, previously stored on the archival storage systems, etc.
  • the routine continues instead to block 830 to determine whether the received request is to store an incremental snapshot copy of a volume that reflects changes from a prior snapshot volume copy. If so, the routine continues to block 835 to identify snapshot chunks that have changed since a prior snapshot copy of the volume, and to obtain copies of the changed snapshot chunks in a manner similar to that previously discussed with respect to block 825. The routine then continues to block 840 to store copies of the changed chunks, and to store information about the new changed chunks and the prior other unchanged chunks whose corresponding data objects are associated with the new snapshot volume copy.
  • the chunks that have changed since a prior snapshot volume copy may be identified in various ways, such as by the server block data storage systems that store primary and/or mirror copies of the volume (e.g., by tracking any write data access requests or other modification requests for the volume).
  • the routine continues instead to block 845 to determine whether the request is to provide one or more chunks of a snapshot volume copy, such as from corresponding stored data objects. If so, the routine continues to block 850 to retrieve the data for the indicated snapshot volume copy chunk(s), and sends the retrieved data to the requester.
  • requests may be, for example, part of creating a new volume based on an existing snapshot volume copy by retrieving all of the chunks for the snapshot volume copy, part of retrieving a subset of a snapshot volume copy's chunks to restore a minimal mirror volume copy, etc.
  • the routine continues to block 855 to determine if the received request is to perform one or more data access requests for one or more volume chunks that are not part of a snapshot volume copy, such as to perform read data access requests and/or write data access requests for one or more data objects that represent particular volume chunks (e.g., if those stored data objects serve as a backing store for those volume chunks). If so, the routine continues to block 860 to perform the requested data access request(s) for the stored data object(s) corresponding to the indicated volume chunk(s).
  • lazy updating techniques may be used when modifying stored data objects, such that a write data access request may not be immediately performed. lf so, before a later read data access request for the same data object is completed, the one or more preceding write data access requests may be performed to ensure strict data consistency.
  • the routine continues instead to block 885 to perform one or more other indicated operations as appropriate.
  • Such other operations may include, for example, repeatedly receiving information that corresponds to modifications being performed on a volume in order to update corresponding stored data objects that represent the volume (e.g., as a backing store or for other purposes) and taking appropriate corresponding actions, responding to requests to delete or otherwise modify stored snapshot volume copies, responding to requests of a user to manage an account with a storage service that provides the archival storage systems, etc.
  • the routine continues to block 895 to determine whether to continue, such as until an explicit termination instruction is received. If so, the routine returns to block 805, and if not continues to block 899 and ends.
  • the routine may in some embodiments verify that the requester is authorized to make the request, such as based on access rights specified for the requester and/or an associated target of the request (e.g., an indicated volume or snapshot volume copy), while in other embodiments the routine may assume that requests have been previously authorized by a routine from which it receives requests (e.g., a Node Manager routine and/or a BDS System Manager routine).
  • some or all types of actions taken on behalf of users may be monitored and metered in at least some embodiments, such as for later use in determining corresponding usage-based fees for at least some of those actions.
  • a program to be executed may comprise an entire operating system, a file system and/or other data, and possibly one or more user-level processes.
  • a program to be executed may comprise one or more other types of executables that interoperate to provide some functionality.
  • a program to be executed may comprise a physical or logical collection of instructions and data that may be executed natively on the provided computing system or indirectly by means of interpreters or other software-implemented hardware abstractions. More generally, in some embodiments, a program to be executed may include one or more application programs, application frameworks, libraries, archives, class files, scripts, configuration files, data files, etc.
  • volumes may be migrated or otherwise moved from one server storage system to another.
  • Various techniques may be used to move volumes, and such movement may be initiated in various manners.
  • the movement may reflect problems related to the server storage systems on which the volumes are stored (e.g., failure of the server storage systems and/or of network access to the server storage systems).
  • the movement may be performed to accommodate other volume copies to be stored on existing server storage systems, such as for higher-priority volumes, or to consolidate the storage of volume copies on a limited number of server storage systems, such as to enable the original server storage systems that store the volume copies to be shut down for reasons such as maintenance, energy conservation, etc.
  • one or more of the volume copies stored on a server storage system need more resources than are available from that server storage system, one or more of the volume copies may be migrated to one or more other server storage systems with additional resources.
  • Overuse of available resources may occur for various reasons, such as one or more server storage systems having less resources than expected, one or more of the server storage systems using more resources than expected (or allowed), or, in embodiments in which available resources of one or more server storage systems are intentionally over-committed relative to possible resources needs of one or more reserved or stored volume copies. For example, if the expected resources needs of the volume copies are within the available resources, the maximum resource needs may exceed the available resources. Overuse of available resources may also occur if the actual resources needed for volume storage or use exceed the available resources.
  • routines discussed above may be provided in alternative ways, such as being split among more routines or consolidated into fewer routines.
  • illustrated routines may provide more or less functionality than is described, such as when other illustrated routines instead lack or include such functionality respectively, or when the amount of functionality that is provided is altered.
  • operations may be illustrated as being performed in a particular manner (e.g., in serial or in parallel) and/or in a particular order, in other embodiments the operations may be performed in other orders and in other manners.
  • data structures discussed above may be structured in different manners in other embodiments, such as by having a single data structure split into multiple data structures or by having multiple data structures consolidated into a single data structure, and may store more or less information than is described (e.g., when other illustrated data structures instead lack or include such information respectively, or when the amount or types of information that is stored is altered).
  • a method for a computing system of a block data storage service to provide remote block data storage capabilities to executing programs comprising:
  • Clause 2 The method of clause 1 further comprising, under control of a system manager module for the block data storage service, managing the providing by the block data storage service of the block data storage to the multiple executing programs, the managing including:
  • Clause 3 The method of clause 2 wherein the multiple programs are executed by a program execution service on a second group of multiple of the plurality of computing systems, wherein the computing systems of the second group are distinct from the computing systems of the first group, wherein the first computing system hosts multiple virtual machines that are each able to execute at least one program, wherein the first executing program is one of the multiple programs and is a virtual machine image being executed by at least one of the multiple virtual machines hosted by the first computing system, and wherein the first node manager module executes as part of a virtual machine monitor for the first computing system.
  • a computer-implemented method for providing block data storage functionality to an executing program comprising:
  • Clause 5 The method of clause 4 further comprising, before the receiving of the indications of the first group of the one or more data access requests, attaching the block data storage volume to the first computing system for use by the first executing program, the attaching of the block data storage volume to the first computing system including associating the logical local block storage device for the first computing system with the block data storage volume provided by the second data storage system.
  • Clause 8 The method of clause 4 further comprising, after the determining that the block data storage volume provided by the second data storage system has become unavailable, automatically initiating creation of another copy of the block data storage volume on a fourth data storage system that is distinct from the first computing system and from the second and third data storage systems.
  • Clause 9 The method of clause 8 wherein the block data storage volume provided by the second data storage system becomes unavailable based on at least one of a failure of the second data storage system, of a failure in connectivity to the second data storage system, and of an inability of the second data storage system to reliably access the stored block data storage volume.
  • Clause 11 The method of clause 4 wherein the first computing system and the second data storage system are a subset of a plurality of computing systems co-located at a single geographical location, wherein the plurality of computing systems includes multiple block data storage systems that are provided by a block data storage service, and wherein the second and third data storage systems are each a distinct one of the multiple block data storage systems.
  • Clause 13 The method of clause 11 wherein the first program is executed by a program execution service that executes multiple programs for multiple users on multiple of the plurality of computing systems, wherein the first computing system hosts multiple virtual machines that are each able to execute at least one program, wherein the first executing program is one of the multiple programs and is a virtual machine image being executed by at least one of the multiple virtual machines hosted by the first computing system, wherein the receiving of the indications of the first group of the data access requests and the receiving of the indications of the second group of the other data access requests and the automatic responding to the received indications of the first and second groups of data access requests are performed as part of execution of a virtual machine monitor for the first computing system, and wherein the first computing system includes one or more other actual local storage devices that are available for use by the first executing program.
  • a computer-readable medium whose contents enable one or more computing systems to provide block data storage functionality to an executing program, by performing a method comprising:
  • Clause 15 The computer-readable medium of clause 14 wherein the performance of the data access requests of the first group, the automatic creating of the mirror copy of the block data storage volume, and the performance of the other data access requests of the second group are automatically performed by a system manager module of a block data storage service, wherein the first program initiates data access requests to the block data storage volume by interacting with a logical block data storage device that is local to the first computing system and that represents the block data storage volume provided by the second block data storage system, wherein the receiving of the data access requests initiated by the first program is performed by a node manager module of the block data storage service that is associated with the first computing system after interactions by the first program with the logical local block data storage device, and wherein the automatic responding to the received indications of the data access requests is performed in part under control of the node manager module by initiating sending of the received data access requests over the one or more networks.
  • Clause 16 The computer-readable medium of clause 14 wherein the second block data storage system stores a primary copy of the block data storage volume at a time of the automatic responding to the received indications of the data access requests, and wherein the method further comprises, before the automatic responding to the received indications of the other data access requests, automatically determining that the primary copy of the block data storage volume has become unavailable, selecting the mirror copy of the block data storage volume on one of the third block data storage systems, and promoting the selected mirror copy of the block data storage volume on the third block data storage system to be a current primary copy of the block data storage volume.
  • the automatic creating of the mirror copy of the block data storage volume on each of the one or more third block data storage systems includes creating a first mirror copy of the block data storage volume on one of the third block data storage systems before the automatic responding to the received indications of the data access requests, wherein the automatic responding to the received indications of the data access requests further includes performing the data access requests on the first mirror copy of the block data storage volume, wherein the first mirror copy of the block data storage volume is the selected mirror copy, and wherein the automatic creating of the mirror copy of the block data storage volume on each of the one or more third block data storage systems further includes, after the determining that the primary copy of the block data storage volume has become unavailable, creating a second mirror copy of the block data storage volume on another of the third block data storage systems.
  • Clause 18 The computer-readable medium of clause 14 wherein the second block data storage system stores a primary copy of the block data storage volume at a time of the automatic responding to the received indications of the data access requests, wherein the indicated one or more data access requests initiated by the first program are a second group of data access requests initiated by the first program, and wherein the method further comprises, before the receiving of the indications of the data access requests of the second group:
  • Clause 19 The computer-readable medium of clause 18 wherein the determining to move the primary copy of the block data storage volume from the fourth block data storage system to the second block data storage system is made based on at least one of an automated determination that the second block data storage system is more capable than the fourth block data storage system in providing the primary copy of the block data storage volume and of a request received from a user of the block data storage service who is associated with the block data storage volume.
  • Clause 20 The computer-readable medium of clause 14 wherein the first program is one of multiple programs executed by a program execution service on multiple host computing systems on behalf of users of the program execution service in exchange for fees paid by the users, wherein the first computing system is one of the multiple host computing systems, and wherein use of the block data storage volume by the first program is performed in exchange for a fee provided by the user of the program execution service on whose behalf the first program is being executed.
  • Clause 22 The computer-readable medium of clause 14 wherein the contents are instructions that when executed cause the one or more computing systems to perform the method.
  • a system configured to provide block data storage functionality to executing programs, comprising:
  • Clause 24 The system of clause 23 wherein the creating of the first block data storage volume further includes creating a mirror copy of the first block data storage volume that is stored on a second of the multiple block data storage systems distinct from the first block data storage system and from the one or more other data storage systems, and wherein the responding to the data access requests further includes, for each data access request that is initiated by one of the executing programs for the first block data storage volume, if the primary copy of the first block data storage volume is not available, initiating performance of the data access request on the mirror copy of the first block data storage volume stored on the second block data storage system.
  • Clause 25 The system of clause 24 wherein the responding to the data access requests further includes, for each data access request that is initiated by one of the executing programs for the first block data storage volume, if the primary copy of the first block data storage volume is available, initiating performance of the data access request on the mirror copy of the first block data storage volume stored on the second block data storage system.
  • Clause 26 The system of clause 24 wherein the responding to the data access requests further includes, for an initial data access request initiated by one of the executing programs for the first block data storage volume for which the primary copy of the first block data storage volume on the first block data storage system is not available, promoting the mirror copy of the first block data storage volume stored on the second block data storage system to be a new primary copy of the first block data storage volume in lieu of the primary copy of the first block data storage volume on the first block data storage system, such that the initiating of the performance of that initial data access request on the mirror copy of the first block data storage volume stored on the second block data storage system is performed on the promoted new primary copy of the first block data storage volume on the second block data storage system, and such that data access requests initiated by one of the executing programs for the first block data storage volume subsequent to that initial data access request are performed on the promoted new primary copy of the first block data storage volume on the second block data storage system.
  • Clause 27 The system of clause 26 wherein the promoting of the mirror copy of the first block data storage volume stored on the second block data storage system to be the new primary copy of the first block data storage volume further includes creating a second mirror copy of the first block data storage volume that is stored on a third of the multiple block data storage systems distinct from the first and second block data storage systems, and wherein the responding to each of the data access requests subsequent to the initial data access request that are initiated by one of the executing programs for the first block data storage volume further includes initiating performance of the data access request on the second mirror copy of the first block data storage volume stored on the third block data storage system.
  • Clause 28 The system of clause 23 wherein the received indication in response to which the new copy of the first block data storage volume is created is based on a determination to move the primary copy of the first block data storage volume from the first block data storage system to a distinct second block data storage system, wherein the one or more other data storage systems are the second block data storage system, wherein the creating of the new copy of the first block data storage volume on the second block data storage system includes designating the created new copy on the second block data storage system as a new primary copy of the first block data storage volume, and wherein the providing of the block data storage service by the block data storage system manager module further includes, after the creating of the new copy of the first block data storage volume, responding to one or more additional data access requests that are each initiated by one of the executing programs for the first block data storage volume by initiating performance of the additional data access requests on the new primary copy of the first block data storage volume stored on the second block data storage system.
  • Clause 29 The system of clause 28 wherein the determination to move the primary copy of the first block data storage volume from the first block data storage system to the second block data storage system is made based on at least one of an automated determination that the second block data storage system is more capable than the first block data storage system in providing access for one or more executing programs to the primary copy of the first block data storage volume and of a request received from a user of the block data storage service who is associated with the first block data storage volume.
  • Clause 30 The system of clause 23 wherein the received indication in response to which the new copy of the first block data storage volume is created is a request to create a snapshot copy of the first block data storage volume using a storage service remote from the first block data storage volume, wherein the one or more other data storage systems are archival data storage systems that are part of the remote storage service, and wherein the creating of the new copy of the first block data storage volume includes interacting with the remote storage service to create the new first block data storage volume copy as a snapshot copy of the first block data storage volume.
  • Clause 31 The system of clause 23 further comprising the multiple block data storage systems, the multiple block data storage systems being co-located at a single geographical location, and further comprising a remote storage service that uses multiple other data storage systems at a location other than the single geographical location, the other data storage systems storing data in a format other than block data, and wherein the providing of the block data storage service by the block data storage system manager module further includes, for each of one or more of the created block data storage volumes, storing multiple portions of the block data storage volume on one or more of the multiple other data storage systems of the remote storage service, the stored multiple portions each representing a portion of the block data storage volume that has been modified by one or more data access requests.
  • Clause 33 The system of clause 23 further comprising a program execution service system manager module configured to provide a program execution service that uses multiple host computing systems to execute multiple programs for users of the program execution service, the multiple programs executed by the program execution service including the one or more executing programs that use the created one or more block data storage volumes.
  • a program execution service system manager module configured to provide a program execution service that uses multiple host computing systems to execute multiple programs for users of the program execution service, the multiple programs executed by the program execution service including the one or more executing programs that use the created one or more block data storage volumes.
  • Clause 34 The system of clause 23 wherein the system includes a first computing system that includes at least one of the one or memories, and wherein the block data storage system manager module includes software instructions for execution by the first computing system using the at least one memory.
  • the block data storage system manager module consists of one or more means for providing a block data storage service that uses multiple block data storage systems to store block data storage volumes that are created by users of the block data storage service and accessed over one or more networks on behalf of one or more executing programs associated with the users, the providing of the block data storage service including:
  • a method for a computing system of a block data storage service to manage access of executing programs to remote stored block data comprising:
  • Clause 37 The method of clause 36 wherein the attaching of the first block data storage volume to the first computing system is performed by a node manager module of the block data storage service that manages access of the first computing system to the internal networks, and wherein the method further comprises, under control of the node manager module:
  • Clause 38 The method of clause 37 wherein the multiple programs are executed by a program execution service on a second group of multiple of the plurality of computing systems, wherein the computing systems of the second group are distinct from the computing systems of the first group, wherein the first computing system hosts multiple virtual machines that are each able to execute at least one program, wherein the indicated program is one of the multiple programs and is a virtual machine image being executed by at least one of the multiple virtual machines hosted by the first computing system, and wherein the node manager module executes as part of a virtual machine monitor for the first computing system.
  • a computer-implemented method for managing access to block data storage functionality by executing programs comprising:
  • Clause 40 The method of clause 39 further comprising automatically determining that the first program copy has become unavailable, the unavailability of the first program copy being based on at least one of a failure of the first computing system, of a failure in connectivity to the first computing system, and of an inability of the first computing system to continue to execute the first program copy.
  • Clause 41 The method of clause 40 wherein the identifying of the third computing system on which the second copy of the first program is executing and the attaching of the block data storage volume to the third computing system are performed automatically to maintain access of the first program to the block data storage volume, the automatic maintaining of the access being performed in response to the automatic determining that the first program copy has become unavailable.
  • Clause 42 The method of clause 39 wherein at least one of the determining that the first program copy has become unavailable, the identifying of the third computing system on which the second copy of the first program is executing, and the attaching of the block data storage volume to the third computing system are performed in response to one or more indications received from a user associated with the first program and with the block data storage volume.
  • Clause 43 The method of clause 39 wherein the identifying of the third computing system on which the second copy of the first program is executing includes, after the determining that the first program copy has become unavailable, initiating execution of the second program copy on the third computing system.
  • Clause 44 The method of clause 39 wherein the first copy of the first program is one of multiple copies of the first program that are executed on multiple distinct computing systems, wherein at least one of the multiple copies is an alternative copy for one or more other of the multiple copies, and wherein the identifying of the third computing system on which the second copy of the first program is executing includes selecting the second copy of the first program based on the second copy being one of the at least one alternative copies.
  • Clause 45 The method of clause 39 further comprising, before the attaching of the block data storage volume to the first computing system, creating the block data storage volume on the second data storage system and creating a mirror copy of the block data storage volume on a distinct fourth block data storage system, and wherein the responding to the data access requests of the first group and of the second group further includes initiating performance on the created mirror copy of the data access requests of the first group and of the second group.
  • Clause 46 The method of clause 39 further comprising, before the receiving of the indications of the one or more data access requests, attaching the block data storage volume to the first computing system for use by the first executing program copy, the attaching of the block data storage volume including associating the first logical block storage device with the block data storage volume provided by the second data storage system and being performed by a node manager module that manages access of the first computing system to the one or more networks, the node manager module being part of a block data storage service that previously creates the block data storage volume in response to a request from a user who is associated with the first executing program.
  • Clause 47 The method of clause 39 wherein the first and third computing systems and the second data storage system are a subset of a plurality of computing systems co-located at a first geographical location, wherein the plurality of computing systems includes multiple block data storage systems that are provided by a block data storage service, wherein the second and third data storage systems are each a distinct one of the multiple block data storage systems.
  • Clause 48 The method of clause 47 wherein the first geographical location is a data center, wherein the first program is executed by a program execution service that executes multiple programs for multiple users on multiple of the plurality of computing systems at the data center, wherein the first computing system hosts multiple virtual machines that are each able to execute at least one program, wherein the first executing program is one of the multiple programs and is a virtual machine image being executed by at least one of the multiple virtual machines hosted by the first computing system, wherein the receiving of the indications of the first group of the data access requests and the receiving of the indications of the second group of the other data access requests and the automatic responding to the received indications of the first and second groups of data access requests are performed as part of execution of a virtual machine monitor for the first computing system, and wherein the first computing system includes one or more other actual local storage devices that are available for use by the first executing program.
  • a computer-readable medium whose contents enable one or more computing systems to manage access to block data storage functionality by executing programs, by performing a method comprising:
  • Clause 50 The computer-readable medium of clause 49 wherein the first program and the second program are executing copies of a single program, wherein the providing of the access for the first program includes attaching the block data storage volume to the first computing system in such a manner that the first executing program initiates the data access requests for the block data storage volume via interactions with a first logical block storage device local to the first computing system that represents the block data storage volume, wherein the providing of the access for the second program includes identifying the third computing system on which the second program executes and attaching the block data storage volume to the third computing system in such a manner that the second program has access to a second logical block storage device local to the third computing system that represents the block data storage volume, and wherein the data access requests for the block data storage volume by the first and second programs are to access block data stored on the block data storage volume.
  • Clause 51 The computer-readable medium of clause 50 wherein the first and third computing systems and the second block data storage system are located at a single geographical location, wherein the first computing system and the second block data storage system are separated by one or more networks, wherein the performance of the data access requests and the other data access requests on the block data storage volume on the second block data storage system is automatically performed by a system manager module of a block data storage service, wherein the providing of the access for the first executing program to the block data storage volume is performed by a node manager module of the block data storage service that is associated with the first computing system and that manages access of the first executing program to the one or more networks, and wherein the automatic responding to the received indications of the data access requests is performed in part under control of the node manager module by initiating sending of the received data access requests over the one or more networks to the second block data storage system.
  • Clause 52 The computer-readable medium of clause 51 wherein the providing of the access for the second executing program to the block data storage volume is performed by the node manager module that further manages access of the second executing program to the one or more networks, wherein the third and first computing systems are part of a single physical computing system, and wherein the automatic responding to the received indications of the other data access requests is performed in part under control of the node manager module by initiating sending of the received other data access requests over the one or more networks to the second block data storage system.
  • Clause 53 The computer-readable medium of clause 49 wherein the computer-readable medium is at least one of a memory of a computing system that stores the contents and a data transmission medium that includes a generated stored data signal containing the contents.
  • Clause 54 The computer-readable medium of clause 49 wherein the contents are instructions that when executed cause the one or more computing systems to perform the method.
  • a system configured to manage access to block data storage functionality by executing programs, comprising:
  • Clause 56 The system of clause 55 wherein the first program and the second program are executing copies of a single program, wherein the providing of the access to the first program includes attaching the first block data storage volume to a first computing system executing the first program in such a manner that the first executing program initiates the data access requests for the first block data storage volume via interactions with a first logical block storage device local to the first computing system that represents the first block data storage volume, wherein the providing of the access to the second program includes identifying a third computing system on which the second program executes and attaching the first block data storage volume to the third computing system in such a manner that the second program has access to a second logical block storage device local to the third computing system that represents the first block data storage volume, and wherein the data access requests for the first block data storage volume by the first and second programs are to access block data stored on the block data storage volume.
  • Clause 57 The system of clause 56 wherein the first block data storage volume is stored on a first of the block data storage systems, wherein the first and third computing systems and the first block data storage system are located at a single geographical location and separated by one or more networks, and wherein the system further comprises one or more node manager modules of the block data storage service associated with the first and second programs to manage access of the first and second programs to the one or more networks, such that the responding to the data access requests and to the other data access requests is performed in part under control of the one or more node manager modules by initiating sending of the data access requests and the other data access requests over the one or more networks to the first block data storage system.
  • Clause 58 The system of clause 55 wherein a first copy of the first block data storage volume is stored on a first of the block data storage systems, wherein the performance of the data access requests initiated by the first program are performed on the first copy of the first block data storage volume, wherein the first program executes on a first computing system that is co-located with the first block data storage system at a first geographical location, wherein the second program executes on a second computing system at a distinct second geographical location, and wherein the providing of the access to the first created block data storage volume to the second executing program includes initiating attachment of the second computing system to a second block data storage system at the second geographical location that stores a second copy of the first block data storage volume.
  • Clause 59 The system of clause 55 wherein the system includes a first computing system that includes at least one of the one or memories, and wherein the block data storage system manager module includes software instructions for execution by the first computing system using the at least one memory.
  • the block data storage system manager module consists of one or more means for providing a block data storage service that uses multiple block data storage systems to store block data storage volumes that are created by users of the block data storage service and accessed over one or more networks on behalf of one or more executing programs associated with the users, the providing of the block data storage service including:

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
EP11009559.3A 2008-08-08 2009-08-07 Ausführenden Programmen zuverlässigen Zugriff auf nichtlokalen Blockdatenspeicher gewährleisten Active EP2426605B1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/188,943 US8015343B2 (en) 2008-08-08 2008-08-08 Providing executing programs with reliable access to non-local block data storage
US12/188,949 US8019732B2 (en) 2008-08-08 2008-08-08 Managing access of multiple executing programs to non-local block data storage
EP09805617.9A EP2324429B1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher

Related Parent Applications (3)

Application Number Title Priority Date Filing Date
EP09805617.9 Division 2009-08-07
EP09805617.9A Division-Into EP2324429B1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher
EP09805617.9A Division EP2324429B1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher

Publications (2)

Publication Number Publication Date
EP2426605A1 true EP2426605A1 (de) 2012-03-07
EP2426605B1 EP2426605B1 (de) 2016-03-02

Family

ID=41663996

Family Applications (4)

Application Number Title Priority Date Filing Date
EP11009559.3A Active EP2426605B1 (de) 2008-08-08 2009-08-07 Ausführenden Programmen zuverlässigen Zugriff auf nichtlokalen Blockdatenspeicher gewährleisten
EP09805617.9A Active EP2324429B1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher
EP20168868.6A Withdrawn EP3699765A1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher
EP16153403.7A Withdrawn EP3037970A1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher

Family Applications After (3)

Application Number Title Priority Date Filing Date
EP09805617.9A Active EP2324429B1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher
EP20168868.6A Withdrawn EP3699765A1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher
EP16153403.7A Withdrawn EP3037970A1 (de) 2008-08-08 2009-08-07 Bereitstellung von ausführenden programmen mit zuverlässigem zugriff auf nichtlokalen blockdatenspeicher

Country Status (5)

Country Link
EP (4) EP2426605B1 (de)
JP (2) JP5015351B2 (de)
CN (3) CN103645953B (de)
ES (1) ES2575155T3 (de)
WO (1) WO2010017492A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9311191B2 (en) 2013-07-26 2016-04-12 Huawei Technologies Co., Ltd. Method for a source storage device sending data to a backup storage device for storage, and storage device

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10255587B2 (en) 2012-01-18 2019-04-09 Microsoft Technology Licensing, Llc System and method for blended presentation of locally and remotely stored electronic messages
CN102710763B (zh) * 2012-05-29 2015-11-25 新华网股份有限公司 一种分布式缓存池化、分片及故障转移的方法及系统
CN103546724A (zh) * 2013-10-22 2014-01-29 杭州爱浦多数码技术有限公司 一种网络摄像机集散式冗余存储系统及其存储方法
US10866768B2 (en) * 2014-12-12 2020-12-15 Advanced Micro Devices, Inc. Storage location assignment at a cluster compute server
US20160277498A1 (en) * 2015-03-20 2016-09-22 Intel Corporation Location and boundary controls for storage volumes
US9900386B2 (en) * 2015-04-09 2018-02-20 International Business Machines Corporation Provisioning data to distributed computing systems
WO2017064770A1 (ja) * 2015-10-14 2017-04-20 株式会社日立製作所 ストレージシステムおよびストレージシステムの制御方法
CN107025151A (zh) * 2016-01-30 2017-08-08 鸿富锦精密工业（深圳）有限公司 电子装置连接系统
EP3479236B1 (de) * 2016-06-29 2021-09-22 Amazon Technologies, Inc. Netzwerkzugängliche datenvolumenänderung
US10509738B2 (en) * 2016-07-01 2019-12-17 Intel Corporation Remote memory operations
CN106844140B (zh) * 2016-12-21 2020-05-26 南京富士通南大软件技术有限公司 一种基于scom的监控方法
TWI659306B (zh) * 2018-01-10 2019-05-11 英屬開曼群島商捷鼎創新股份有限公司 卷搬移中執行資料讀寫的方法及電子裝置
JP7171757B2 (ja) * 2018-04-30 2022-11-15 アマゾン テクノロジーズ インコーポレイテッド ブロックストレージシステムのための分散されたレプリカ
CN113760611B (zh) * 2021-08-30 2024-05-03 银清科技有限公司 系统站点切换方法、装置、电子设备及存储介质
CN113849137B (zh) * 2021-10-13 2023-08-01 上海威固信息技术股份有限公司 一种面向申威容器平台的可视化块存储方法和系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070156842A1 (en) 2005-12-29 2007-07-05 Vermeulen Allan H Distributed storage system with web services client interface
US20080189468A1 (en) * 2007-02-02 2008-08-07 Vmware, Inc. High Availability Virtual Machine Cluster

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6324654B1 (en) * 1998-03-30 2001-11-27 Legato Systems, Inc. Computer network remote data mirroring system
JP2002123406A (ja) * 2000-10-17 2002-04-26 Pfu Ltd 高信頼性システム
US6938122B2 (en) * 2001-01-23 2005-08-30 Emc Corporation Remote mirroring in a switched environment
CN1285047C (zh) * 2001-08-30 2006-11-15 Bea系统公司 具有并行检查的群集高速缓存
US20070094466A1 (en) * 2001-12-26 2007-04-26 Cisco Technology, Inc., A Corporation Of California Techniques for improving mirroring operations implemented in storage area networks and network based virtualization
US20070094465A1 (en) * 2001-12-26 2007-04-26 Cisco Technology, Inc., A Corporation Of California Mirroring mechanisms for storage area networks and network based virtualization
US7139885B2 (en) * 2001-12-27 2006-11-21 Hitachi, Ltd. Method and apparatus for managing storage based replication
KR100464350B1 (ko) * 2001-12-31 2005-01-03 삼성전자주식회사 통신 시스템에서 로드 공유 그룹을 이용한 분산된 호 처리및 업그레이드 시스템 및 방법
US7043665B2 (en) * 2003-06-18 2006-05-09 International Business Machines Corporation Method, system, and program for handling a failover to a remote storage location
JP4307202B2 (ja) * 2003-09-29 2009-08-05 株式会社日立製作所 記憶システム及び記憶制御装置
US20050240806A1 (en) * 2004-03-30 2005-10-27 Hewlett-Packard Development Company, L.P. Diagnostic memory dump method in a redundant processor
US7131027B2 (en) * 2004-07-09 2006-10-31 Hitachi, Ltd. Method and apparatus for disk array based I/O routing and multi-layered external storage linkage
US7058731B2 (en) * 2004-08-03 2006-06-06 Hitachi, Ltd. Failover and data migration using data replication
JP4786248B2 (ja) * 2005-08-09 2011-10-05 株式会社日立製作所 ストレージシステムの構成管理装置及び構成管理方法
JP4710518B2 (ja) * 2005-09-28 2011-06-29 株式会社日立製作所 計算機システムとそのブート制御方法
JP4736783B2 (ja) * 2005-12-19 2011-07-27 株式会社日立製作所 ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法
US8046545B2 (en) * 2006-01-03 2011-10-25 Emc Corporation Continuous backup
JP2007226400A (ja) * 2006-02-22 2007-09-06 Hitachi Ltd 計算機管理方法、計算機管理プログラム、実行サーバの構成を管理する待機サーバ及び計算機システム
JP4611922B2 (ja) * 2006-03-28 2011-01-12 富士通株式会社 制御プログラム、制御方法および制御装置
US7792944B2 (en) * 2006-03-31 2010-09-07 Amazon Technologies, Inc. Executing programs based on user-specified constraints
US7627729B2 (en) * 2006-09-07 2009-12-01 International Business Machines Corporation Apparatus, system, and method for an improved synchronous mirror swap
US7594072B2 (en) * 2006-09-15 2009-09-22 Hitachi, Ltd. Method and apparatus incorporating virtualization for data storage and protection
JP4902403B2 (ja) * 2006-10-30 2012-03-21 株式会社日立製作所 情報システム及びデータ転送方法
JP5244332B2 (ja) * 2006-10-30 2013-07-24 株式会社日立製作所 情報システム、データ転送方法及びデータ保護方法
WO2009134772A2 (en) * 2008-04-29 2009-11-05 Maxiscale, Inc Peer-to-peer redundant file server system and methods

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070156842A1 (en) 2005-12-29 2007-07-05 Vermeulen Allan H Distributed storage system with web services client interface
US20080189468A1 (en) * 2007-02-02 2008-08-07 Vmware, Inc. High Availability Virtual Machine Cluster

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"LVM Administrator's Guide Configuration and Administration", 1 January 2007 (2007-01-01), Raleigh, NC 27606-2072 USA, pages 1 - 92, XP055017068, Retrieved from the Internet <URL:http://www.centos.org/docs/5/pdf/Cluster_Logical_Volume_Manager.pdf> [retrieved on 20120120] *
"Red Hat Cluster Suite Overview: Red Hat Cluster Suite for Red Hat Enterprise Linux 5", 1 January 2007 (2007-01-01), Raleigh, NC 27606-2072 USA, pages 1 - 67, XP055017058, Retrieved from the Internet <URL:http://www.centos.org/docs/5/pdf/Cluster_Suite_Overview.pdf> [retrieved on 20120120] *
"Using GNBD with Global File System Configuration and Administration", 1 January 2007 (2007-01-01), Raleigh, NC 27606-2072 USA, pages 1 - 15, XP055017072, Retrieved from the Internet <URL:http://www.centos.org/docs/5/pdf/Global_Network_Block_Device.pdf> [retrieved on 20120120] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9311191B2 (en) 2013-07-26 2016-04-12 Huawei Technologies Co., Ltd. Method for a source storage device sending data to a backup storage device for storage, and storage device
US10108367B2 (en) 2013-07-26 2018-10-23 Huawei Technologies Co., Ltd. Method for a source storage device sending data to a backup storage device for storage, and storage device

Also Published As

Publication number Publication date
EP2324429A4 (de) 2012-06-06
CN105138435B (zh) 2019-06-04
CN103645953B (zh) 2017-01-18
JP2011530748A (ja) 2011-12-22
EP3699765A1 (de) 2020-08-26
EP2324429B1 (de) 2020-10-14
EP2426605B1 (de) 2016-03-02
EP2324429A1 (de) 2011-05-25
WO2010017492A1 (en) 2010-02-11
JP2012053878A (ja) 2012-03-15
CN103645953A (zh) 2014-03-19
EP3037970A1 (de) 2016-06-29
CN105138435A (zh) 2015-12-09
JP5015351B2 (ja) 2012-08-29
CN102177508A (zh) 2011-09-07
JP5118243B2 (ja) 2013-01-16
CN102177508B (zh) 2015-08-05
ES2575155T3 (es) 2016-06-24

Similar Documents

Publication Publication Date Title
US11768609B2 (en) Managing access of multiple executing programs to nonlocal block data storage
US11526407B2 (en) Providing executing programs with access to stored block data of others
US9262273B2 (en) Providing executing programs with reliable access to non-local block data storage
US7831682B2 (en) Providing a reliable backing store for block data storage
EP2426605B1 (de) Ausführenden Programmen zuverlässigen Zugriff auf nichtlokalen Blockdatenspeicher gewährleisten
US11669409B2 (en) Application migration between environments
US11663085B2 (en) Application backup and management
US9276987B1 (en) Identifying nodes already storing indicated input data to perform distributed execution of an indicated program in a node cluster
US10372561B1 (en) Block storage relocation on failure
US8296419B1 (en) Dynamically modifying a cluster of computing nodes used for distributed execution of a program
US20040153481A1 (en) Method and system for effective utilization of data storage capacity
Barclay et al. TerraServer Bricks “” A High Availability Cluster Alternative

Legal Events

Date Code Title Description
17P Request for examination filed

Effective date: 20111202

AC Divisional application: reference to earlier application

Ref document number: 2324429

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DESANTES, PETER, N.

Inventor name: JORGENSEN, ATLE, NORMANN

Inventor name: PATERSON-JONES, ROLAND

Inventor name: CERTAIN, TATE, ANDREW

Inventor name: GARMEN, MATTHEW, S.

17Q First examination report despatched

Effective date: 20121009

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20150812

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DESANTES, PETER, N.

Inventor name: CERTAIN, TATE, ANDREW

Inventor name: JORGENSEN, ATLE, NORMANN

Inventor name: GARMEN, MATTHEW, S.

Inventor name: PATERSON-JONES, ROLAND

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AC Divisional application: reference to earlier application

Ref document number: 2324429

Country of ref document: EP

Kind code of ref document: P

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 778456

Country of ref document: AT

Kind code of ref document: T

Effective date: 20160315

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009036632

Country of ref document: DE

REG Reference to a national code

Ref country code: CH

Ref legal event code: NV

Representative=s name: ING. MARCO ZARDI C/O M. ZARDI AND CO. S.A., CH

REG Reference to a national code

Ref country code: NL

Ref legal event code: FP

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2575155

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20160624

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 778456

Country of ref document: AT

Kind code of ref document: T

Effective date: 20160302

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160602

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160603

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 8

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160704

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009036632

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 602009036632

Country of ref document: DE

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, DE

26N No opposition filed

Effective date: 20161205

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160602

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 9

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20090807

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160302

Ref country code: MT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20160831

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 10

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230523

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: TR

Payment date: 20230719

Year of fee payment: 15

Ref country code: IT

Payment date: 20230822

Year of fee payment: 15

Ref country code: ES

Payment date: 20230901

Year of fee payment: 15

Ref country code: CH

Payment date: 20230903

Year of fee payment: 15

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: LU

Payment date: 20240827

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20240826

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IS

Payment date: 20240718

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240828

Year of fee payment: 16

Ref country code: MC

Payment date: 20240724

Year of fee payment: 16

Ref country code: IE

Payment date: 20240827

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20240827

Year of fee payment: 16

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20240826

Year of fee payment: 16