Deploying a Space

As part of evaluating GigaSpaces or GigaSpaces, or as part of working with the products in a lab environment, you’ll want to deploy a data grid, also known as a SpaceClosed Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model.. After you’ve deployed the Space, you can perform Space-related activities, such as adding data objects, viewing information about the Space configuration, querying the data in the Space, and viewing logs and alerts.

In order to deploy a Space, you must first have a service grid up and running. Deploying a Space creates 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. that contains only a Space, without any application components.

To deploy a Space to the service grid:

Command:

gs.{sh/bat} space deploy

Description:

Deploys a Space in a stateful Processing Unit.

Before deploying a Space, you must start a container (refer to Starting a Container).

Parameters and Options:

Item Name Description Comment
Parameter name Provide the name of the Space you are deploying. If you run the command without defining any options, a non-clustered Space is deployed.
Option --partitions Define how many primary partitions the Space should contain, using the syntax --partitions=n.
Option --ha High availability. Adds a single backup partition per primary partition.
Option --requires-isolation

If this Space should not share a container, adding this option provisions the Space in a dedicated container.

 

  

The "requires isolation" configuration for Processing Units is deprecated and will be removed in a future release.

Input Example:

This example deploys a Space named mySpace with high availability and two partitions, two instances for the first parition (mySpace~1_1,mySpace~1_2) and two for the second partition (mySpace~2_1,mySpace~2_2). For this example, you must start at least 2 containers.

<GS_HOME>/bin/gs space deploy --ha --partitions=2 mySpace

<GS_HOME>/bin/gs.sh space deploy --ha --partitions=2 mySpace

Path

POST /spaces

Description:

Deploys a Space in a stateful Processing Unit. If you run the command without defining any options, a non-clustered Space is deployed.

Example Request: 

curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/plain' 'http://localhost:8090/v2/spaces?name=mySpace&partitions=3&backups=true&requiresIsolation=true'

This example deploys a Space named mySpace with high availability, three partitions and isolation.

Options:

Option Description Required
name Provide the name of the Space you are deploying. Yes
ha High availability. Adds a single backup partition per primary partition. No
partitions= <partitions> Define how many primary partitions the Space should contain, using the syntax –partitions=n. No
requiresIsolation If this Space should not share a container, adding this option provisions the Space in a dedicated container. No

The "requires isolation" configuration for Processing Units is deprecated and will be removed in a future release.

  1. From the Deploy menu on the menu bar, select Space.

  2. In the Space Deployment dialog box, do the following:

    1. In the Space name box, type a name for the Space.

    2. (Optional) If you want this Space to be secure, do the following In the User Login Details area:

      • Select Secured Space.

      • Provide the user credentials in the User Name and Password boxes.

    3. In the Cluster Info area, apply the required configuration details.

    4. In the Cluster schema box, specify the SLA definitions (cluster topology):

      • None - A standalone Space.

      • Partitioned - A cluster that is partitioned across the instances that are specified.

      • Sync_replicated - A cluster with synchronous replication across the instances that are specified.

      • Async_replicated - A cluster with asynchronous replication across the instances that are specified.

    5. In the Number of Instances box, specify the number of primary Space instances to deploy in the cluster.

    6. (For partitioned clusters) In the Number of Backups box, define the number of backup Spaces for each primary Space. The number of backups can be zero or one.

    7. In the Max Inst. per VM box, define the maximum number of Space instances each virtual host may contain (the default is 1).

    8. In the Max Inst. per VM box, define the maximum number of Space instances each physical host may contain.

    9. If you have more than one host, you can specify on which host to deploy the primary Space instances.

  3. (Optional) If you want to use a configuration file to specify the SLA definitions, or if you want to override your defined SLA definitions in specific scenarios, click Next.

  4. Click the Browse button next to the SLA override box and select the sla.xml file that you want to use.

  5. If your environment contains zones, you can do one of the following:

    1. Select the Select Zone option and:
      • From the list on the left, select which zone to use for the -zone deployment parameter.
      • In the Max. Instances (partitions) number area on the right, define the maximum instances per zone (`-max-instances-per-zone` deployment parameter).
    2. If you don’t want to specify a zone, select Any Zone.

  6. Click Deploy.

Refer to the GigaSpaces Management Center topics in the Administration section.

Refer to the Admin API topics in the Developer Guide.