When I discussed the VantageCloud Lake architecture post, I said that “the Compute Clusters represent a decentralized unit of autoscaling”. Then I explained the Compute Groups and Profiles and how they defined which workloads to execute, the initial number of Compute Cluster and the upper limit to autoscale.

Incidentally, you have a summary of the critical VantageCloud Lake elements and the basis for using them in the post VantageCloud Lake in a Nutshell (it includes an infographic).

In this post, I will elaborate on how the autoscale mechanism works and what triggers it.

How the Compute Clusters Autoscale

Once you define one or more Compute Profiles, the Compute Group autoscales automatically.

So, when the amount of user work within a Compute Cluster increases, Lake automatically detects when the active Compute Cluster contention threshold is reached. This threshold is based on the CPU utilization of the active clusters.

Thus, when a Compute Cluster is very busy, Lake starts a second cluster instance.

However, a Compute Group doesn’t grow indefinitely; a policy limits the degree of scaling.

Conversely, when Lake detects consistently lower levels of work within the Compute Cluster, it automatically triggers a hibernation process for one of the cluster instances.

Furthermore, Lake routes all new queries to the remaining active cluster instances.

It is essential to realize that Lake doesn’t restart when scaling in or out, so there is no interruption to active work.

Autoscale Triggers

The methods to trigger the addition or subtraction of clusters within Compute Groups are:

• Global Throttles: By design, the maximum number of queries that can start executing in a cluster is 20 for each active cluster in the Compute Group. If you run 20 queries on a cluster and execute another one, Lake places the latest query in a delay queue. Once one of the active queries is complete, Lake will run the query in the delay queue. However, placing a query in the delay queue triggers the autoscale process if the Compute Group has not reached the maximum number of compute clusters. So, the new query may run in the fresh cluster.
• CPU Utilization: If the average CPU usage for the active clusters within the Compute Groups reaches 90%, Lake will trigger the autoscale process. This trigger is independent of the Global Throttle.
• Memory Utilization: If the memory usage in the active clusters within the Compute Groups reaches 100%, Lake autoscales the Compute Group. As with the CPU trigger, the memory one is independent of the Global Throttle.
• External Orchestration: If your business requires a larger capacity at a specific time, an administrator or an application can trigger the Compute Cluster deployment or hibernation using APIs.

Final Considerations

Check the Teradata online documentation to learn how to administer Compute Groups, as well as the posts Compute Clusters in VantageCloud Lake and Impact of Scaling in VantageCloud Lake.

Note that even though there is a scaling policy by default, the DBAs can override it using SQL.

I updated this post with the link to the post VantageCloud Lake in a Nutshell on 10 December 2023.

On 29 July 2024, I added the link to the post Compute Clusters in VantageCloud Lake.

I modified this post on 30 July 2024 to include a link to the post Impact of Scaling in VantageCloud Lake.