104 requires gradual optimization of resource utilization, factoring in utilization trends over a specific timeframe before determining any scaling actions. By basing decisions on smoothed utilization patterns over time, one can achieve consistent cluster performance. To achieve this smoothing effect, a range of industry-standard algorithms are available. Selecting the most suitable algorithm for a customer's cluster workload involves a process of experimentation, which is facilitated by the framework of the SDDC analysis system. Among the commonly employed algorithms (industry standard) are moving averages, exponential moving averages, Holt Linear, etc. Each algorithm exerts a distinct influence on streaming data. The SDDC analysis system empowers users to choose from these techniques, allowing them to identify the one that best aligns with their workload requirements. Thus, the SDDC analysis system provides a framework that fosters experimentation and the selection of the most suitable algorithm as a pivotal facet of the scaling decision-making process.

As described below, the SDDC analysis system 104 processes historical resource usage data with modified parameters and provides a graphical visualization of the resource elasticity profile of an SDDC cluster, such as the cluster 110 in the SDDC 102. In each iteration, users are able to see how the resource elasticity profile of the cluster changes, and save the constructs that balance the cost and performance characteristics of the cluster. In an embodiment, a single click may transfer the profile from the analytic environment to the cluster.

Although the custom policy on the resource scheduler 134 allows users to manage the autoscaling behavior of their clusters, knowing the right set of values to tune, and analyzing the impact on production workloads, overall billing and cluster performance are challenging. The idea behind the SDDC analysis system 104 is to provide users the flexibility to play around with historical cluster data, introduce variation in their raw utilization data coupled with different combinations of resource thresholds. The utilization curve can also be smoothened. The weights assigned to historical utilization values and the current utilization value can also be customized and tuned to strike a good balance. Using the SDDC analysis system 104, users can iteratively tune parameters and analyze the resulting cost implications and performance until a fine balance is achieved.

Turning now to FIG. 2, components of the SDDC analysis system 104 in accordance with an embodiment of the invention are illustrated. As shown in FIG. 2, the SDDC analysis system 104 includes a data collector 202, a smoothing module 204, an autoscaler 206, an analytics engine 208 and a user interface 210. The SDDC analysis system 104 may reside in any computing environment, such as a private or public cloud. In an embodiment, the SDDC analysis system 104 may be implemented as a service that is running on a public cloud.

The data collector 202 of the SDDC analysis system 104 operates to periodically collect raw resource utilization metrics from the host cluster 110 in the SDDC 102. The resource utilization metrics that are collected will be compute (CPU), memory and storage utilization metrics from the hosts 112 of the cluster 110. These resource utilization metrics may be retrieved from the cluster management center 138 and/or from the hosts 112 of the cluster 110. In an embodiment, the resource utilization metrics may be collected at predefined regular intervals from the SDDC 102, for example, every few minutes or every few hours.

The smoothing module 204 of the SDDC analysis system 104 operates to smooth out spikes and randomness in the resource usage represented by the collected resource utilization metrics using various techniques. As an example, the smoothing techniques that may be used by the smoothing module 204 include an exponential method, a moving average method, a double exponential method and a spline curve fitting. One or more of these smoothing techniques may be used to cancel out the unwanted variations in the collected resource utilization metrics. In some scenarios, the resulting data may reveal interesting trends and patterns in the collected data.

The smoothing module 204 may use preset weights or custom weights to perform the smoothing operation. The option to use preset or custom weights and/or the option to use a particular type of smoothing technique may be user selectable.

The autoscaler 206 of the SDDC analysis system 104 operates to automatically determine virtual scaling operations based on the collected resource utilization data using various scale-in and scale-out resource thresholds. That is, the autoscaler determines either a scale-in operation, i.e., a removal of a host from the SDDC cluster under analysis, or a scale-out operation, i.e., an addition of a host to the SDDC cluster under analysis, based on the resource utilization in the SDDC cluster in view of the resource thresholds, which are user adjustable. These resource thresholds include thresholds for scale-in and scale-out determinations for each of the resources being considered. In an embodiment, the autoscaler 206 uses the same algorithm as the resource scheduler 134 to execute autoscaling operations in the SDDC 102.

The analytics engine 208 of the SDDC analysis system 104 operates to perform cost analysis, incident hour computation, and slack capacity calculation for a selected period of time for the SDDC cluster being analyzed using the autoscaling results of the autoscaler 206. Cost analysis is a calculation of the cost of the SDDC cluster for the selected period of time, which will vary depending on the number of hosts being used in the SDDC at different times and the cost of each host per unit of time. For example, the cost analysis may use the cost of host per hour, e.g., $8.36 for each host per hour. Thus, the cost computation will vary depending on the dynamic use of hosts in the SDDC cluster during a select period of time, which will depend on the results of the scale-in and scale-out operations made during the period.

Thus, based on the clastic policy set, the historical cluster configuration and resource utilization data, the cost incurred to the customer for a select period of time can be calculated. On each iteration of input parameter tuning (i.e., changing the operational parameters of the data collector 202, the smoothing module 204 and/or the autoscaler 206), the resulting cost implications may be calculated and presented to the user in terms of savings or additional expense. In an embodiment, the total cost incurred for a period of time is calculated using the following equation:

$Cost = \sum_{j = 1}^{M} (N_{j} \times δ \times m)$

where j is over every δ-minute interval, M is the total number of δ-minute intervals in the period of time being considered, N_jis the number of hosts in cluster at jth interval and m is the cost per minute per host. As an example, δ may be 5 so that 5-minute intervals are being considered.

Incident hours define the duration for which a workload will operate under resource constrained or degraded conditions. In a computing environment, workload resource demands are dynamically changing. Elasticity responds to varying demands and scales the resource. However, there are scenarios where the response time of elasticity can be suboptimal, leading to temporary degradation in workload performance. This delay can occur because elasticity either responds slowly, responds too quickly, or reacts too late to the changing demands. Since customers have the flexibility to set different elasticity thresholds for CPU, memory and storage, it becomes crucial for them to understand the potential impact on their workloads due to the suboptimal response time of elasticity.

Thus, armed with the information regarding the incident hours, customers can make informed decisions when setting elasticity thresholds, aiming to minimize the total incident hours (i.e., the time duration where the cluster struggles to meet workload demands). Incident hours may be calculated by adding a predefined time, e.g., 1/12th of an hour or 5 minutes, when any of the resource utilization percentages breaches a desirable performance threshold, which may be set by a customer or user. For example, if the desirable performance threshold is set at 80% for memory but memory utilization percentage is at 85%, the total duration during which the desirable performance threshold is breached adds up to incident hours. In an embodiment, the incident hours for a SDDC cluster may be calculated using the following algorithm.

Algorithm 1: Algorithm to compute incident hours

Input : DataPoints ← List(tuple[memUtilPct, cpuUtilPct,

storageUtilPct]),

desirablePerformanceThreshold

1.
// Initialization

2.
IncidentHours=0

3.
/* Incident hours go up by 1/12th of an hour on breaching

desirablePerformanceThreshold. */

4.
for each entry in Datapoints do

5.
if memUtilPct >= desirablePerformanceThreshold || cpuUtilPct >=

desirablePerformanceThreshold || storageUtilPct >=

desirablePerformanceThreshold then

6.
IncidentHours = IncidentHours + (5/60)

7.
else

8.
end for

9.
return IncidentHours

Slack capacity is a measure of unutilized resource capacity in a cluster during a given period of time. Higher slack capacity denotes a possibility of over provisioning of resources and a lower slack capacity signifies a likelihood of resource crunch (i.e., running out of resources). Slack capacity may be calculated by subtracting the maximum utilization percentage for any of the resources being analyzed from 100 percent for each data point and then averaging these resulting values for all the data points. In an embodiment, on each iteration of input parameter tuning, the slack capacity for a SDDC cluster may be calculated using the following algorithm.

Algorithm 2: Algorithm to compute Slack Capacity

10. Input : DataPoints ← List(tuple[memUtilPct,

cpuUtilPct, storageUtilPct])

11. Init : SumUnutilizedCapacty ← 0

12. for entry in DataPoints do

13. i ← entry[0]

14. j ← entry[0]

15. k ← entry[0]

16. minimumUnutilizedCapacity ← 100 − max(i, j, k)

17. SumUtilizedCapacity + = minimumUnutilizedCapacity

18. end for

19. SlackCapacity = SumUtilizedCapacity / len(DataPoints)

The UI 210 of the SDDC analysis system 104 allows users to enter parameters to adjust the operations performed by the data collector 202, the smoothing module 204, the autoscaler 206 and the analytics engine 208. As an example, for the data collector 202, the frequency of the data collection and the time window for analysis can be adjusted using the UI 210 so that the collected utilization data for all resources for the selected time window is used for the analysis. For the smoothing module 204, the weights that are used for smoothing and/or the smoothing method used may be adjusted using the UI 210. For the autoscaler 206, the threshold settings for CPU, memory and/or storage (i.e., the scale-in and scale-out resource thresholds) may be adjusted using the UI 210. For the analytics engine 208, the duration of the analysis and the resources being used for the analysis may be adjusted using the UI 210. In addition, the option to compute the cost, the incident hours and/or the slack capacity by the analytics engine 208 may be adjusted using the UI 210.

The UI 210 also presents results of the analysis performed by analytics engine 208 to be consumed by users. The analysis results may include the cost analysis, the computed incident hours, and the slack capacity for each iteration. The analysis results may also include a graph showing the resource capacity over a period of time and the scale-in and scale-out events during the time period. An example of analysis results 300 for a particular iteration in accordance with an embodiment of the invention is illustrated in FIG. 3.

As shown in FIG. 3, the analysis results 300 show the resource capacity over a period of time. The analysis results also show three scale-in operations and two scale-out operations that were executed during this period. The analysis results also show the cost analysis savings of $3,000 and a slack capacity of 20%.

Using the analysis results, such as the analysis results 300 depicted in FIG. 3, for different configurations with respect to parameters for autoscaling operations, a user can select the optimal configuration based on cost analysis, the computed incident hours, and/or slack capacity. Thus, the SDDC analysis system 104 can be used to select the optimal resource scaling policy parameters for an SDDC cluster to reduce cost, while maintaining comfortable slack capacity.

In an embodiment, the SDDC analysis system 104 allows a user to transfer parameters used in the analysis to the SDDC cluster being analyzed using the UI 210, which may provide a button for a single click transfer of the parameters. Thus, the SDDC analysis system 104 provides a simple mechanism to change the parameters of the resource scheduler 134 to implement the input parameters used in one of the analyses that offers the desired cost, the incident hours, and/or slack capacity. Further, the SDDC analysis system 104 can be modeled and made more intuitive with artificial intelligence (AI) or machine learning (ML) solutions, allowing users to reap the benefits of higher cost savings.

The benefits of the SDDC analysis system 104 are further described using an example of an SDDC running in VMware Cloud™ on AWS. In this example, only a single cluster of hosts will be considered. However, the SDDC analysis system 104 may be used for SDDCs with multiple clusters of hosts. Resource utilization metrics used for this example include capacity, demand and exponentially weighted moving average (EWMA) values that are collected every five minutes over a period of thirty (30) days, which amounts to around 8600 data points. Only the raw utilization data is considered for this example without any variations except for resource thresholds for scale-out and scale-in operations across iterations.

In this example, a memory intensive workload is considered on the cluster where scale-out occurs due to high memory utilization and scale-in occurs when memory, CPU and storage utilization on the cluster are all below specific thresholds set based on the resource autoscaling policy. The analysis starts with five (5) hosts in the cluster and the corresponding resource capacities for AWS EC2 i3en.metal instance type. The scaling operations are observed based on policy thresholds and data over various 5-minute intervals. A scale-out event is accounted for when the memory utilization breaches 80% of the total memory capacity available. The resource capacities are then readjusted, the host count in the cluster is incremented, and the cost incurred to the customer is computed. Similarly, a scale-in event is accounted for when CPU, memory and storage utilizations are within 60%, 60% and 20% of their respective capacities. The resource capacities are then readjusted, the host count in the cluster is decreased, and the cost saved for the customer is computed.

For this example, a base iteration is initially performed by the analytics engine 208 with memory scale-out threshold set to 80%, memory scale-in threshold set to 60%, CPU scale-in threshold set to 60% and storage scale-in threshold set to 20%. Then, a first iteration is performed by the analytics engine 208 with memory scale-out threshold set to 80%, memory scale-in threshold set to 30%, CPU scale-in threshold set to 30% and storage scale-in threshold set to 20%. A second iteration is performed by the analytics engine 208 with memory scale-out threshold set to 95%, memory scale-in threshold set to 65%, CPU scale-in threshold set to 65% and storage scale-in threshold set to 20%. The results of these iterations are shown in the following table.

Memory
Memory
CPU
Storage

scale-out
scale-in
scale-in
scale-in
No of
No of

Change

Iteration
threshold
threshold
threshold
threshold
scale-
scale-
Cost
in Cost
Slack

(“Iter”)
(%)
(%)
(%)
(%)
outs
ins
($)
($)
Capacity

Base
80
60
60
20
49
47
44,526
N/A
50.27%

Iter.

Iter. 1
80
30
30
20
17
12
55,017
+10491
59.87%

Iter. 2
95
65
65
20
32
30
42,031
−2495
47.28%

For the base iteration, there were 49 scale-outs (assuming that the CPU and storage utilization on the cluster are well within their scale-out thresholds) and 47 scale-ins. At a rate of $8.36 per hour as the on-demand rate per host, the cost for the customer is calculated to be around $44526 over a period of 30 days and the slack capacity is calculated to be 50.27%. A small section of the observed data for the base iteration is illustrated in FIG. 4A, which shows the memory demand, the memory capacity, the scale-out operations and the scale-in operations.

For the iteration 1, there were 17 scale-outs and 12 scale-ins for the observation period. Since the number of scale-in operations is on the lower end, there is a higher number of hosts left behind in the cluster at the end of the observation period. Thus, the cost for the customer has increased by $10,491. The slack capacity has also increased to 59.87%. A small section of the observed data for the iteration 1, which corresponds to the section shown in FIG. 4A for the base iteration, is illustrated in FIG. 4B, which shows the memory demand, the memory capacity, the scale-out operations and the scale-in operations.

For the iteration 2, the number of scale-out and scale-in operations have dropped to 32 and 30, respectively, from the previously seen values of 49 and 47 for the base iteration. Thus, there is a cost savings of $2495 and a significant drop in slack capacity to 47.28%.

By iteratively adjusting the memory scale-out, memory scale-in, CPU scale-out, CPU scale-in, storage scale-out and/or storage scale-in thresholds and running the analytics engine 208, the customer can select the optimal setting for an SDDC with respect to cost and slack capacity.

Another example illustrating the benefits of the SDDC analysis system 104 is now described. In this example, a rapid scale-up policy (i.e., multiple hosts for scale-outs) is enabled on the SDDC. Resource utilization metrics used for this example include capacity, demand and exponentially weighted moving average (EWMA) values that are collected every five minutes over a period of one (1) day. In different iterations, scale-up increments and resource thresholds have been modified. This policy is suitable for virtual desktop infrastructure (VDI) workloads where hosts are added in bulk expecting a huge demand at a point of time, and similarly scaling down the cluster one at a time when the demand goes down. On any resource breach, a scale-out operation is performed to add a number of hosts in parallel equivalent to the scale-up increment set in the policy. However, the scale-in operation is performed one at a time based on the recommendation from the platform. This example considers the time taken to add a host as around twenty (20) minutes, and the results reflect an increase in capacities when the hosts are successfully added. Similarly, a decrease in capacity is noticed on each subsequent scale-in performed. Based on the thresholds in each iteration, add host or remove host operations are performed adhering to the cool off periods between successive events to not act on spikes or randomness in utilization. The results of these iterations are shown in the following tables. The first table shows the different thresholds and the number of scale-up increments. The second table shows the cost, cost savings, savings percentage and incident hours for the different iterations.

Memory
Memory
CPU
CPU
Storage
Storage

scale-out
scale-in
scale-out
scale-in
scale-out
scale-in
No of

Iteration
threshold
threshold
threshold
threshold
threshold
threshold
Scale-

(“Iter”)
(%)
(%)
(%)
(%)
(%)
(%)
outs

Base
80
50
80
50
80
40
3

Iter.

Iter. 1
60
45
60
45
80
40
3

Iter. 2
80
50
80
50
80
40
2

Iter. 3
60
45
60
45
80
40
4

Iter. 4
80
50
80
50
80
40
4

Iter. 5
60
45
60
45
80
40
2

Cost
Savings in

Iteration
Cost
Savings
Percentage
Incident

(“Iter”)
($)
($)
(%)
Hours

Base
1106
N/A
N/A
0.583

Iter.

Iter. 1
1195
−89
−8.05
0

Iter. 2
850
256
23.15
22.5

Iter. 3
1327
−221
−19.18
0

Iter. 4
1021
85
7.69
0.083

Iter. 5
1018
88
7.96
1.416

As shown in the above tables, the results of iteration 2 shows cost savings of 23.15% as two hosts are added during a scale-out operation compared to the base iteration where the scale-up increment is three hosts. However, the incident hours are as high as 22.5 hours of possible downtime in the performance, which is not a desirable outcome. In iteration 1, with 60% as the scale-out threshold and 45% as the scale-in threshold for memory and CPU, and three (3) hosts as the scale-up increment, a spike is seen in the cost by nearly 8% with the least downtime, whereas the scale-up increment being two (2) in similar configurations (i.e., iteration 5) shows cost savings of 7% with 1.4 hours of possible downtime. These iterations provide customer with insightful data to make decisions and weigh the trade-offs best suiting workload demands.

A process of analyzing an SDDC cluster, e.g., the host cluster