Cloud database policies
Turbonomic ships with default automation policies that are believed to give you the best results based on our analysis. For certain entities in your environment, you can create automation policies as a way to override the defaults.
Automation workflow
Action |
Applies To |
Default Setting |
---|---|---|
Cloud DB scale |
Azure SQL vCore and DTU |
Manual |
Database suspend actions |
Azure dedicated SQL pool |
On, Manual |
Database reconfigure actions |
Azure Cosmos DB |
On, Recommend |
Database delete actions |
Azure Cosmos DB |
On, Manual |
You can use Action Scripts and third-party orchestrators (such as ServiceNow) for action orchestration.
Scaling sensitivity
Turbonomic uses a percentile of utilization over the specified observation period. This gives sustained utilization and ignores short-lived bursts.
Turbonomic uses these settings to calculate utilization percentiles for DTU, RU, and storage. It then recommends actions to improve utilization based on the observed values for a given time period.
-
Aggressiveness
Attribute
Default Value
Aggressiveness
95th Percentile
When evaluating performance, Turbonomic considers resource utilization as a percentage of capacity. The utilization drives actions to scale the available capacity either up or down. To measure utilization, the analysis considers a given utilization percentile. For example, assume a 95th percentile. The percentile utilization is the highest value that 95% of the observed samples fall below. Compare that to average utilization, which is the average of all the observed samples.
Using a percentile, Turbonomic can recommend more relevant actions. This is important in the cloud, so that analysis can better exploit the elasticity of the cloud. For scheduled policies, the more relevant actions will tend to remain viable when their execution is put off to a later time.
For example, consider decisions to reduce capacity. Without using a percentile, Turbonomic never resizes below the recognized peak utilization. Assume utilization peaked at 100% just once. Without the benefit of a percentile, Turbonomic will not reduce resources for that database.
With Aggressiveness, instead of using the single highest utilization value, Turbonomic uses the percentile you set. For the previous example, assume a single burst to 100%, but for 95% of the samples, utilization never exceeded 50%. If you set Aggressiveness to 95th Percentile, then Turbonomic can see this as an opportunity to reduce resource allocation.
In summary, a percentile evaluates the sustained resource utilization, and ignores bursts that occurred for a small portion of the samples. You can think of this as aggressiveness of resizing, as follows:
-
99th Percentile – More performance. Recommended for critical databases that need maximum guaranteed performance at all times, or those that need to tolerate sudden and previously unseen spikes in utilization, even though sustained utilization is low.
-
95th Percentile (Default) – The recommended setting to achieve maximum performance and savings. This assures performance while avoiding reactive peak sizing due to transient spikes, thus allowing you to take advantage of the elastic ability of the cloud.
-
90th Percentile – More efficiency. Recommended for databases that can stand higher resource utilization.
By default, Turbonomic uses samples from the last 14 days. Use the Max Observation Period setting to adjust the number of days.
-
-
Max Observation Period
Attribute
Default Value
Max Observation Period
Last 14 Days
To refine the calculation of resource utilization percentiles, you can set the sample time to consider. Turbonomic uses historical data from up to the number of days that you specify as a sample period. If the database has fewer days' data then it uses all of the stored historical data.
You can make the following settings:
-
Less Elastic – Last 30 Days
-
Recommended – Last 14 Days
-
More Elastic – Last 7 Days or Last 3 Days
Turbonomic recommends an observation period of 14 days so it can recommend scaling actions more often. Since Azure SQL DB scaling is minimally disruptive, with near-zero downtime, scaling often should not introduce any noticeable performance risks.
Note:For more information about Azure scaling downtimes, see the Azure documentation.
-
-
Min Observation Period
Attribute
Default Value
Min Observation Period
None
This setting ensures historical data for a minimum number of days before Turbonomic will generate an action based on the percentile set in Aggressiveness. This ensures a minimum set of data points before it generates the action.
Especially for scheduled actions, it is important that resize calculations use enough historical data to generate actions that will remain viable even during a scheduled maintenance window. A maintenance window is usually set for "down" time, when utilization is low. If analysis uses enough historical data for an action, then the action is more likely to remain viable during the maintenance window.
-
More Elastic – None
-
Less Elastic – 7 Days
-
Cloud instance types
By default, Turbonomic considers all instance types currently available for scaling when making scaling decisions for SQL databases. However, you may have set up your SQL databases to only scale to certain instance types to reduce complexity and cost, or meet demand. Use this setting to identify those instance types.
Attribute |
Default Value |
---|---|
Cloud Instance Types |
None |
Click Edit to set your preferences. In the new page that displays, choose from the following options:
-
Excluded
By default, this option is selected and all instance types are deselected. This means that all instance types are considered for scaling.
Any instance types that you select are excluded from scaling.
Configure an exclusion list if there are fewer instance types to exclude than to include. For example, if 400 instance types are currently available for scaling and you do not want SQL Databases to scale to 20 instance types, configure an exclusion list and select the 20 instance types.
-
Included
Any instance types that you select are considered for scaling.
Configure an inclusion list if there are fewer instance types to include than to exclude. For example, if 400 instance types are currently available for scaling and you want SQL Databases to scale only to 50 instance types, configure an inclusion list and select the 50 instance types.
Expand an instance family to see individual instance types and the resources allocated to them.
After you save your changes, the main page refreshes to reflect your selections.
This policy setting is not available in plans.
Scaling target utilization
The utilization that you set here specifies the percentage of the existing capacity that Turbonomic will consider to be 100% of capacity.
The settings you make depend on the pricing model in place for the workloads in the policy scope.
-
vCore Pricing Model
To meet individual VCPU, VMEM, or IOPS/Throughput targets, the workloads must be charged according to the vCore pricing model.
Attribute
Default Value
VCPU
70
VMEM
90
IOPS/Throughput
70
Storage Amount Utilization
90
-
DTU Pricing Model
To meet a target DTU utilization, the workloads must be charged according to the DTU pricing model.
Attribute
Default Value
DTU Utilization
70
Storage Amount Utilization
90
-
RU Pricing Model
To meet a target RU utilization or individual RU targets, the workloads must be charged according to the RU pricing model.
Attribute
Default Value
RU Utilization
70
These advanced settings determine how much you would like a scope of workloads to utilize their resources. These are fixed settings that override the way Turbonomic calculates the optimal utilization of resources. You should only change these settings after consulting with Technical Support.
While these settings offer a way to modify how Turbonomic recommends actions, in most cases you should never need to use them. If you want to control how Turbonomic recommends actions to resize workloads, you can set the aggressiveness per the percentile of utilization, and set the length of the sample period for more or less elasticity on the cloud.
Minimum RU capacity for scale down actions
This setting applies only to Cosmos DB databases. Turbonomic checks this scaling constraint when it recommends scale down actions to ensure that Cosmos DB databases never scale below the specified value.
Attribute |
Default Value |
---|---|
Minimum RU capacity for scale down actions |
400 |
Be sure to specify a value that is an increment of 100. By design, Azure increases or decreases the number of RUs at any time in increments or decrements of 100 RUs.
In addition to this scaling constraint, Turbonomic also checks the minimum RU limit that Azure calculated. This limit takes precedence over the value specified in the policy. For example, if the minimum RU limit calculated by Azure is 500 while the minimum RU capacity in the database policy is 400, Turbonomic will never recommend scaling below 500 RUs.