7.2 Deployment Option Modelling
7.2.1 Concepts
|
An application's deployment can be modelled at the same time as the application is modelled.
Deployment Options
can be added at the application level - i.e. as a child node of the application node in the model;
Pu Deployment Options can be added at the processing unit level.
Both types of deployment options can be named, or left unnamed - with a missing or blank name.
Named deployment options are for deployment;
unnamed options are considered to be the default for that (application or PU) level.
Deployment Options and Pu Deployment Options with the same name define different aspects of that named deployment.
For each item of information in the final requested deployments,
Cloudtran uses a search approach so that sensible defaults can be set for a deployment.
For example, you might want to not specify the number of partitions and backups for most of the PUs
and pick that up from a default, but also have the ability to override this for a given PU.
Cloudtran implements the following search order to allow to allow you to do this
(using 'cloudDepl' as the deployment name):
- First it searches for a value in the Pu Deployment Option named 'cloudDepl', if one exists
- Then it looks for the value in the unnamed Pu Deployment Option, if one exists
- Next it looks in the named Deployment Option named 'cloudDepl' (at the application level), if one exists
- The unnamed Deployment Option (at the application level)
- Finally, if the above does not find a value, a built-in default.
Each named Deployment Option can specify a target - these are
- CommandLine - a windows command line environment - this is the default
- AmazonEC2 - for deploying to the Amazon EC2 cloud. This is used in conjunction with GigaSpaces Cloud Tools.
- Unix - a unix deployment environment. This is, at present, untested
There is no need to model deployment to the Eclipse environment because it is always generated.
(It is given a name of 'Eclipse', so you can't use this to model other environments.)
See the Eclipse Deployment section for more details.
7.2.2 Machine Estates
|
This is a collection of machines that the application can be deployed to. Machine Estates are separate from the Deployment Options and there may
be many machine-estates in the system. Machine Estates are modelled as peers of Deployment Options - child objects of the Application.
The idea is to allow the modeller to define a set of machines that may be used in a number of deployments.
The definition of a Machine Estate should be fairly self explanatory. There is a name of the machine estate and a list of the machines in the estate. The machines can be identified
by name - which can be a machine name or and IP address, or by a machine class. So a Processing Unit can be deployed to a specific machine or a class of machine - but you don't care
which specific machine is used.
7.2.3 Machine Allocation
|
The allocation parameter on the Deployment Option links the deployment with the machines to which it is going to be deployed.
The allocation parameter is a string which is parsed to determine which Processing Unit goes on which machine. The allocation is parsed and the deployment scenario is calculated
from the information given. It also includes in the calculation the various options defined in the Deployment Option and the individual PUDeployment Options.
The allocation parameter references machines in a machine estate or references Amazon EC2 machine classes.
The Warehouse example has two Deployment Options that use the allocation parameter.
The first for an in-house machine estate which contains 2 machines QCore1 and QCore2 and the second for a deployment to Amazon EC2
Taking the in-house example the allocation parameter on the 'QCORE' Deployment Option is:
WarehousePU:QCore1; CoordinatorPU:QCore2
What this says is that the Warehouse Processing Unit (PU) must be on QCore1 and the Coordintor PU must be deployed on QCore2 . The other 4 processing units can be deployed anywhere.
In the AmazonTest Deployment Option the allocation parameter is
CoordinatorPU:HighCpuMedium->HighCpuExtraLarge;
EC2Client, WarehousePU:Large->ExtraLarge;
ClientPU, SupplierPU, CustomerPU:Large,vmcount=*,machines=2
This says the Coordinator PU needs to be deployed to a HighCpuMedium which will (if need be) scaled out to a HighCpuExtraLarge. There will only be 1 virtual machine (GSC) on the machine
as the 'vmcount' defaults to 1.
The EC2Client PU and the Warehouse PU start on a 'Large' machine and will scale out to an 'ExtraLarge' machine.
The remaining three Processing Units (ClientPU, SupplierPU, CustomerPU) are all to be deployed onto 2 Large machines.
The 'vmcount=*' means that as many virtual machines (GSCs)
can be started to ensure all the Processing Units will be deployed to the 2 machines. The AmazonTest Deployment Option defines that there will be 1 primary and 1 backup
for each Processing Unit, this means there will be 3 GSCs started the 2 Large machines.
7.2.4 How To
|
To model a Deployment Option select the application and add a new child Deployment Option:
Set the required options. In this case the name is set to 'deployment1'.
The number of partitions is 2 and the number of backups is 1.
If you want to amend the target then select the appropriate option from the 'Target' property.
This will create a command line deployment called 'deployment1'. All processing units will have 2 partitions and 1 backup.
If you want to override this deployment scenario for the CongestionZoneProcessor Processing Unit create a Pu Deployment Option
Set the name to be 'deployment1'. As this has the same name as the Deployment Option it will override the options defined in the Deployment Option.
So the CongestionZoneProcessor will have 4 partitions with 2 backups.
| 
