Released: December 2017
This release presents updated time series and cluster trend reporting and a more effective way to identify workloads or machines that are on the watchlist within the baseline and forward thinking scenarios.
The report also provides information on how often this cluster event has been raised and at which severity. In the above example, the first cluster event has been raised 22 times in the last 30 days for each level of redundancy threshold crossing.
By selecting ‘Drill through to event history’ you can view the last 30 days history of the event. This chart has a blue indicator marking the expected saturation date when the event was first raised, a red indicator for the most recently calculated saturation date, and then a series of indicators showing each date between. This can be used to gain an understanding of whether or not an event is coming closer and faster or moving further away as a result of a flattening trend.
A chart is also provided showing the time series of allocated vCPUs in the cluster, giving an indication of growth that may also contribute to changes in the cluster saturation dates.
The above shows an example of a cluster event that has been raised a number of times. When first raised, the projected saturation date was 29th October 2018. The most recent saturation date predicted is now 18th September as indicated by the red marker on the chart.
The lower chart shows a time series trend of allocated vCPUs in this cluster. It can be seen that there has been a rise over the course of the last 3 months which is most likely leading to the change in projected saturation date for the cluster.
The time series line chart has been significantly enhanced to provide more flexibility and support the representation of multiple series on a single chart.
There are now a number of configuration options for this report.
|Timeframe||The baseline model to be used to generate the series.|
|Entity type||Selection of the primary entity type to be used to generate the series. This can be either Cluster, Host, Physical, Datastore or VM.|
|Entity name||List of all entities of the selected type (i.e., VMs). Typing in this list allows for a specific entity to be found. The check box allows multiple entities to be selected.|
|Related entity type||Allows for the selection of specific entities that are contained by the primary entity, for example, VMs within a chosen primary entity Cluster.|
|Metric||Select the metric that you want the report generated for.|
|From date||The start date for the series.|
|To date||The end date of the series.|
|From time||Allows the filtering of specific data points (i.e, working day).|
|To time||The end of the hour:min filter.|
|Days of week||Allows the filtering of particular days (i.e. working week).|
|Timeseries||Determine whether to use raw data or aggregated hourly average data.|
Depending on the filter, this series can take some time to generate. Once complete, it can be exported as normal.
The following is an example showing a time series of cpu.ready.summation for all hosts within a single cluster, filtering out weekends and overnight data.
This time series is also available from the VM Storage Summary report that was released in version 90. Please see the Release 90 release note for details on that report specifically. When exploring the utilisation of individual drives, it is now possible to view a time series of that specific drive. The report also contains a VM filter allowing the user to quickly highlight a specific VM.
When you next open the baseline, you may see some VMs with a red circle around them, similar to the following:
These are VMs that currently, as of the latest processing of the model, do not have enough capacity to meet their 95th %ile demand value over the last 3 months. In other words, in the last 3 months, the CPU demand of these VMs has been higher than what the VM is currently capable of supporting.
The most likely cause of this is due to VMs moving around an unbalanced cluster. A VM with 2 VCPUs will always have 2 VCPUs, however, if this VM moves onto a less capable device, then the raw capacity with regards to GHz will fall. If this is a VM that often uses its available CPU capacity then may take longer for that VM to complete activities when running on a less capable device.
This can also be seen within the metrics explorer.
The blue line is the capacity of the VM in GHz. The VM is in a significantly unbalanced cluster meaning that its relative capacity significantly decreased when it was moved on to a less capable device on 29th October. However, prior to that, it can be seen that a number of times, the CPU demand was significantly higher. As a result, the current VM capacity is not sufficient to meet the previous historical high demand values. In forward thinking, any VM that is over-committed on any metric will also be highlighted with a red circle.
Click the links below to view other versions of Capacity Planner release notes.
|Capacity Planner Release Notes 102||Released: October 2019|
|Capacity Planner Release Notes 101||Released: August 2019|
|Capacity Planner Release Notes 100||Released: May 2019|
|Capacity Planner Release Notes 99.2||Released: March 2019|
|Capacity Planner Release Notes 99||Released: December 2018|
|Capacity Planner Release Notes 95||Released: May 2018|
|Capacity Planner Release Notes 94||Released: March 2018|
|Capacity Planner Release Notes 93||Released: January 2018|
|Capacity Planner Release Notes 92||Released: December 2017|
|Capacity Planner Release Notes 91||Released: October 2017|
|Capacity Planner Release Notes 90||Released: September 2017|