The partitioned cache provides a simple way to add more partition instances, scaling out data and messages based on a certain field in the message attributes. Its main limitation is that data that is already stored in the partition is not re-partitioned when a new node is added or removed.
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.
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 Using CLI
To deploy a partitioned cache using the Service Grid CLI:
Use the gs-all utility to start the Grid Service Monitor (GSM) and Grid Service Container (GSC). This utility launches both GSM and GSC under the same virtual machine.
When deploying a partitioned 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).
Open the command line shell (gs) and change directory to config/deployment
Use the command deploy partitioned_cluster.xml command to deploy the partitioned cache, utilizing the partitioned_cluster.xml deployment descriptor file.
The following output is displayed:
s> deploy partitioned_cluster.xml
total 1
Deploying [Partitioned Cluster], total services [2] ...
[1] Partitioned GigaSpace provisioned to 11.0.0.6
- There are [1] service provisioning requests outstanding
Deployment notification time 5015 millis, Command completed
To deploy the second cache instance, run a second GSC instance. The Service Grid automatically detects the availability of the new GSC instance and deploys the second cache instance into the new container.
Monitoring the Deployed Cache
Use the list command to view the cache instances, the lookup groups they are assigned to, and their host locations.
The list space utility can provide more information about the space instances, such as the number of entries and their basic configuration:
Option
Description
list space
Lists all spaces in the network
list space entry
Lists all spaces with a specific count per class
list space stats
Lists all spaces, the count per class, and runtime statistics
Deploying Partitioned Space Using Admin UI
To deploy a partitioned cache using the Service Grid Admin UI:
Start the Service Grid Admin UI, using the gs-ui utility.
Start the Deployment Wizard by clicking the Deploy button (see screenshot below), and select A Proactive 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 the Space Name field, enter a name to identify the space. This name is also used to to define the cache cluster name.
In the Initial Instance Count field, type 2.
In the Maximum Instance Count field, type 2.
From the Space Schema drop-down menu, select cache.
From the Cluster Schema drop-down menu, select partitioned to deploy a partitioned cache.
Click here to view more details about the deployment parameters.
Parameter
Description
Deployment Name
The cache service name.
Space Name
The space name. Also used to define the cache cluster name.
Initial Instance Count
The minimum number of instances that need to be running at any given point of time. The actual number of instances depends on the availability of the GSC instances. This number is used to handle failover – if the actual number of instances is less than the minimum number, the Service Grid proactively tries to re-deploy a failed service to another available machine.
Maximum Instance Count
The maximum number of instances that need to be running. Relevant for scaling policy – if a scaling event happens (e.g. CPU utilization exceeds a certain level), a new instance is deployed and relieves some of the load from the existing cluster members. These instances are auto-deployed and un-deployed up to the maximum number of instances specified.
Space Schema
Determines the configuration type for the space. Default selects the default schema that comes with GigaSpaces. It can be overwritten by the gs.space.url.arg.schema property. See Schema Basics for more details.
Cluster Schema
Determines the cluster topology. The options in the drop-down menu are based on the basic topologies supported by GigaSpaces. These value can be overwritten by the gs.space.url.arg.cluster_schema property. See Cluster Schemas for more details.
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 Close to abort the process.
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