The partitioned space with backup is designed to address strict stateful application requirements. In this mode, continuous high availability of data in each partition is guaranteed. Scaling of data is achieved through re-assembly of partition nodes across available Grid Service Containers (GSCs), assuming that each GSC represents a single VM. Continuous high availability is maintained through a replicated backup instance of a partition running on another machine. If one instance fails, the data is not lost and can be recovered through replication.
The partitioned cache can be useful as a front-end to a centralized data store, via CacheLoader. In this scenario, the data is loaded from the database if not in cache, allowing you to increase cache capacity by adding more memory instances to the partition. Another common scenario is stateless event processing, such as data streaming applications (market data is one example); events are constantly refreshed through the stream, and the partition balances itself over time when new nodes are added or removed.
The partitioned cache is set for a deployment of three nodes. Two of the instances are marked as required, meaning that the Service Grid makes its best effort to keep the two instances running on any available machine, even during a failover scenario. The Service Grid is also configured to run a single cache instance per container. In a case of load (high CPU utilization), the Service Grid tries to launch another cache instance if a Service Container is available for it.
Partitioned cache with backup can presently be run through the Admin UI only, not through the CLI.
The number of partition instances is kept constant throughout the lifecycle of the cache. It is the number of instances per Grid Service Container (GSC) / Virtual Machine that varies. Scaling is achieved by utilizing the available memory capacity in each GSC / VM. Relocation of partition instances can be done at any time, even dynamically. Therefore, it is normally required that the number of partitions in a cluster deployment be higher than the amount of available VMs. When a new GSC / VM joins the cluster, one of the existing partitions can be re-deployed to that machine.
Deploying Partitioned Space with Backup Using Admin UI
To deploy a partitioned cache with backup using the Service Grid Admin UI:
Start the Service Grid Admin UI, using the gs-ui utility.
When deploying a fault-tolerant space, you must start another container before the deployment, by executing <GigaSpaces Root>\ServiceGrid\bin\gsc.bat. Otherwise your deployment won't be successful. Alternatively, you can start two containers using the service launcher (see Running Service Grid).
Start the Deployment Wizard by clicking the Deploy button (see screenshot below), and select A Fault Tolerant Partitioned Space as the deployment type. Click Next.
A – Deployment button.
Selecting Application as the deployment type defines a Generic Application Service (see Compute Grid).
Set the deployment parameters:
In the Deployment Name field, enter a name to identify the deployed service. In this mode a service is deployed per partition. Each service represents the combination of partition and its backup, and is named <Deployment Name><Partition Instance ID>.
In the Space Name field, enter a name for the space, also used to define the cache cluster name. This name is the same for all space instances, backup and primary.
In the Number of Backups field, type 1 to start one backup node per partition.
In the Number of Partitions field, type 2 to start two partition nodes.
From the Space Schema drop-down menu, select cache. The space schema can be overwritten by the gs.space.url.arg.schema property.
To create a Deployment Descriptor based on the default settings, click the Advanced button. This opens the Deployment Descriptor Generator, allowing you to modify the default settings.
When you are done, press Next.
In this step you determine the location of the code of the GigaSpaces service, by selecting a codebase server. This enables the Service Grid to dynamically deploy GigaSpaces instances on machines that do not have GigaSpaces installed. The server location is provided as a URL.
Select one of the GSM instances from the list.
Click Verify. This verifies that the location provided by the deployment descriptor is available. If not, another GSM instance, which maintains a reference to the service, is suggested.
The verification step is required only if the codebase server provided in the deployment descriptor is unavailable.
If you clicked Verify and the server is not verified successfully, this indicates that your HTTP port is not set correctly in the Service Deployment Descriptor. Open the descriptor file, and edit the tag <Parameter Name="httpPort" Value="9010" />, under <Component Name="com.gigaspaces.start">. Set the Value attribute to the current port set on your codebase server.
Once the verification finishes successfully, the Deploy button becomes enabled.
Click the Deploy button to start the deployment process. Current deployment status is shown; wait for deployment to finish or press Dismiss to abort the process.
Viewing the Deployment
In the deployment view, you can see the deployment status: which containers are running, which space is deployed on each container, and so on.
A – the newly deployed space is added to the Service Deployments tree.
B – the green boxes represent the services for the selected deployment. Double-clicking one of these boxes leads you to a window called Space Administration UI, which provides the options to start the space browser and to terminate the service.
C – these buttons represent the containers that are currently running. When pressed, each button shows details of the spaces running in the specified container.
D – a list showing the details of the spaces running in the specified container.
As you can see in the deployment view, there are two services created Space.1 and Space.2. The total amount of spaces is 4 (two partitions with one backup per partition). In the container view, you can see that the Grid Service Monitor (GSM) automatically spreads the cache instances across the Virtual Machines, which results in two spaces per VM (parition1 + backup2 on GSC1, partition2 + backup1 on GSC2).
We need your help to improve this wiki site. If you have any suggestions or corrections, write to us at techw@gigaspaces.com. Please provide a link to the wiki page you are referring to.
Previous release
Add Comment