|
|
United States-English | |
|
|
 |
|
HP Capacity Advisor Version 4.1 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 Provider runs 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 (300 seconds) 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. For data collected using the agentless solution, collection intervals may vary depending on values that you set and the number of machines in the collection. Headroom is the difference between the observed utilization on a system and the maximum available capacity. That is, 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. 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. Use the following chart to understand the headroom ranking system. Table 3-1 Headroom Stars Defined
Headroom star rankings for a host are a weighted average of all of the star rankings of the workloads on that host. The weighting tends to give the highest weight to the lowest ranking. One low ranking can dramatically lower the ranking for the entire host. In the case of a VM host, the star rankings 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 ranking 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 re-sizing 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 Re-sizing the virtual machines after running the Smart Solver can be less effort, as you only have to re-size 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 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. Utilization limits also apply to the automated load balance of servers and virtual machines, and to automated workload stacking. The default utilization limits used globally across Capacity Advisor in the absence of user-defined limits are the following:
(For more information on how utilization is calculated for each resource, see Appendix 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 could 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 50% 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 compensating factors to help Capacity Advisor adjust needed resources when analyzing moving workloads from one platform to another. (For information on how utilization is calculated for each resource, see Appendix B.) The following are situations that you will want to adjust for when modifying a scenario because they affect resource utilization:
Meaning The ratio of change in CPU utilization due to using a different platform (PA-RISC, Itanium, or Xeon, for example) to host workloads in the scenario than the platform originally assumed. If changes made in a scenario assume using the same platform, use the default multiplier. Default The default value is 1.0 (0% change) Where you might use this multiplier
Simple Examples If you are moving from:
Detailed Example Assume that you benchmark your current application on a test machine that is similar to one that is currently running a production application. Assume that the test machine is a two-way 550 MHz PA-RISC system with a benchmark of 400 CPU seconds to complete, using 400 MB of RAM. Next, assume that you want to run a newer version of the application on a one-way, 1.6 GHz, HP Integrity Virtual Machine. Your new benchmark for this application is 100 CPU seconds to complete, using 600 MB of RAM. Because Capacity Advisor automatically scales CPU times to the clock speed of the CPU cores in the system, you will need to do the same to supply a useful alternative CPU Multiplier to help Capacity Advisor adjust to platform changes in a scenario. To compute the CPU Multiplier, calculate the ratio of the CPU seconds multiplied by the clock speed for the new and the old platform: (100*1600)/(400*550) = 0.73 The multiplier of 0.73 represents a 27% decrease in CPU utilization. Meaning The ratio of change in memory utilization due to using a different platform (PA-RISC, Itanium, or Xeon, for example) to host workloads in the scenario than the platform originally assumed. If changes made in a scenario assume using the same platform, use the default multiplier. Default The default value is 1.0 (0% change) Where you might use this multiplier
Simple Examples If you are moving from:
Detailed Example For this example, refer to the assumptions stated in the “Detailed Example” shown in the CPU Multiplier section. To compute the Memory Multiplier, calculate the ratio of the memory used for the new and the old platform: 600/400 = 1.5 The multiplier of 1.5 represents a 50% increase in memory utilization. This change is affected primarily by the move to Integrity and by getting a new version of the software application. In the case of memory utilization, factors like the number of CPU cores and the use of virtual machines have no effect unless the application tests for these factors and changes its behavior accordingly. The following sections describe the multipliers that you can use when you create new workloads. The multipliers help you to more accurately simulate changes in resource demand that are anticipated for workloads in a new data center configuration. Meaning The relative change in CPU utilization desired when sizing an existing workload to better simulate a new workload in a scenario. CPU utilization by the new workload that you are creating can be made smaller, the same, or larger than that of the workload chosen as the baseline value.
Default The default value is 1.0 (no change). Where you might use this multiplier
Examples To increase the CPU utilization of a new workload by 10% of the chosen baseline workload, enter a multiplier of 1.1. To decrease the CPU utilization of a new workload by 10% of the chosen baseline workload, enter a multiplier of .9. Meaning The relative change in memory utilization when you are sizing a workload to simulate a new workload in a scenario. Memory utilization by the new workload that you are creating can be made smaller, the same, or larger than that of the workload chosen as the baseline value.
Default The default value is 1.0. Where you might use this multiplier
Example To increase the memory utilization of a new workload by 20% of the chosen baseline workload, enter a multiplier of 1.2. Meaning The relative change in network I/O utilization desired when sizing an existing workload to better simulate a new workload in a scenario. Network I/O can be made smaller, the same, or larger than that available for the workload chosen as the baseline value. Default The default value is 1.0 (no change). Where you might use this multiplier
Example To decrease the network I/O available to a new workload by 5% of that available to the chosen baseline workload, enter a multiplier of .95. Meaning The relative change in disk I/O utilization desired when sizing an existing workload to better simulate a new workload in a scenario. Disk I/O can be made smaller, the same, or larger than that available for the workload chosen as the baseline value. Default The default value is 1.0 (no change). Where you might use this multiplier
Example To increase the disk I/O available to a new workload by 10% of that available to the chosen baseline workload, enter a multiplier of 1.1. Use these fields to set parameters for the workload's utilization of resources. When you use an existing workload profile (Copy Profile), you leverage data that already exists for a workload to examine alternatives. When you use a static workload profile (Static Profile), you create a profile based on independent values. Table 3-4 Settings to Guide Estimated Utilization Assumptions for Workload
Capacity Advisor gives you the ability to provide compensating factors to help Capacity Advisor adjust needed resources when analyzing moving workloads from a physical system to a virtual machine on a VM host or from a virtual machine to a physical system. (For information on how utilization is calculated for each resource, see Appendix B.) The following section presents the scaling factor that you can use to more accurately simulate the impact of changing a standalone system to a virtual machine, or a virtual machine into a standalone system. In these situations, CPU utilization can increase or decrease due to the overhead required for the virtual machine software. The CPU Virtualization Overhead % helps you to account for this in a scenario. Meaning The percent change in CPU utilization due to the overhead (or the absence of overhead) incurred by running an application in a virtual machine. Default The default value is 0% (0% change). Where you might use this multiplier
Example: Making a server become a virtual machine If your virtualization software would cause a 15% increase in CPU utilization due to the overhead for virtualization software, enter 15 for the CPU Virtualization Overhead % to account for the additional demand on the CPU core(s) when changing a server to a virtual machine. Example: Making a virtual machine become a server If your virtualization software requires a 15% increase in CPU utilization due to the overhead for virtualization software in the virtual machine, enter -15 for the CPU Virtualization Overhead % to account for the gain in CPU availability when changing a virtual machine to a server.
The following section presents the scaling factor that you can use to more accurately simulate the impact of including a hypervisor in your scenario. With the addition of a hypervisor, memory utilization increases due to the operation of the hypervisor. The Hypervisor Memory Overhead helps you to account for this in a scenario. Meaning The amount of memory used by the virtualization platform to host virtual machines. The size of the memory overhead varies for each virtualization platform. Default Capacity Advisor calculates the value for you. Where you might use this percentage adjustment
When you encounter this adjustment factor in altering a scenario, you have a choice to supply your own values. To help you with this, the following calculation examples are provided. To compute the memory overhead of the hypervisor, use the following formula: 750 MB (.73 GB) + 7.5% of (Total Physical Memory – 1 GB) Example: For a host with 32 GB of physical memory, the Hypervisor Memory Overhead will be: 750 MB (.73 GB) + 7.5% of 31 GB = .73 GB + 2.24 GB = 2.97 GB Source: Hardware Consolidation with Integrity Virtual Machines To compute the memory overhead of the hypervisor, use the following formula: Total Physical Memory – (Total Physical Memory – 284 MB)/1.078 This formula is derived from a least squares fit of observed values in test systems running VMware ESX. VMware documentation provides tables that outline how much memory overhead to expect based on the number of virtual CPUs and the amount of memory allocated to guests. For more information: Resource Management Guide on the VMware web site. Depending on which version of Windows® Server is used as a host, Microsoft recommends between 256 MB and 512 MB of physical memory be available for the operating system and hypervisor. In addition, Microsoft Virtual Server incurs 32 MB of overhead per guest, and supports up to 64 guests. To estimate the hypervisor overhead, use the following formula: 512 MB + (32 MB x Number of Guests Hosted) Example: For a system hosting 4 guests, the estimated Hypervisor Memory Overhead will be: 512 MB + (32 MB x 4 guests) = 640 MB (.63 GB) Source: System Requirements for Virtual Server on Microsoft TechNet web site. Microsoft recommends at least 512 MB (.5 GB) of physical memory be available for basic hypervisor features. In addition, for each guest, plan on 32 MB of overhead for the first GB of RAM allocated to a guest, and 8 MB for each additional GB of RAM allocated to a guest. To compute the memory overhead introduced by the hypervisor, use the following formula: 512 MB + (Number of Guests x (32 MB for first GB of guest RAM + 8 MB per additional GB of guest RAM)) Example: For a system hosting 2 guests with 2 GB of RAM, and 2 guests with 1 GB of RAM, the Hypervisor Memory Overhead is as follows: 512 MB + (32 MB + 8 MB) + (32 MB + 8MB) + 32 MB + 32 MB = 512 MB + 40 MB + 40 MB + 32 MB + 32 MB = 656 MB (.64 GB) Capacity Advisor assumes that a host will be filled with 1 GB guests when estimating the memory overhead for Hyper-V. This provides a generous estimate of memory overhead, as this configuration will maximize the size of the memory overhead. As a result, allowing Capacity Advisor to estimate the Hypervisor Memory Overhead for Hyper-V will leave extra headroom on Hyper-V hosts when providing consolidation recommendations. Source: Performance Tuning Guidelines for Windows Server 2008 on the Windows Hardware Developer Central web site. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 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. 
