Hey all,

Hope you are safe and healthy during pandemic.

Continuing the post series that we started some days ago, this is the second post about AutoScaling. Today we will discuss about AutoScaling on OCI.

The first post can be found here: Scaling Challenges in On-Premises Workloads – Post 1

First of all, it’s important to explain that on OCI we have two types of Scaling. Please note that I am not saying about two types of AutoScaling, but, two types of Scaling:

  • Vertical Scaling: when you change the shape for an instance;
  • Horizontal Scaling: when you change the number of instances/nodes of an instance pool.

So, just to be clear, this post series will talk about Horizontal Scaling.

Well, there are two types of AutoScaling configurations on OCI:

  • Metric-Based:
    • Used mainly for unpredictably demand. This is valid when the Workload changes suddenly with no plan for that;
    • Need to choose a performance metric to configure it. It can be CPU or memory. A threshold must be specified for this performance metric;
    • AutoScaling resizes the instance pool in near real-time;
    • If load increases, the pool scales out;
    • If load decreases, the pool scales in;
    • The performance metrics are collected by Monitoring Service;
    • Metrics are aggregated into one-minute periods and averaged across all instances in the instance pool;
    • When three consecutive values (average metrics for three consecutive minutes) meet the threshold, an autoscaling event is triggered;
    • A cooldown period (300 seconds – 5 minutes) lets the system stabilize at the updated level and starts the instance pool reaches the Running state;
    • Autoscaling continues to evaluate metrics during cooldown period. When a cooldown ends, autoscaling adjusts the instance pool size if needed (this means that if metric thresholds are reached for the last 3 minutes of cooldown, when cooldown finishes an autoscaling will be triggered).
  • Schedule-Based:
    • Used mainly for predictably demand (Black Friday, Quarterly Ending, FY Ending, etc);
    • For each scale-out or scale-in operation, an exclusive policy (schedule) must be created to define the pool size. Ex: Every Saturday at 15:00 increases the pool size (scale out). Every Sunday at 02:00 decreases the pool size (scale in);
    • Can have multiple autoscaling policies with a different schedule and target pool size.

Some prereqs for AutoScaling::

  • For metric-based AutoScaling, if an instance is behind a private subnet, the instance must have access to a Service Gateway to reach Monitoring Service endpoint. If an instance is behind a public subnet, no action needed;
  • Limits or Quotas cannot reach the maximum number of instances allowed before autoscaling;
  • Optionally, it’s possible to attach to a Load Balancer.

For a metric-based pool, the following rules will be used to remove instances from pool:

  • The number of instances in pool will be balanced. So, if AD1 have 3 instances, AD2 have 2 instances and AD3 have 1 instance, one instance will be removed from AD1;
  • After the number of instances is balanced across AD’s, the number of instances will be balanced across Fault Domains. So, if some FD have more instances than another FD, the instances will be removed from FD with more instances running;
  • After instances are balanced across AD’s and FD’s, the oldest instance running is terminated first.

Main components for an AutoScaling Configuration:

  • Custom Image: if you have a Custom Image you can use it as a default image for instances in your pool. So, all instances in the pool will use the same Custom Image and you can have a “standardisation” of your pool. To do that, you need to create an instance on OCI, install the softwares that you need, configure the instance as you need and then create the Custom Image;
  • Instance Configuration: after an Instance is provisioned using the Custom Image, you can create an Instance Configuration. An Instance Configuration with a lot of useful information to create new instances: image used, metadata, shape, storage volumes attached, VNICs, etc. An Instance Configuration works as a template to next instances that will be created. An Instance Configuration can be associated with N instance pools;
  • Instance Pool: is used to create multiple instances using the same configuration (Instance Configuration), within same region, across availability domains. With Instance Pool is possible manage instances as a group. You can scale-out (increase the number of instances in pool) or scale-in (decrease the number of instances in pool). It’s possible to associate with one or more Load Balancers. Despite the fact that you can associate 1 Instance Configuration with N Instance Pools, you can only associate 1 Instance Pool with 1 Instance Configuration;
  • AutoScaling Configuration: is used to create an AutoScaling configuration to a specific Instance Pool. You can create a configuration metric-based (as we already explained in this post) or a configuration schedule-based. You can associate 1 AutoScaling Configuration with only 1 Instance Pool. This means that if you create an Instance Pool and want to use a policy metric-based and another policy schedule-based, you need to create 2 Instance Pools and associate each one with a specific AutoScaling Configuration.

So, the suggested Workflow to create AutoScaling Configuration is below:

So, in the next posts we will start Hands-On with the following tasks:

  • Compartment creation;
  • VCN/Subnets creation;
  • Load Balancer creation;
  • Security List updates on Ingress Rules to enable AutoScaling to attach an Instance on Load Balancer;
  • Instance creation;
  • Customization of instance created;
  • Custom Image creation;
  • Termination of Instance created;
  • Criation of an Instance using the Custom Image;
  • Creation of an Instance Configuration;
  • Creation of 2 Instance Pools;
  • Creation of 2 AutoScaling Configurations.

Hope this helps.