DOC: Key Concepts and Objects

Experiment: A Scenario and an execution table (with start times and duration for each execution).

An experiment is composed by a set of Experiment Objects. Experiment objects are defined within CBTOOL, and used by it to control the effective deployment and execution of benchmark applications.

Objects are of three classes.

• The configuration objects are used by CBTOOL for internal code execution and bookkeeping.
• The concrete objects are managed and tracked by both CBTOOL and the cloud manager.
• The abstract objects are the ones whose meaning and state are tracked only by CBTOOL, representing a logical aggregation of the multiple instances of concrete objects. Abstract objects can represent either a single Virtual Application deployed on a cloud, or a group of inter-related VApps. It is through the specification of abstract objects that an experiment assumes a truly dynamic behavior.

Concrete objects are of four flavors: Clouds, Virtual Machine Container, Hosts (exposed by some Clouds) and Virtual Machines (VMs).

Cloud: The Cloud object represents the cloud manager, and includes in its description all information required to establish a connection to it, including access and authentication credentials.

• By having a whole cloud as an object, CloudBench allows one direct an individual experiment plan at multiple clouds to compare them against each other.

Virtual Machine Container (VMC): The smallest point of access or "place" where a VM is instantiated.

• Each VMC has a cloud-wide unique identifier
• While the meaning of Region is invariant, its scope is very specific to each particular cloud. It can range from a single host (in a virtualized environment with the libvirt/KVM duo) to a whole geographic region with multiple “availability zones” (in the case of Amazon’s Elastic Compute Cloud).
• The definition of the Region as a distinct object is useful, allowing CBTOOL to exploit intra-cloud parallelism (e.g., in a geographically distributed cloud)

Host: Individual Hypervisors where VMs are effectively deployed.

• Not all clouds allow Hosts to be discovered/monitored (e.g., Amazon EC2)

Virtual Machine (VM): Individual Virtual Machine instances are the only element whose state (i.e., created, running, destroyed) are effectively know by a given cloud.

• VMs are instantiated and terminated (the latter only in case of an AS with a variable number of instances) by the submission of the appropriate commands/operations/requests to the cloud by CBTOOL.
• In order to be properly created, a VM with a given role needs to be fully identified within the cloud, with some cloud-specific information, like image id, instance size and/or class. This is designated a VM template.

DB2:“ami-e7f63a8e”, “m1.large” (Amazon EC2)

Abstract objects are of two flavors: Virtual Applications and Virtual Application Submitters

Virtual Application Submitter (VAppS): A collection of Application Instances of a given Application Type.

• Due to "historical" reasons, this abstraction is also called Application Instance Deployment Request Submitter (AIDRS).
• Every Virtual Application instance has an inter-arrival time, and a lifetime, governed by two AS-wide random distributions.
• Every Virtual Application instance on an VAppS has an individual time-varying load intensity and duration attributed to it, according to two AS-wide random distributions.

Virtual Application (VApp): A collection of VMs that run cooperatively to effectively execute a given application type.

• Due to "historical" reasons, this abstraction is also called Application Instance (AI)
• Every VM has a “role” within the VApp.
• One of the VMs has to have the roles load manager and metrics aggregator. This VM will: (1) manage the load applied to the rest of the AI and (2) collect performance data from the VApp.
• Each VApp has an “Virtual Application template”, containing a list of VM roles and its topology.

DayTrader:1_x_driver_daytrader->1_x_WAS->1_x_DB2 VM Hadoop:1_x_driver_hadoop->1_x_hadoopmaster->4_x_hadoopslave