Basic Concepts

Cloud
Virtual Cloud
Hybrid Cloud Deployment
Developing Cloud Application
VM Image
Amazon EC2
Grid vs. Cloud
Grid Instance
Grid Node
Grid Task
Grid Task Session
Grid Topology
Grid Job
Grid Job Sibling
Grid Job Context
Grid Job Collision & Scheduling
Grid Job Failover
Grid Job Preemption
Grid Job Stealing
Grid Job Checkpoint
MapReduce
Grid Enabling
Grid Event
Resources Injection

Below are some of the basic concepts and definition in GridGain product. Note that some of these definitions are common and some are specific to GridGain only. Understanding of these basic concepts is essential for understanding how GridGain works.

Cloud

External data center that exposes its resources with programmatic interface, usually a WS interface. In most cases, due to this dynamic nature of resource provisioning these data centers provide pay-per-use payment schema.

Virtual Cloud

Two or more clouds or grids viewed, accessed and managed as one. In most cases, a combination of local grid and external cloud is referred as virtual cloud.

Hybrid Cloud Deployment

Hybrid cloud deployment means that application is deployed across local resources and resources from one or more external cloud. This is usually done to accommodate non-critical one-off tasks that can be run on the cloud, to handle demand picks, etc. For many complex real-life business applications this is a primary deployment model.

Developing Cloud Application

Developing cloud application is no different than developing any other grid application. The only difference is that this application can be deployed entire on the cloud or in a hybrid deployment mode where part of the application is deployed locally and the part of parts are deployed permanently or temporarily on the cloud.

VM Image

Cloud infrastructure providers (such as Amazon EC, GoGrid, etc.) use hardware virtualization technology to provide cloud infrastructure to its clients. Virtual Machine (VM) image (do not confuse with Java Virtual Machine) is what one usually need to create and upload to cloud provider to provision and configure resource on the cloud. VM image typically includes operating system, JDK, GridGain installation and any other software that you need to run with GridGain.

Amazon EC2

Amazon EC2 is a cloud service which is one of several services provided by Amazon. Basically, it exposes Amazon's data center resources via Web Services API using pay-per-use pricing. Anyone can rent a computer and upload its own VM Image using WS APIs and pay only for the actual usage. This is the most popular and most developed cloud provider at the moment of this writing (December 2008).

Grid vs. Cloud

Grids and clouds are completely synergetic. Grids are usually comprised of the resources that are available locally, while clouds are usually the resources that are not local and available on pay-per-use price from external provider. That's all the difference. In many situations you would need both as grids provide ready and permanent deployment environment that is totally controlled by you and clouds provide sensible option for handling tasks that can be or should be offloaded from the local grid.

Grid Instance

Grid instance is a single runtime named instance of GridGain. You can have one runtime per JVM or multiple runtime instances in the same VM. You can also usually have multiple instance of GridGain per physical computer. GridFactory ^Javadoc is responsible for starting grid instances.

Grid Node

Grid node is similar (and almost synonymous) to grid instance. In the essence it is a single grid runtime with unique node ID. Note that grid node doesn't have to be physically separate node. GridGain supports multiple grid nodes on the same VM. Grid node provides static information about a node via node attributes and dynamic runtime information via node metrics.

Grid Task

Grid task is a main deployment unit in GridGain. Grid task is what user deploys (explicitly or implicitly) and executes. Everything else in the GridGain system coalesces around the notion of grid task. Grid task's another major responsibility includes splitting into jobs and aggregating jobs's results.

See also: GridTask ^Javadoc
See also: GridTaskResult ^Javadoc
See also: GridTaskAdapter ^Javadoc

Grid Task Session

During the entire grid task execution GridGain provides grid task session that is available for grid task and grid jobs instances. As most system-managed resources in GridGain, grid task session is injectable via annotation resource. Grid task session provides comprehensive API including access to job siblings, checkpoints, and distributed session attributes.

Grid Topology

Grid topology defines what grid nodes are available for a given grid task. Topology SPI is a centralized place that is responsible for determining what nodes are available to a given task.

There are many strategies on how grid topology can be resolved for a particular situation: cycle scavenging can be used for picking up idling resources, time-based resolution can be used for coarse grained scheduling, benchmark metrics can be used for finding best nodes match given specific job's parameters, etc.

Grid Job

Grid job defines an executable. Basically, grid job travels to remote nodes for execution while grid task is responsible for split and aggregation of grid jobs' results. Combination of grid task and grid jobs is the essence of GridGain and computational grid computing in general.

Grid Job Sibling

Grid job siblings are jobs from the same split (they by definition belong to the same task).

Grid Job Context

Grid job context is the context associated with every job. Unlike task session which distributes all parameters to all participants of the task, setting job context attributes is always a local operation. If you set an attribute on job context, other jobs will not know about it, however, this attribute is guaranteed to stay with the job everywhere it goes (e.g. in case of fail-over or job stealing).

Grid Job Collision & Scheduling

When grid job arrives on a node to execute, it will be put into waiting queue. It is responsibility of grid Collision SPI to move jobs from waiting queue to active queue, reject waiting jobs, cancel active jobs, control total number of jobs that can execute concurrently, etc...

This customizable design allows for a fine-tuned control of how jobs are scheduled and executed (like priority of FIFO-based execution). There is also a work stealing collision SPI which allows under-loaded nodes to still jobs from over-loaded nodes.

Grid Job Failover

Job failover happens when grid job on the remote node produces the result that is interpreted as failure for result(...) method on GridTask interface. Grid Failover SPI is responsible to provide failover logic.

Grid Job Preemption

Grid job preemption is a technique that may combine collision resolution, checkpoints, task session, job context, and failover resolution. Basically, job is preempted when it is instructed to stop, save its state and is re-routed to another node where it continues its execution from the last saved checkpoint. This technique can be used when long running jobs have to "survive" preemptive resource management on grid nodes.

The easiest way to preempt a job is to "cancel" a job from Collision SPI, while it is still on the waiting queue. This is also known as "rejecting" a job. User may also wish to cancel an already running job, but then a job would have to react to GridJob.cancel() method in order to optionally save it's state and stop.

See also: Collision SPI
See also: Checkpoint SPI

See also: GridCollisionSpi ^Javadoc
See also: GridCheckpointSpi ^Javadoc
See also: GridTasl.result(GridJobResult, List<GridJobResult>) ^Javadoc

Grid Job Stealing

Job stealing is the concept where under-loaded nodes steal jobs from over-loaded nodes. It allows to uniformly distribute load between grid nodes in cases where jobs get stuck in waiting queue on some node waiting for a long running job to finish. Job stealing is implemented via GridJobStealingCollisionSpi and GridJobStealingFailoverSpi SPIs.

See also: GridJobStealingCollisionSpi ^Javadoc
See also: GridJobStealingFailoverSpi ^Javadoc

Grid Job Checkpoint

Checkpoint is a saved state of the grid job. Checkpoints are available from grid task session. Checkpoints are used together with failover or preemption. In both cases checkpoints allow jobs to continue their execution from the last saved state rather than from the beginning.

Checkpoints also handle an important use case of allowing to failover the "master" node failure when the node that did the original split fails.

See also: Distributed Grid Task Session
See also: Checkpoint SPI

MapReduce

Like in traditional HPC systems (such as MPI) the trademark of computational grids is ability to split process into a set of sub-processes, execute them in parallel, and aggregate sub-results into the one final result (note that split can and often does occur recursively). GridTask ^Javadoc is the main interface for handling MapReduce logic.

Split and aggregate (a.k.a Map/Reduce) design allows to parallelize the process of task execution gaining performance and/or scalability: with two nodes in the grid you can achieve up to 2 times performance increase, with 3 nodes - up to 3 times performance increase, and so on. For a example, with simple and inexpensive 10-nodes grid you can achieve "an order of magnitude" performance increase for your applications.

Grid Enabling

Grid enabling is a process of taking existing code and making it run on the grid. In GridGain you can either use @Gridify annotation or call grid task manually.

Grid Event

Each grid node stores all events that happened on this node locally. It is important to understand that when a grid task is executing it may travel the grid and events for this task's execution can be scattered around the grid. GridGain provides an API to query the grid in a distributed fashion for such events.

See also: GridEvent ^Javadoc
See also: GridEventFilter ^Javadoc
See also: GridEventLocalListener ^Javadoc

Resources Injection

Resource is a GridGain internal object or user defined one (either by Spring or set up manually) that is relevant to the context like task session for the task and job, current node id or grid instance. GridGain uses IOC like way to inject internal or user defined objects into the task or job.

Page Operations

Browse Space