XAP

Service Grid

This section describes the available GigaSpaces runtime configuration parameters.

The basic unit of deployment in the GigaSpaces GigaSpaces platform is the Processing Unit.

After is it packaged, a Processing UnitClosed This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. is deployed to the GigaSpaces runtime environment, which is called the Service GridClosed A built-in orchestration tool which contains a set of Grid Service Containers (GSCs) managed by a Grid Service Manager. The containers host various deployments of Processing Units and data grids. Each container can be run on a separate physical machine. This orchestration is available for XAP only.. The Service Grid is responsible for materializing the Processing Unit's configuration, provisioning its instances to the runtime infrastructure, and making sure the instances continue to run properly over time.

When developing your Processing Unit, we recommend running and debugging the Processing Unit within your IDE. Deploy it to the Service Grid when you want to test it in the real-life runtime environment, and for production.

Architecture

The Service Grid is composed of the following components:

In previous GigaSpaces versions, the Grid Service Manager and Lookup Service were standalone components. Starting in GigaSpaces version 12.1, we recommend starting the GigaSpaces Manager instead. In addition to this being simpler, it also offers better consistency and protection against network segmentation (via Apache Zookeeper), as well as the RESTClosed REpresentational State Transfer. Application Programming Interface An API, or application programming interface, is a set of rules that define how applications or devices can connect to and communicate with each other. A REST API is an API that conforms to the design principles of the REST, or representational state transfer architectural style. Manager API.

For backward compatibility and to simplify the upgrade process, you can still start the LUSClosed Lookup Service. This service provides a mechanism for services to discover each other. Each service can query the lookup service for other services, and register itself in the lookup service so other services may find it. and GSMClosed Grid Service Manager. This is is a service grid component that manages a set of Grid Service Containers (GSCs). A GSM has an API for deploying/undeploying Processing Units. When a GSM is instructed to deploy a Processing Unit, it finds an appropriate, available GSC and tells that GSC to run an instance of that Processing Unit. It then continuously monitors that Processing Unit instance to verify that it is alive, and that the SLA is not breached. independently. However, future releases may include additional new features and functionality that will require using the GigaSpaces Manager.

All of the above components are fully manageable from management interfaces such as the GigaSpaces Management Center, the command line interface, and the Admin API.

Grid Service Manager

When a Processing Unit is uploaded to the Grid Service Manager (GSM), it analyzes the deployment descriptor and determines how many instances of the Processing Unit should be created, and which containers should host them. The GSM then ships the Processing Unit code to the relevant containers, and instructs them to instantiate the Processing Unit instances. This phase in the deployment process is called provisioning.

After it is provisioned, the GSM continuously monitors the Processing Unit instances to verify that they are functioning properly. When a certain instance fails, the GSM identifies it and re-provisions the failed instance to another GSCClosed Grid Service Container. This provides an isolated runtime for one (or more) processing unit (PU) instance and exposes its state to the GSM., in order to enforce the Processing Unit's SLA.

Grid Service Container

The Grid Service Container (GSC) can be thought of as a node on the Service Grid, which is controlled by the GSM. The GSM sends deployment and un-deployment commands of the Processing Unit instances to the GSC. The GSC reports its status to the GSM.

The GSC can host multiple Processing Unit instances simultaneously. The Processing Unit instances are isolated from each other using separate Class loaders (in java) or AppDomains (in .NET).

It is common to start several GSCs on the same physical machine, depending on the machine CPU and memory resources. The deployment of multiple GSCs on a single or multiple machines creates a virtual Service Grid. The GSCs provide a layer of abstraction on top of the physical layer of machines. This enables deploying clusters in various deployment typologies for enterprise data centers and public clouds.

The Lookup Service

The Lookup Service (LUS) provides a means for services to discover each other. Each service can query the LUS for other services, and register itself in the LUS so other services can find it. For example, the GSM queries the LUS to find active GSCs.

The LUS is used primarily to establish the initial connection. After service X discovers service Y via the LUS, it usually creates a direct connection without further involving the LUS.

Service registrations in the LUS are lease-based, and each service periodically renews its lease. That way, if a service hangs or disconnects from the LUS, its registration gets cancelled when the lease expires.

For more information on the LUS, refer to The Lookup Service.

Grid Service Agent

The Grid Service Agent (gs-agent) is a process manager that can spawn and manage Service Grid processes (operating-system-level processes) such as the GSM, GSC, and LUS. Typically, the gs-agent is started with the host machine's startup. Using the agent, you can bootstrap the entire cluster very easily, and start and stop additional GSCs, GSMs and LUSs as necessary.

Usually, each machine runs a single gs-agent. If you are setting up multiple Service Grids separated by Lookup Groups or Locators, you will probably start a gs-agent per machine, per group.

The gs-agent exposes the ability to start, restart, and kill a process either using the Administration and Monitoring API or the GigaSpaces Management Center.

High Availability

High availability is acheived via redundancy. We recommend setting up and starting three GigaSpaces Managers (refer to GigaSpaces Manager High Availability).

Alternatively, it is possible to manually configure and start multiple LUS and GSM instances. For more information, refer to the following topics:

Advanced

Process Management

The gs-agent manages operating system processes. There are two types of process management, local and global.

Local processes simply start the process type (for example, a Grid Service Container) without taking into account any other process types run by different GSAs.

Global processes take into account the number of process types (a Grid Service Manager for example) that are currently run by other GSAs within the same lookup groups or lookup locators. It will automatically try and run at least X number of processes across all the different GSAs (with a maximum of 1 process type per GSAClosed Grid Service Agent. This is a process manager that can spawn and manage Service Grid processes (Operating System level processes) such as The Grid Service Manager, The Grid Service Container, and The Lookup Service. Typically, the GSA is started with the hosting machine's startup. Using the agent, you can bootstrap the entire cluster very easily, and start and stop additional GSCs, GSMs and lookup services at will.). If a GSA running a globally managed process type fails, another GSA will identify the failure and start it in order to maintain at least X number of global process types.