Stratos is able to start up or terminate instances (single tenant) according to the demand. In Stratos terms this is referred to as subscription and unsubscription. Subscription will bring up a cluster, with the minimum number of instances, and unsubscription will terminate the instances. Prior to subscription, it is required to define and deploy the relevant cartridge in order to communicate to Stratos the details about the service that you will be providing, the IaaS that will be used, etc.
In previous Stratos releases, each cluster corresponding to a subscription was isolated and there was no connection between multiple clusters. However, in a real world use cases, there are requirements to have multiple clusters in a grouped manner, where one or more clusters can depend on some other clusters. Therefore, in this release composite applications support has been introduced and cartridge subscription has been made obsolete.
Composite application support, which is also referred to as cartridge grouping, provides the ability to deploy an application that has different service runtimes with their relationship and dependencies. Further, each of the service runtimes in the application can scale independently or jointly with the dependent services. Thereby, users can defined applications with its required service runtimes, deployment and auto scaling policies, artifact repositories and all dependencies in simple structured JSON file that Stratos can understand and provision all the required runtimes in a defined manner.
The various terminologies used with composite application support, which are groups, dependency, startup order, group scaling, dependence scaling, termination behaviors and metadata service, have been explained in-depth in the following sub-sections.
A cartridge group, is a metadata that you can define by grouping several cartridges together. Composite applications in Stratos, support nested groups within a group as inter-dependencies among group members. Cartridge groups define the relationship among a set of groups and a set of cartridges. The relationship among the children of a group can be start up order, termination behavior and any scalable dependencies. Writing a group definition provides the ability to re-use the same frequently used group as needed in different composite applications. See diagram - 01 for a sample group.
The following is the structure of a basic service group JSON definition:
Within a group or an application you can define the startup order that needs to be maintained between two or more dependent cartridges or groups.
Example: Based on diagram-01:
Termination behavior allows you to define the action that needs to be taken if any dependency runtime failure occurs in an application. Failures are identified as not satisfying the required minimum member count. The following are the three termination behaviors that are supported:
Example: Based on diagram-01:
When dependent scaling is defined among members (cartridge or a group), and scaling (scaling up or down) is taking place for any of the members, all other dependent members will also scale in order to maintain the defined ratio.
Example: Based on iterations 1 to 4 in diagram-02.
Group G2, cartridge C2 and cartridge C3 have been defined in the dependent scaling list. Four auto-scaling iterations are considered in this example to illustrate how scaling up and scaling down takes place with dependent scaling. Note that cartridge C2 and C3 have two different auto-scaling policies, one is based on the CPU utilization and other is based on memory consumption. Furthermore, in cartridge C2 the number of minimum instances in the cluster is 2 and the maximum number of instances are 6; while. in cartridge C3 the minimum number of instances is 1 and the maximum number of instances are 3.
Iteration 2 : In cartridge C3 the predicted memory consumption is 85%, which exceeds the threshold. The following equation needs to be used to calculate the required C3 cartridge instances that are required to handle this predicted value.
The required C3 instances = 85/80 * 1 = 1.06. When dealing with instances, the minimum required instance count is one. Therefore, in situations like this we need to round off the required instance count to the nearest instance, which means that we need 2 C3 instances to handle the predicted load.
As C2 depends on C3 with the a 2:1 (C2 minimum instances : C3 minimum instances) ratio and the C3's new instance count is 2, Stratos will create 2 new C2 instances, to make a total of 4 C2 instances in order to maintain the defined ratio. Furthermore, note that at the time C2 was under the threshold value, but priority is always given to dependent scaling decisions.
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. Since C3 is dependent on C2 with a ratio 2:1, C3 will increase its instance count to 3.
Iteration 4: In this scenario, C3 is under the defined threshold, but 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. Based on the dependent ratio, C3 should be in scaled down to 2 instances. Since C3 is below the auto-scaling threshold scaling down takes place.
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:
group scaling enable/disable
group scaling enable/disable
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 following is the basic structure of an application deployment policy:
Descriptions on the terminology used in deployment policy definitions are as follows:
NP1:P1 -> US-WEST -> us-west-1 (N. California)
NP1:P2 -> US-WEST -> us-west-2 (Oregon)
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
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.
Many REST APIs have been exposed to add, fetch and delete metadata in the metadata service. Therefore, when there are multiple cartridges all the instances will invoke REST APIs to publish their details to the metadata service. When information sharing is required between the cartridge instances in a composite application, the respective cartridge instance will invoke a REST API to retrieve the required metadata.
The metadata client is used when third party Stratos components (e.g., Cloud Controller, Auto-scaler, Stratos Manager) need to communicate with the metadata service. However, other clients (e.g., Cartridge Agent) that have the JW OAuth token can communicate with metadata service without the use of the metadata client. The metadata client is a Java API that wraps the client to transform the requests and responses. Therefore, third party Stratos components will be able to use the metadata client to add, fetch and delete metadata in the metadata service. For example, the metadata client will be used when the Git repository URL, which is in the Cloud Controller, needs to be added to the metadata table.
The following flow explains how to get a composite application working with Stratos:
Add a network partition.
Add a deployment policy.
Add an auto-scaling policy.
Add a cartridge.
Add a cartridge group.
Add the application.
Add the application policy.
Deploy the application.
After the composite application is deployed, all the clusters that belong to the composite application are brought up by Stratos, based on the dependency information provided in the cartridge group definition and in the application definition.