Abstract: In a particular embodiment, a virtual namespace identifier is mapped to one or more volumes stored among a pool of storage resources, wherein at least a first storage system and a second storage system are utilized to provide the storage resources. The virtual namespace identifier is migrated among the pool of storage resources to virtualize a data path for the one or more volumes.

Abstract: Declarative provisioning of storage, including: identifying one or more policies associated with a storage object; determining, in dependence upon at least the one or more policies, a storage configuration for the storage object; and provisioning, in accordance with the storage configuration, storage that implements the storage object.

Abstract: In a particular embodiment, a virtual namespace identifier is mapped to one or more volumes stored among a pool of storage resources, wherein at least a first storage system and a second storage system are utilized to provide the storage resources. The virtual namespace identifier is migrated among the pool of storage resources to virtualize a data path for the one or more volumes.

Abstract: An I/O manager may be configured to service I/O requests pertaining to ephemeral data of a virtual machine using a storage device that is separate from and/or independent of a primary storage resource to which the I/O request is directed. Ephemeral data may be removed from ephemeral storage in response to a removal condition and/or trigger, such as a virtual machine reboot. The I/O manager may manage transfers of ephemeral virtual machine data in response to virtual machines migrating between host computing devices. The I/O manager may be further configured to cache virtual machine data, and/or manage shared file data that is common to two or more virtual machines operating on a host computing device.

Abstract: Techniques are described herein for creating an algorithm for batch mode processing against big data. The techniques involve receiving one or more user commands from a set number of commands that correspond one-to-one with a set number of low-level database operations. In a preferred embodiment, the set of database operations includes only FILTERS, SORTS, AGREGGATES, and JOINS. In the algorithm formation process, database operations are performed on a sample population of records. The user drills down to a set of useful records by performing database operations against the results of the previous database operations. While the database cluster is receiving operations, the system is tracking the operations in a dependency graph. The chains selected within the dependency graph indicate which operations are used to create the algorithm. To generate the algorithm, the database cluster reverse engineers the logic for performing those operations against big data.

Abstract: Techniques are described herein for performing database operations against location and access transparent metadata units called fat pointers organized into globally distributed data structures. The fat pointers are created by extracting values corresponding to a particular key and paring each value with a reference to the local location and server that has the native format record containing the value. The fat pointers may be transferred to any server in the cluster, even if the server is different from the server that has the native format record. In general, most operations are performed against fat pointers rather than the native format records. This allows the cluster to perform work against arbitrary types of data efficiently and in a constant amount of time despite the variable sizes and structures of records.

Abstract: Techniques are described herein for performing database operations against location and access transparent metadata units called fat pointers organized into globally distributed data structures. The fat pointers are created by extracting values corresponding to a particular key and paring each value with a reference to the local location and server that has the native format record containing the value. The fat pointers may be transferred to any server in the cluster, even if the server is different from the server that has the native format record. In general, most operations are performed against fat pointers rather than the native format records. This allows the cluster to perform work against arbitrary types of data efficiently and in a constant amount of time despite the variable sizes and structures of records.

Abstract: Techniques are described herein for creating an algorithm for batch mode processing against big data. The techniques involve receiving one or more user commands from a set number of commands that correspond one-to-one with a set number of low-level database operations. In a preferred embodiment, the set of database operations includes only FILTERS, SORTS, AGREGGATES, and JOINS. In the algorithm formation process, database operations are performed on a sample population of records. The user drills down to a set of useful records by performing database operations against the results of the previous database operations. While the database cluster is receiving operations, the system is tracking the operations in a dependency graph. The chains selected within the dependency graph indicate which operations are used to create the algorithm. To generate the algorithm, the database cluster reverse engineers the logic for performing those operations against big data.

Abstract: A storage module may be configured to service I/O requests according to different persistence levels. The persistence level of an I/O request may relate to the storage resource(s) used to service the I/O request, the configuration of the storage resource(s), the storage mode of the resources, and so on. In some embodiments, a persistence level may relate to a cache mode of an I/O request. I/O requests pertaining to temporary or disposable data may be serviced using an ephemeral cache mode. An ephemeral cache mode may comprise storing I/O request data in cache storage without writing the data through (or back) to primary storage. Ephemeral cache data may be transferred between hosts in response to virtual machine migration.

Abstract: A storage module may be configured to service I/O requests according to different persistence levels. The persistence level of an I/O request may relate to the storage resource(s) used to service the I/O request, the configuration of the storage resource(s), the storage mode of the resources, and so on. In some embodiments, a persistence level may relate to a cache mode of an I/O request. I/O requests pertaining to temporary or disposable data may be serviced using an ephemeral cache mode. An ephemeral cache mode may comprise storing I/O request data in cache storage without writing the data through (or back) to primary storage. Ephemeral cache data may be transferred between hosts in response to virtual machine migration.

Abstract: An I/O manager may be configured to service I/O requests pertaining to ephemeral data of a virtual machine using a storage device that is separate from and/or independent of a primary storage resource to which the I/O request is directed. Ephemeral data may be removed from ephemeral storage in response to a removal condition and/or trigger, such as a virtual machine reboot. The I/O manager may manage transfers of ephemeral virtual machine data in response to virtual machines migrating between host computing devices. The I/O manager may be further configured to cache virtual machine data, and/or manage shared file data that is common to two or more virtual machines operating on a host computing device.