Cloud database server policies for AWS RDS and Azure SQL Managed Instances

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 Default setting/mode
Database Server Scaling Actions On
Disruptive irreversible scaling Manual
Disruptive reversible scaling Manual
Non-disruptive irreversible scaling Manual
Non-disruptive reversible scaling 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 vCPU, vMem, DB Cache Hit Rate, and IOPS. 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 Server.

    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 Database Servers 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 Database Servers 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. To ensure that there are enough samples to analyze and drive scaling actions, set the Min Observation Period.

  • 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 Server 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 Database Server scaling is minimally disruptive, scaling often should not introduce any noticeable performance risks.

  • 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 – 1, 3, or 7 Days

Cloud instance types

By default, Turbonomic considers all instance types currently available for scaling when making scaling decisions for Database Servers. However, you may have set up your Database Servers to only scale to certain instance types to reduce complexity and cost, or meet demand. Use this setting to identify those instance types.

Note:

Turbonomic automatically discovers and enforces Database Server tier exclusions configured in your AWS environment. You do not need to configure these tier exclusions in policies. To see a list of tier exclusions that are currently enforced, set the scope to one or several Database Servers and click the Policies tab.

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 Database Servers 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 Database Servers 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.

Note:

This policy setting is not available in plans.

Scaling target utilization

This is the target utilization as a percentage of capacity.

Attribute Default value
VCPU 70
VMEM 90
IOPS 70
Storage Amount 90

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.