|
|
United States-English | |
|
|
 |
|
HP Capacity Advisor Version 4.0 User's Guide > Chapter 3 Key Capacity Advisor Concepts
Measuring and Analyzing Resource Utilization |
|
|
In using Capacity Advisor, it is helpful to understand how the tool approaches sampling and data analysis, and the user-provided information that affects these. Measuring utilization of computing resources is more complex than simply determining the maximum memory or processor utilization. Sum of Peaks. An old standby in capacity planning is to simply take the peak of the two loads and use that to determine the maximum required capacity; this is the “sum of peaks”. While this will definitely provide a robust solution, it does not take into account the timing of the peak of the loads and may end up planning for more capacity than is actually used. Peak of Sums. A more efficient planning solution, which is easily accomplished using HP Capacity Advisor, takes into account the timing of the maximum utilization peaks in the individual loads. By adding together utilization at each measured interval and then taking the maximum of the resulting time sequence, a more accurate measure of the required maximum resource can be determined. This can lead to cost savings when planning the resources required to consolidate loads onto new or existing servers. HP Capacity Advisor utilization providers run on each monitored system to collect information on resource utilization. At the CPU-clock cycle level, a processor is either busy or idle. For Capacity Advisor, the average utilization for each 5–minute interval is stored. Therefore, peaks lasting less than 5 minutes are not visible. Because each data point is the average of the five preceding minutes of values, this averaging tends to flatten the graphs, particularly when compared with real-time graphs in which each data point is the average of values from the 15 preceding seconds. Headroom is the difference between the average utilization on a system and the maximum available capacity. Optimum headroom varies depending on size of system. While a single processor system might require 50% headroom to preserve reasonable response times, a 16-way system might have reasonable response times when loaded at 80%. Adequate headroom can also depend heavily on the characteristics of the loads; highly interactive systems require much more headroom than those that can tolerate delays in response time; batch systems may get by with very little headroom at all. Various reports and results show headroom star rankings. The headroom of a system is the amount of additional capacity that can be used without violating the utilization limits of the applications running on that system. For example, if you have a system with 4 cores where you never want utilization to exceed 75%, and peak utilization is 1.75 cores, then headroom is 1.25 cores. The highlighted number of stars representing headroom can be interpreted as follows: Table 3-1 Stars Defined
Headroom star ratings for a host are a weighted average of all of the star ratings of the workloads on that host. The weighting tends to give the highest weight to the lowest ratings. One low rating can dramatically lower the rating for the entire host. In the case of a VM host, the star ratings account for how well the workloads fit into their virtual machines, as well as how well the virtual machines fit on the VM host. The rating for the VM host will be low if any of the virtual machines are too small for their workloads. When using the Smart Solver to find a plan to convert physical systems to virtual machines, consider the following factors that can adversely affect the Smart Solver results.
You can avoid having the Smart Solver produce
inaccurate or useless results by resizing your systems before running
the Smart Solver. If either of the above conditions exist in your
situation, consider increasing the number of cores on your simulated
physical systems before running the Smart Solver. (Select What-if Actions Resizing the virtual machines after running the Smart Solver can be less effort, as you only have to resize the VMs that have fewer stars than your desired goal. After adding more cores to the VMs for which CPU resources are too tight, you can rerun Smart Solver to balance the load on the VM hosts to improve the solution a bit more.
Data collected by Capacity Advisor is used in the scenarios you create and manipulate. During an interval when no data was collected, the data is considered missing (data may not have been collected, for example, because a system was down during data collection). Invalidated (or invalid) data is data that you have marked as invalid. For each metric about a system or workload, if a significant amount of data is missing or invalid, the metric is followed by asterisks with the following meaning:
Thus, metrics without asterisks are considered useful and reliable for analysis. Utilization limits allow you to set specific service level objectives for workloads. Beyond overall system utilization, these utilization limits place service level objectives on one or more specific utilization metrics (CPU, memory, network, or disk utilization) for any given workload. When making automated changes, such as the automated system consolidation done by the HP Smart Solver, these utilization limits are honored in determining a solution for automated load balance of servers and virtual machines and for automated workload stacking. The default utilization limits used globally across Capacity Advisor in the absence of user-defined limits are the following:
(For information on how utilization is calculated for each resource, seeAppendix B .) There are three building blocks to specifying a utilization limit:
For more information about time limits, see “Sustained Time Limits” and “Percentage of Time Limits” A sustained limit specifies a limit where the resource cannot exceed that utilization limit for X consecutive minutes. For example, if X is 20, this means that the resource cannot exceed the utilization limit for 20 consecutive minutes. Because the Capacity Advisor collects data samples every 5 minutes, the time X for the sustained limit must be a multiple of 5 minutes; the minimum for X is 0 minutes. A percentage of time limit specifies that the resource cannot exceed the limit for more than the designated percent of time, where percent of time is related to the percentile utilization ranges in the Capacity Advisor data. Given that there are about 10,000 minutes in a week, 3% of the time is roughly 300 minutes (3% of 10,000). These 300 minutes total to 5 hours per week. Below is a table relating percentages of time to hours per week, which may help you in specifying percent of time utilization limits. Table 3-2 Percent of Time Conversions
The utilization limit messages are shown as a percentage of allocation, where allocation is subset of the given hardware for the system the workload is running on. For example, for a 1–core system, the allocation is 1 CPU. The CPU utilization limit of 50% would mean 50% of 1 core, or .5 cores. However, this percentage changes when the hardware (allocation) changes. If 2 additional cores are added (say through dynamic CPU migration with vPars), the CPU utilization limit of 50% would mean 50% of 3 cores, or 1.5 cores. The allocation values for network and disk may be updated each time utilization data is collected from the system using the capcollect command. (See the “Command Reference” in this guide.) If a new high observed value occurs during the time period collected, the network or disk allocation value for the system is increased to reflect it. This increased value then affects any network or disk utilization limits for workloads on that system. The current allocation values for a system are displayed on the Profile Viewer page under Platform Characteristics. A sustained utilization limit can be set such that CPU utilization cannot exceed 50% of allocation for 20 consecutive minutes, where the allocation of hardware is based upon a 3–core system. The utilization limit message would read: CPU utilization may not exceed 50% of allocation or 1.5 cores for more than 20 minutes. A percentage of time utilization limit could be set such that CPU utilization cannot exceed 90% of allocation for more 10% of the time, where the allocation is based upon a 3–core system. The utilization limit message would read: CPU utilization may not exceed 50% of allocation or 1.5 cores for more than 10% of the time. Utilization limits can be set to apply broadly or narrowly within the Capacity Advisor user interface:
When a workload falls within more than one scope, only the more specific one applies, as shown in the table below. You can disable a more specific scope where you do not want a specific scope to apply. Table 3-3 Scope of Utilization Limits
Capacity Advisor gives you the ability to provide a compensating factor, a scaling multiplier, to help Capacity Advisor to adjust needed resources when analyzing moving from one platform to another. The following table lists the scaling factors that you can use to more accurately simulate potential change. (For information on how utilization is calculated for each resource, seeAppendix B .) Table 3-4 Definitions of Scaling Multipliers Used in Capacity Advisor
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
Edit System... on the System tab on the Edit Scenario screen.) If you change the number of cores
from 1 to 2 or 2 to 3 before consolidating, the resulting virtual
machines will have enough cores to cover the virtualization overhead
or a slower VM host. 
