Space Deployment (Magic xpa 4.x)
By default, once the Grid Service Agent (GSA) is executed (GigaSpaces-xpa\bin\gs-agent.bat), it exeutes GigaSpaces-xpa\bin\DeployandStartProjects.bat, which is responsible for the Magic Space deployment and the startup of the Magic xpa servers. The Magic Space can be deployed only once, so it will only be deployed by one of the started OS services.
The deployment process uses SLA settings defined in the MgxpaGSSpace_sla.xml file (as explained in the Space Clustering SLA section).
If only one machine was running during the Magic Space deployment process, and there was no restriction in the SLA definition related to a single machine (max-instances-per-machine), this machine will hold all the partitions. Containers starting on other machines after the deployment was complete will not hold any Magic Space partitions, and the single machine that is currently running the Magic Space is now considered a single point-of-failure.
When you have more than one machine that is part of the grid, you will want to have control over when the Magic Space is deployed. When the Grid Service Agent (GSA) loads, and the machine becomes a part of the grid, that machine will not host a part of the Magic Space if there is already a Magic Space deployed on the grid.
To spread the partitions over multiple machines when one machines holds all of the partitions, you have the following options:
-
You can manually rearrange the partitions from the GigaSpaces UI. To do this, open the Gigaspaces UI Hosts tab, and stand on the Hosts entry at the top of the hierarchy tree on the left. In the Services pane, on the right side of the Gigaspaces UI screen, you will see a tree of containers and partitions. You can now select a partition (either primary or backup) and drag it to a different container, as shown in the following image.
-
You can restart the backup GSC and GigaSpaces will provision the grid. You do this as follows:
a. Park on the GSC node of the backup partition.
b. From the context menu, select Restart.
GigaSpaces will attempt to place the backup container on the second computer, as you can see from the image below. This provides redundancy for your application. If the secondary machine is not available, GigaSpaces will create the backup partition on the current machine. When the secondary machine becomes available again, GigaSpaces may not automatically reposition the backup on the secondary computer. You may need to perform the operation manually.
-
You can use the max-instances-per-machine restriction in the SLA. This method should be restricted to a cluster of at least three machines, and it ensures that at least two machines in the grid will run the Space partitions.
a. In the MgxpaGSSpace_sla.xml file, define the max-instances-per-machine ="1" entry as explained in the Space Clustering SLA section.
b. When the automatic deployment process starts, it will not be completed until at least two machines are hosting the Space partitions.
Memory allocation for the various GigaSpaces entities is determined in a batch file called setenv.bat. This file is found under the <Magic xpa installation>\GigaSpaces-xpa\bin folder.
In this batch file, you will find settings for the GSA, GSM, and LUS entities:
-
set XAP_GSA_OPTIONS=-Xmx64m
-
set XAP_GSM_OPTIONS=-Xmx64m
-
set XAP_LUS_OPTIONS=-Xmx64m
These entities have quite a small memory footprint, so you can leave these settings as is. The GSC is the container that runs the Space partitions and holds all of the data that flows through the projects. The GSC entity in the batch file is:
If you encounter any memory-related issues with the GSC, you should consider increasing this value.
