According to certain aspects, a system includes a client device that includes a virtual machine (VM) executed by a hypervisor, a driver located within the hypervisor, and a data agent. The VM may include a virtual hard disk file and a change block bitmap file. The driver may intercept a first write operation generated by the VM to store data in a first sector, determine an identity of the first sector based on the intercepted write operation, determine an entry in the change block bitmap file that corresponds with the first sector, and modify the entry in the change block bitmap file to indicate that data in the first sector has changed. The data agent may generate an incremental backup of the VM based on the change block bitmap file in response to an instruction from a storage manager, where the incremental backup includes the data in the first sector.

Virtual machine change block tracking

Systems and methods enable a virtual machine, including any applications executing thereon, to quickly start executing and servicing users based on pre-staged data blocks supplied from a backup copy in secondary storage. An enhanced media agent may pre-stage certain backed up data blocks which may be needed to launch the virtual machine, based on predictive analysis pertaining to the virtual machine's operational profile. The enhanced media agent may also pre-stage backed up data blocks for a virtual-machine-file-relocation operation, based on the operation's relocation scheme. Servicing read requests to the virtual machine may take priority over ongoing pre-staging of backed up data. Read requests may be tracked so that the media agent may properly maintain the contents of an associated read cache. Some embodiments of the illustrative storage management system may lack, or may simply not require, the relocation operation, and may operate in a “live mount” configuration.

Efficient live-mount of a backed up virtual machine in a storage management system

The data storage system according to certain aspects can manage the archiving of virtual machines to (and restoring of virtual machines from) secondary storage. The system can determine whether to archive virtual machines based on usage data or information. The usage information may include storage usage, CPU usage, memory usage, network usage, events defined by a virtual machine software or application, etc. The system may archive virtual machines that are determined to have a low level of utilization. For example, a virtual machine can be archived when its usage level falls below a threshold level. The system may create a virtual machine placeholder for an archived virtual machine, which may be a “light” or minimal version of the virtual machine that acts as if it is the actual virtual machine. By using a virtual machine placeholder, a virtual machine may appear to be active and selectable by the user.

Archiving virtual machines in a data storage system

The disclosed systems and methods enable a virtual machine, including any applications executing thereon, to quickly start executing and servicing users based on pre-staged data blocks supplied from a backup copy in secondary storage. Substantially concurrently with the ongoing execution of the virtual machine, a virtual-machine-file-relocation operation may move data blocks originating in the backup copy to a primary storage destination that becomes the virtual machine's primary data store after the relocation operation completes. An enhanced data agent, operating in conjunction with an enhanced media agent in a storage management system, coordinates restoring of the virtual machine and the launch of the relocation operation. The enhanced media agent may pre-stage certain backed up data blocks which may be needed to launch the virtual machine, based on predictive analysis pertaining to the virtual machine's operational profile. The enhanced media agent may also pre-stage backed up data blocks for the relocation operation, based on the operation's relocation scheme. Servicing read requests to the virtual machine may take priority over ongoing pre-staging of backed up data. Read requests may be tracked so that the media agent may properly maintain the contents of an associated read cache. Some embodiments of the illustrative storage management system may lack, or may simply not require, the relocation operation, and may operate in a “live mount” configuration.

Efficiently restoring execution of a backed up virtual machine based on coordination with virtual-machine-file-relocation operations

A service manages a plurality of virtual machine instances for low latency execution of user codes. The service can provide the capability to execute user code in response to events triggered on an auxiliary service to provide implicit and automatic rate matching and scaling between events being triggered on the auxiliary service and the corresponding execution of user code on various virtual machine instances. An auxiliary service may be configured as an event triggering service to detect events and generate event messages for execution of the user codes. The service can request, receive, or poll for event messages directly from the auxiliary service or via an intermediary message service. Event messages can be rapidly converted to requests to execute user code on the service. The time from processing the event message to initiating a request to begin code execution is less than a predetermined duration, for example, 100 ms.

Programmatic event detection and message generation for requests to execute program code

A distributed computing application is described that provides a highly elastic and multi-tenant platform for Hadoop applications and other workloads running in a virtualized environment. Data and compute nodes are separated into different virtual machines (VM). Compute VMs are used to launch containers from different tenants. Compute VMs are organized in pools of hot spare VMs that are immediately available for launching a container and executing a task, and pools of cold spare VMs. Each compute VM may include a mounted network filesystem provided by a node manager to share intermediate outputs across VMs executing on the same host.

Container virtual machines for hadoop

A distributed computing application is described that provides a highly elastic and multi-tenant platform for Hadoop applications and other workloads running in a virtualized environment. Deployments of a distributed computing application, such as Hadoop, may be executed concurrently with a distributed database application, such as HBase, using a shared instance of a distributed filesystem, or in other cases, multiple instances of the distributed filesystem. Computing resources allocated to region server nodes executing as VMs may be isolated from compute VMs of the distributed computing application, as well as from data nodes executing as VMs of the distributed filesystem.

Multi-tenant distributed computing and database

Exemplary methods, apparatuses, and systems that can intelligently copy data to a plurality of datastores using performance monitoring are described. In one embodiment, a shortest path tree determines the most efficient paths available for copying data from a source datastore to one or more destination datastores. During the copying of the data between a source datastore and the one or more destination datastores, a performance value of each of the datastores involved in the copying process is compared to a threshold. In response to determining that the performance value of a given source or destination datastore involved in the copying exceeds the threshold, the copying of the data to the corresponding destination datastore is suspended. An updated shortest path tree is determined to locate a more efficient path for copying data to the suspended destination datastore. Copying is resumed to the suspended destination datastore using the updated shortest path tree.

Intelligent data propagation using performance monitoring

An elastic filesystem for temporary data provides storage space for virtual machines (VMs) in a distributed computing system. The filesystem redirects accesses to virtual disks in VMs to a common pool file. The system provides performance and storage efficiency at least on par with local, direct attached virtual disks, while providing a single pool of shared storage that is provisioned and managed independently of the VMs. The system provides storage isolation between VMs storing temporary data in that shared pool. Also, storage space for temporary data may be allocated on demand and reclaimed when no longer needed, thereby supporting a wide variety of temporary space requirements for different Hadoop jobs.

Elastic temporary filesystem

The designation Big Data has become a mainstream buzz phrase across many industries as well as research circles. Today many companies are making performance claims that are not easily verifiable and comparable in the absence of a neutral industry benchmark. Instead one of the test suites used to compare performance of Hadoop based Big Data systems is the TeraSort. While it nicely defines the data set and tasks to measure Big Data Hadoop systems it lacks a formal specification and enforcement rules that enable the comparison of results across systems. In this paper we introduce TPCx-HS, the industry’s first industry standard benchmark, designed to stress both hardware and software that is based on Apache HDFS API compatible distributions. TPCx-HS extends the workload defined in TeraSort with formal rules for implementation, execution, metric, result verification, publication and pricing. It can be used to asses a broad range of system topologies and implementation methodologies of Big Data Hadoop systems in a technically rigorous and directly comparable and vendor-neutral manner.

Tariq Magdon-Ismail

Papers

Container virtual machines for hadoop

Multi-tenant distributed computing and database

Intelligent data propagation using performance monitoring

Elastic temporary filesystem

Introducing TPCx-HS: The First Industry Standard for Benchmarking Big Data Systems