Page History

• Iteration 5 :  In this scenario, C3's predicted value is 250. When the above instances count formula is applied the required instances count for C3 is 250/80 * 1 = 3.125, which means 4 C3 instances are needed. However, as C3's maximum number of instances count is 3, it is not possible to scale more than 3 C3 instances within the G2 group. In this situation, as group scaling is enabled, Stratos will create a new G2 group instance, which has 2 instances of C2 and one instance of C3. As a result, there will be two G2 group instances G2-1 and G2-2. This has been illustrated further in the diagram below:

Application JSON

An application JSON is a structured JSON, that you can define the runtime of your application by using, cartridges, cartridge groups, dependencies, artifact repositories and auto-scaling policies. The application JSON can be converted into an application template, that can be reused to deploy the same application with different deployment patterns.  The deployment policy is the way to define the deployment pattern (e.g., high availability, disaster recovery, cloud bursting, multi-cloud with 4 nines or 5 nines etc.).

The following is the structure of a basic application JSON definition:

• applicationId  

• alias

• components

• groups

• alias

• min/max

• group scaling enable/disable

• cartridges

• min/max

• subscribable info

• groups

• alias

• min/max

• group scaling enable/disable

• cartridges

• min/max

• subscribable info

• cartridges

• min/max

• subscribable info

• dependencies

• startup order

• termination behavior

• dependent scaling

Application deployment policies

In Stratos, deployment policies are used to define the deployment patterns that need to be used.  In grouping, deployment policies are supported at the group level or at the cluster level. Global deployment policies provide a single place to define the deployment policies that correspond to the children (nested groups). Thereby, each application will have a single deployment policy, which defines all the children deployment policies as well. There are many advantages of defining global deployment policies, which are as follows:

• The same applications can be deployed in high availability (HA) or in a burst manner using different deployment policies.
  • This enabled the actual VMs to be started after deploying the deployment policy rather than starting it once the application has been deployed.
  • The deployment policy will always be coupled with an application.
• It is not needed to define multiple deployment policies at the cluster level or group level.
• The partition definition details can also be defined in the deployment policy itself.

The following is the  basic structure of an application deployment policy:

Descriptions on the terminology used in deployment policy definitions are as follows: 

• Network Partition
  A network partition is a logical partition that you can define, in a network bound manner. Thereby, Stratos will map the network partitions with the IaaS regions. The abbreviation for a network partition is as follows: NP
  Example:
  NP1: EC2-US-WEST
NP2: EC2-US-EAST
NP3: OPENSTACK-NY-RegionOne
   
• Partition
  Partitions are also an individual or a logical group within a network partition in a fine grained manner. The abbreviation for a partition is as follows: P
  Example:
  NP1:P1 -> US-WEST -> us-west-1 (N. California)
NP1:P2 -> US-WEST -> us-west-2 (Oregon)
   
• applicationPolicy
  The application policy will have the definition of all the network partitions and partitions that will be used throughout the application.
   
• activeByDefault
  If this property is true, it means that the network partition will be used by default. However, if this property is false, it means that the network partition can be used when all the resources are exhausted (in bursting).
• childPolicies
  Each child policy will refer the network partition and the relevant partition from the applicationPolicy to define their own deployment pattern. Please note that, if you define a childPolicy by referring to group, the underlying cluster (cartridge runtime)/group will inherit the same policy.
   
• max
  Maximum no of instances that can be handled by a partition.
  In terms of a group: Maximum group instances that can be in a partition.
  In terms of a cluster: Maximum number of members that can be maintained for a cluster instance in a partition.
• algorithm
  Stratos support the following two algorithms: round robin and one after another. These algorithms can be used depending on the required scenarios.
  Example: Based on  diagram-04, which has two child policies applied in the cartridge runtime level.
  

  Child policy : sample1
  Partitions : P1, P2
  P1 Max : 4
  P2 Max : 3
  Algorithm : Round robin

   

  Child policy : sample2
  Partitions : P3, P4
  P3 Max : 2
  P4 Max : 3

  Algorithm : One after another
  
  In diagram-04 you can see that C2 has applied the sample1 child policy and all C2 instances are created in P1 and P2 in a round robin manner. C3 has applied the sample2 child policy and as the defined algorithm is one after another, all C3 instances are created in P3 until P3 reaches its maximum instance count, which is 2. Thereafter, C3 instances are created in P4.
• Iteration 1 : Cartridges C2 and C3 are both below the threshold values. Therefore, the minimum instance count will be maintained. As C2 is based on the round robin algorithm and because its minimum instance count is 2, one instance will be created in P1 and another instance will be created in P2. As  C3 is based on the one after the other algorithm and because its minimum instance count is 1, the instance will be created in P3.

• Iteration 2 : In cartridge C3 the predicted memory consumption is 85%, which exceeds the threshold. When the above instances count formula is applied, the required instances count for C3 is 85/80 * 1 = 1.06. Therefore, P3 will increase its count to 2. As C2 is dependent on C3 with a 2:1 (C2 minimum instances : C3 minimum instances) ratio, C2 will need to increase its instance count to 4. As  C2 is based on the round robin algorithm, the instance count will be increased by 1 in P1 and P2 .
   

• Iteration 3: In this case, C2's predicted CPU consumption is 150%. When the above instances count formula is applied, the required instances count for C2 is 150/60 * 2 = 5. As  C2 is based on the round robin algorithm and because the instance count was last adjusted in the P2 partition, the instance count in P1 will be increased by 1. Based on the dependent ratio, the instance count in C3 needs to be increased to 3. As P3 has reached its maximum instance count limit, one instance will be created in P4.
   

• Iteration 4: In this scenario, C3 is under the defined threshold. However, C2 has exceeded the threshold. When the above instances count formula is applied, the required instances count for C2 is 90/60 * 2 = 3. This means that we need to scale down C2's instances to 3 instances. As  C2 is based on the round robin algorithm and because the instance count was last adjusted in the P1 partition, the instance count in P2 needs to be scaled down to 1 instance.  Based on the dependent ratio, C3 should be in scaled down to 2 instances. As C3 is based on one after the other algorithm, the instance in P4 will be terminated.

Metadata Service