The main purpose of SLM is to be able to measure the data center performance against pre-defined goals. These goals should be derived from the SLA between the consumer and the service provider. These goals, in turn, drive the service level objectives (SLOs) in the data center. In addition, it is important to be able to report to customers that promises were met. Having the information that shows the performance against the goals supports the continuous improvement process.
To facilitate the continuous improvement of quality, a good approach to the SLM system uses a circular process because it allows for adjustments as time progresses. The key challenge is to have a realistic starting point when a new service is provided. Because the SLA must be able to be met by the infrastructure capabilities of the IDC, it is important to include the design of an SLM solution during the IDC architectural phase and revisit this design as changes to the architecture are incorporated.
Customers expect the goals, for example, transaction response times and so forth, to be addressed in the SLA. Managing against an SLO also forces the system to be able to report on performance on higher layers, which is what customers experience typically. Managing against an SLO also forces IDC providers to manage components that are not under their control. A third party service provider is a good example, but the network components in the Internet that separate the consumer from the service provider and are largely unknown entities for the service provider are examples, too. The SLM process helps determine where the boundaries are and what can be expected when these boundaries are crossed.
FIGURE 2 is a graphical representation of a SLM process that focuses on the relationship between the SLA and the performance metrics collected. This example is specifically designed to facilitate the tools selection process.
FIGURE 2 SLM Process
The major change is the decision to have SLAs drive the operational measurements of success. Often the service levels delivered are derived from the capabilities of the infrastructure. The business case should drive the QoS, which in turn drives the infrastructure requirements. FIGURE 2 illustrates this point.