Multiple Instances (Scaling)
This page describes different concepts involved in scaling components of your application blueprint.
When we refer to multiple instances and scaling, we are actually referring to the number of node instances each node template will have on deployment,
and changes made to that number during runtime after the deployment is created, using the
There are two ways of specifying this configuration in the application blueprint. The first is aimed at configuring this number on a per node
template basis, using the
scalable capability configuration. The second method is mostly aimed at configuring the number of instances on a group basis
where the group contains several node templates.
We will show both and what will follow is an explanation of the difference between these two methods,
after which we will show how the number of instances for different nodes may be changed during runtime.
To specify the initial number of instances a node template will have, the node template
capabilities.scalable properties should be configured.
For example, to configure some vm node template so that it will be deployed with 5 initial instances, the following configuration may be used:
node_templates: example_vm: type: cloudify.nodes.Compute capabilities: scalable: properties: default_instances: 5
See Node Templates for more details.
Scaling Policy and Scaling Groups Configuration
To specify the initial number of instances a group of node templates will have as a single unit, use scaling policies and groups.
For example, to configure a scaling group for a vm and an ip, the following configuration may be used:
node_templates: vm: type: cloudify.nodes.Compute ip: type: cloudify.nodes.VirtualIP groups: vm_and_ip: members: [vm, ip] policies: scale_policy1: type: cloudify.policies.scaling properties: default_instances: 5 targets: [vm_and_ip]
When deployed, 5
vm node instances and 5
ip node instances will be created.
See Policies for more details.
Combining Node Template
scalable With Scaling Groups
A node template may have have its
scalable capability configured and in addition, may also be included in some scaling group. Consider the following
node_templates: vm: type: cloudify.nodes.Compute capabilities: scalable: properties: default_instances: 3 groups: vm_group: members: [vm] policies: scale_policy1: type: cloudify.policies.scaling properties: default_instances: 5 targets: [vm_group]
When deployed, 15 (
3 * 5)
vm node instances will be created.
Scaling groups may be nested. (i.e. a scaling group may have a different scaling group as one if its members).
get_attribute intrinsic function in the blueprint
with explicit reference to a node by its name (i.e. not
TARGET) between members of the same scaling group may be used in places where
otherwise, an ambiguity would arise. See
get_attribute intrinsic function for
connected_to/depends_on Relationship Semantics
A previous example showed how to use scaling groups in order to scale a group of node templates together.
In this section, we will discuss how
connected_to/depends_on relationships behave between node instances that belong to the same scaling
Generally, when two node templates are related via a
connected_to/depends_on relationship, relationship instances will exist between all node instances of the source node to all node instances of the target node. This is further elaborted here under the
Similar logic applies between node templates that belong to the same scaling group. The exception here, is that the relationship instances between the node instances will not “escape” scaling group boundaries. This is best explained with an example.
Consider the following:
node_templates: application: type: web_app capabilities: scalable: properties: default_instances: 2 relationships: - type: cloudify.relationships.connected_to target: database database: type: database capabilities: scalable: properties: default_instances: 2 groups: application_and_database: members: [application, database] policies: scale_policy2: type: cloudify.policies.scaling properties: default_instances: 2 targets: [application_and_database]
The previous blueprint snippet, when deployed, will have 2 instances of the
application_and_database scaling group. Each scaling group will contain 2 node instances of the
application node and 2 node instances of the
The following diagram aims to explain how will the different node instances be connected. Specifically, it aims to show how
connected_to relationships don’t “escape” scaling group boundaries:
The next diagram builds upon the blueprint shown previously in this page where we had 5
vm_and_ip scaling group instances with a
ip node instances in each scaling group instance.
vm node were to have a
connected_to relationship to the
ip node, this is how the relationships would behave:
contained_in Relationship Semantics
Implicit Scaling Group Membership
B and node
B is part of some scaling group
S, then node
A is also implicitly included in
For example, in the following example where a
db node template is
vm node template, both group definitions are
node_templates: vm: type: cloudify.nodes.Compute db: type: cloudify.nodes.DBMS relationships: - target: vm type: cloudify.relationships.contained_in groups: vm_group: members: [vm, db] # is equivalent to vm_group: members: [vm] policies: scale_policy1: type: cloudify.policies.scaling targets: [vm_grop]
Scaling groups and
The semantics for
contained_in relationships are described in detail here.
Building upon the semantics described in the previous link, we now describe how scaling group fit in.
Consider the following:
node_templates: vm: type: cloudify.nodes.Compute capabilities: scalable: properties: default_instances: 2 app: type: web_app relationships: - type: cloudify.relationships.contained_in target: vm db: type: database relationships: - type: cloudify.relationships.contained_in target: vm groups: app_and_db: members: [app, db] policies: scale_policy2: type: cloudify.policies.scaling properties: default_instances: 2 targets: [app_and_db]
Deploying the previous blueprint produces this topology:
It can be seen from the diagram that two
vm node instances were deployed, as expected from the blueprint definition.
vm node instance has two
db and two
app node instances contained in it. Or, put differently, each
vm node instance “contains” 2 instances of the
app_and_db scaling group
as defined in the blueprint.
This shows that scaling groups can be “contained in” node templates when their members are
contained_in some other node templates.
To change the number of node instances during runtime (i.e. after the deployment is installed), use the
See Scale Workflow for more details.