Cloud Partitioning

Partitions

A partition depicts the division in an IaaS and defines an area of an IaaS cloud used by a service subscription. A partition can be made at one of the following levels: Provider level, Region level, Zone level or Rack level. A partition should at least have a provider defined. If required, partition groups can be defined in the partition definition. DevOps, for the purpose of high availability, can define multiple partitions in order to instruct Apache Stratos to spawn instances in multiple areas (e.g., region, zone or rack). For example, if you spawn instances in multiple availability zones in EC2, your system will be still functional even if one availability zone is down.

Partition Groups

A partition group is the an area of an IaaS that is bound by one network of an IaaS (e.g., region). Partition groups are also referred to as network partitions. We can include several partitions inside a network partition. Thereby, DevOps can define multiple partition groups, which have multiple partitions under it, for the purpose of high availability.

Partition Algorithms

When scaling takes place among several partitions, the partition algorithm that needs to be used has to be defined. Partition algorithms define the scaling mechanism that needs to be used to spawn instances between partition groups. The partition algorithm that is applied within a partition group, may vary from the partition algorithm that is applied between different partition groups. For example, if there are two partition groups named PG1 and PG2 and if there are two separate partitions named P1 and P2 within PG1. Then the partition algorithm used between P1 and P2 within PG1 may vary from the partition algorithm used between PG1 and PG2. The available partition algorithms are as follows:

One after the other
When using this algorithm, instances will be spawned in the same partition until the maximum number of instances for the respective partition is reached, before spawning instances in the next partition. For example, if there are two partitions named P1 and P2, instances will be spawned in the same partition until the maximum number of instances are reached, before spawning instances in P2.
Round Robin
When using this algorithm, instances will be spawned in each of the partitions sequentially. For example, if there are two partitions named P1 and P2, after an instance is spawned in P1 it will spawn the next instance in P2.

Example Scenarios

In a typical Cloud bursting scenario, we would use one after the other. For example, if an enterprise has its private cloud, all instances would be allocated there, and when we run out of capacity, we would go to the next partition on the public cloud. The round robin case could be a case for very high availability, where instances are spawned across multiple IaaS providers.

Partition Deployment

Auto-scaler makes decisions based on the defined partitions or partition groups. The partitions and partition groups are defined in the


    partitions.json

file in the registry. DevOps need to use the deployment policy to define the design of the partitions and partition groups (network partitions) used in their PaaS. Partitions are defined in WSO2 Private PaaS to manage the instance count. Thereby, when defining the deployment policy the maximum number of instances allowed in a partition per cartridge subscription (partitionMax) and the minimum number of instances allowed in a partition per cartridge subscription (partitionMin) needs to be specified. For information on the workflow, see Partition Deployment Workflow.