The aim of a CDB is to provide the relevant Capacity and performance information to the
appropriate sub-processes of Capacity Management. In addition, these reports could be used by a number of the other Service Management processes. This information is provided through various reports.
Service and Component Based Reports
For each Infrastructure component there should be a team of technical staff responsible for its control and management, and management staff who are responsible for the overall service.
Reports must be produced to illustrate how the service and its constituent components are performing and how much of its maximum Capacity is being used.
Exception Reporting
Reports that show management and technical staff when the Capacity and performance of a particular component or service becomes unacceptable are also a required output from a CDB . Exceptions can be set for any component, service or measurement that is stored within a CDB.
An example exception may be that CPU percentage utilisation for a particular server has breached 70% for three consecutive hours, or that the hit rate from Users exceeded all expectations.
In particular, exception reports are of interest to the SLM process in determining whether the targets in SLAs have been breached. Also the Incident and Problem Management processes may be able to use the exception reports in the resolution of Incidents and Problems.
Capacity Forecasts
To ensure the IT Service Provider continues to provide the required service levels, the Capacity Management process must predict future growth. To do this, future component and service Capacity must be forecast. This can be done in a variety of ways depending on the technology used by the component. Changes to workloads by the development of new functionality must be considered alongside growth in workload that is driven by business growth. A simple example of a Capacity forecast is a correlation between a business driver and a component utilisation, e.g.
CPU utilisation against the number of accounts supported by the company. Then this data can be correlated to find the effect that increased numbers of accounts will have on the utilisation of particular components of the configuration.
If the forecasts on future Capacity requirements identify a requirement for increased resource, this requirement needs to be input to the IT budget cycle.
6.3.6 Demand Management Objective
The prime objective of Demand Management is to influence the demand for computing resource and the use of that resource.
Description
This activity can be carried out as a short-term requirement because there is insufficient current Capacity to support the work being run, or, as a deliberate policy of IT management, to limit the required Capacity in the long term.
Short-term Demand Management may occur when there has been a partial failure of a critical resource in the IT Infrastructure. For example, if there has been a failure of part of the memory on a processor, it may not be possible to run the full range of services. However a limited subset of the services could be run. Capacity Management should be aware of the business priority of each of the services, know the resource requirements of each service (in this case, the amount of memory required to run the service) and then be able to identify which services can be run while there is a limited amount of memory available.
Long-term Demand Management may be required when it is difficult to cost-justify an expensive upgrade. For example, many processors are heavily utilised for only a few hours each day, typically between 10:00 – 12:00 and 14:00 – 16:00. Within these periods, the processor may be over-loaded for only one or two hours. For the hours between 18:00 – 08:00 these processors are only very lightly loaded, and the resource is under-utilised. Is it possible to justify the cost of an upgrade to provide additional resource for only a few hours in 24 hours, or is it possible to influence the demand and spread the requirement for resource across the 24 hours, thereby avoiding the need for the upgrade?
Demand Management needs to understand which services are utilising the resource and to what level, and needs to know the schedule of when they must be run. Then a decision can be made on whether it will be possible to influence the use of resource, and if so, which option is
appropriate.
The influence on the services that are running could be exercised by:
● physical constraints – for example, it may be possible to stop some services from being
available at certain times, or to limit the number of Customers who can use a particular
service, for example by limiting the number of concurrent Users; the constraint could be implemented on a specific resource or component, for example by limiting the number of physical connections to a network router or switch.
● financial constraints – if Charging for IT Services is occurring, reduced rates could be
offered for running work at certain times of the day, that is the times when there is currently less demand for the resource.
Demand Management can be carried out as part of any one of the sub-processes of Capacity Management. However Demand Management must be carried out sensitively, without causing damage to the business Customers or to the reputation of the IT organisation. It is necessary to understand fully the requirements of the business and the demands on the IT Services, and to ensure that the Customers are kept informed of all the actions being taken.
6.3.7 Modelling Objectives
A prime objective of Capacity Management is to predict the behaviour of IT Services under a given volume and variety of work. Modelling is an activity that can be used to beneficial effect in any of the sub-processes of Capacity Management.
Description
The different types of modelling range from making estimates based on experience and current resource utilisation information, to pilot studies, prototypes and full scale benchmarks. The former is cheap and a reasonable approach for day-to-day small decisions, while the latter is expensive but may be advisable when implementing a large new project.
Trend Analysis
Trend analysis can be done on the resource utilisation and service performance information that has been collected by the Service and Resource Capacity Management sub-processes. The data can be held in a spreadsheet and the graphical and trending, and forecasting facilities used to show the utilisation of a particular resource over a previous period of time, and how it can be expected to change in the future.
Typically trend analysis only provides estimates of future resource utilisation information. Trend analysis is less effective in producing an accurate estimate of response times in which case either analytical or simulation modelling should be used.
Analytical Modelling
Analytical models are representations of the behaviour of computer systems using mathematical techniques, e.g. multi-class network queuing theory. Typically a model is built using a software package on a PC, by specifying within the package the components and structure of the
configuration that needs to be modelled, and the utilisation of the components, e.g. CPU, memory and disks, by the various workloads or applications. When the model is run, the
queuing theory is used to calculate the response times in the computer system. If the response times predicted by the model are sufficiently close to the response times recorded in real life, the model can be regarded as an accurate representation of the computer system.
The technique of analytical modelling requires less time and effort than simulation modelling, but typically it gives less accurate results. Also the model must be kept up-to-date. However if the results are within 5% accuracy for utilisation and 15 – 20% for on-line application response times, the results are usually satisfactory.
Simulation modelling
Simulation involves the modelling of discrete events, e.g. transaction arrival rates, against a given hardware configuration. This type of modelling can be very accurate in sizing new
applications or predicting the effects of Changes on existing applications, but can also be very time-consuming and therefore costly.
When simulating transaction arrival rates, have a number of staff enter a series of transactions from prepared scripts, or use software to input the same scripted transactions with a random arrival rate. Either of these approaches takes time and effort to prepare and run. However it can be cost-justified for organisations with very large systems where the cost (millions of pounds) and the associated performance implications assume great importance.
Baseline Models
The first stage in modelling is to create a baseline model that reflects accurately the
performance that is being achieved. When this baseline model has been created, predictive modelling can be done, i.e. ask the ‘what if?’ questions that reflect planned Changes to the hardware and/or the volume/variety of workloads. If the baseline model is accurate, then the accuracy of the result of the predicted Changes can be trusted.
Effective Service and Resource Capacity Management together with modelling techniques enable Capacity Management to answer the ‘What if’ questions. ‘What if the throughput of Service A doubles?’ ‘What if Service B is moved from the current processor onto a new processor – how will the response times in the two services be altered?’
6.3.8 Application sizing
Application sizing has a finite life-span. It is initiated at the Project Initiation stage for a new application or when there is a major Change of an existing application, and is completed when the application is accepted into the operational environment.
Objective
The primary objective of application sizing is to estimate the resource requirements to support a proposed application Change or new application, to ensure that it meets its required service levels. To achieve this application sizing has to be an integral part of the applications lifecycle.
Description
During the initial systems analysis and design the required service levels must be specified. This enables the application development to employ the pertinent technologies and products, in order to achieve a design that meets the desired levels of service. It is much easier and less
expensive to achieve the required service levels if the application design considers the required service levels at the very beginning of the application lifecycle, rather than at some later stage.
Other considerations in application sizing are the resilience aspects that it may be necessary to build into the design of the new application. Capacity Management is able to provide advice and guidance to the Availability Management process about the resources required to provide the required level of resilience.
The sizing of the application should be refined as the development process progresses. The use of modelling can be used within the application sizing process.
The SLRs of the planned application developments should not be considered in isolation. The resources to be utilised by the application are likely to be shared with other services and potential threats to existing SLA targets must be recognised and managed.
When purchasing software packages from external suppliers it is just as important to understand the resource requirements needed to support the application. Often it can be difficult to obtain this information from the suppliers, and it may vary, depending on throughput. Therefore, it is beneficial to identify similar Customers of the product and to gain an understanding of the resource implications from them. It may be pertinent to benchmark trial the product prior to purchase.
KEY MESSAGE
Quality must be built in.
Some aspects of service quality can be improved after implementation (additional hardware can be added to improve performance, for example).
Others – particularly aspects such as reliability and maintainability of
applications software – rely on quality being ‘built in’, since to attempt to add it at a later stage is in effect redesign and redevelopment, normally at a much higher cost than the original development. Even in the hardware example quoted above, it is likely to have cost more to add Capacity after service implementation rather than as part of the original project.
From Quality Management for IT services, ITIL
6.3.9 Production of the Capacity Plan Objective
The prime objective is to produce a plan that documents the current levels of resource utilisation and service performance, and after consideration of the business strategy and plans, forecasts the future requirements for resource to support the IT Services that underpin the business activities. The plan should indicate clearly any assumptions made. It should also include any recommendations quantified in terms of resource required, cost, benefits, impact etc.
Description
The production and update of a Capacity Plan should occur at pre-defined intervals. It is, essentially, an investment plan and should therefore be published annually, in line with the business or budget lifecycle, and completed before the start of negotiations on future budgets. A quarterly re-issue of the updated plan may be necessary to take into account changes in
business plans, to report on the accuracy of forecasts and to make or refine recommendations.
The typical contents of a Capacity Plan are described in Annex 6B.
This is a Value Added product which falls outside the scope of the HMSO Core Licence.
© Crown Copyright 2001
6.4 Costs, benefits and possible problems
6.4.1 Costs
The costs associated with establishing a Capacity Management process include:
● procurement of required hardware and software tools including:
❍ monitoring tools (performance and utilisation) covering hardware, operating
system and application Capacity. These tools should be capable of monitoring and collecting data from all required host, network and client environments
❍ CDB for holding a historic record of all service, technical, utilisation, financial and
business data
❍ modelling tools for performing simulation modelling and statistical analysis
❍ graphical and textual reporting tools (often web-enabled)
● project management – implementation of Capacity Management should be treated as a
project
● staff costs – recruitment, training and consultancy costs associated with the set-up of the
Capacity Management process
● accommodation – provision of an adequate working environment and facilities, which
may be distributed.
The costs associated with maintaining a Capacity Management include:
● annual maintenance and required upgrades of all hardware and software tools
● on-going staff costs including salaries, further training and ad hoc consultancy
● recurring accommodation costs such as leasing, rental and energy costs.
As discussed earlier Capacity Management responsibilities may be distributed either
geographically or functionally within the organisation. Where this is the case, additional costs will be incurred for the central co-ordination and reporting of Capacity information.