Global vs. Local GSM
This page is irrelevant for GigaSpaces Manager, and explains how to setup multiple GSMs manually to achieve high availability. This technique is still supported, but outdated, and will be phased out in the future. It's highly recommended to use Manager instead, which is both easier to use and provides superior high availability.
Local GSM
Similar to the lookup service you may run a global GSM 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. or a local GSM. In this case a local GSM will allow you to control the host machine where the GSM and its deploy folder will be located (configured via the com.gs.deploy
system property). The GSM deploy folder used at the deployment time when provisioning a deployed PU 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. into exiting GSCs or once a new GSC Grid Service Container.
This provides an isolated runtime for one (or more) processing unit (PU) instance and exposes its state to the GSM. is started, where it is downloading from the GSM its PU configuration (pu.xml) and relevant PU files.
When performing hot deployment to support rolling upgrade or other maintenance activities the location of the GSMs is important since you must place the updated PU files in the machines running the GSM. A GSM may be running in an active or slave mode - it is recommended to place updated PU files on both GSM's deploy folder. If you have a large grid (over 100 GSCs) or a large PU (over 10MB) with many files you may want to choose specific machines with special network or CPU capacity to run the GSM - This is another scenario where the local GSM setup should be considered.
Local Setup Example
With the following example we have Machine A
, Machine B
, Machine C
and Machine D
running the service grid. We would like to start two GSMs. We have decided that Machine A
and Machine D
will be running a GSM.
The agent on these machines will be started using the following:
gs-agent --gsm=1
Machine B
and Machine C
will not run a GSM. The agent on these machines will be started using the following:
gs-agent
Upon startup the only Machine A
and Machine D
agent's that are configured to start a local GSM will have it running. In case of Machine A
or Machine D
failure the system will have a single GSM. Service Grid 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. components (LUS 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. , GSC) will be notified for this missing GSM. Once the missing GSM will be restarted on the relevant machine Service Grid components will be notified. With a network running a DNS - you may start a new machine with the same Host name to support total machine failure while keeping number of running GSMs intact.
Global GSM
With the global GSM setup - Once a running GSM failed (as a result machine termination, or GSM process failure) , a different agent that is not running a GSM will be starting a GSM to enforce the SLA specified at the agent startup. In this case all machines are equal and may run a GSM. Two GSMs is the recommended number per service grid.
Global Setup Example
With the following example we have Machine A
, Machine B
, Machine C
and Machine D
running the service grid.
All agents are started with the same command instructing them to maintain two global GSMs across the entire service grid:
gs-agent --global.gsm=2
Upon startup the agents will decide which ones will run a GSM and which won't.