Chapter 5 Defining Service Level Agreements

Service level agreements are technical specifications that determine how the system must perform under certain conditions. This chapter describes the service requirements that are specific to Directory Server Enterprise Edition. The chapter includes questions that you need to ask during the planning phase to ensure that your deployment meets these requirements.

This chapter covers the following topics:

• Identifying System Qualities

• Defining Performance Requirements

• Defining Availability Requirements

• Defining Scalability Requirements

• Defining Security Requirements

• Defining Latent Capacity Requirements

• Defining Serviceability Requirements

Identifying System Qualities

To identify system qualities, specify the minimum requirements that your directory service must provide. The following system qualities typically form a basis for quality of service requirements:

• Performance. The measurement of response time and throughput with respect to user load conditions.

• Availability. A measure of how often a system's resources and services are accessible to end users, often expressed as the uptime of a system.

• Scalability. The ability to add capacity and users to a deployed system over time. Scalability typically involves adding resources to the system without changing the deployment architecture.

• Security.A complex combination of factors that describe the integrity of a system and its users. Security includes authentication and authorization of users, security of data, and secure access to a deployed system.

• Latent capacity. The ability of a system to handle unusual peak loads without additional resources. Latent capacity is a factor in availability, performance, and scalability.

• Serviceability. The ease by which a deployed system can be maintained, including monitoring the system, fixing problems that arise, and upgrading hardware and software components.

Defining Performance Requirements

Performance requirements should be based on typical models of directory usage. In all directory deployments, Directory Server supports one or more client applications, and the requirements of these applications must be assessed. Estimating how much information your directory contains, and how often that information is accessed, involves identifying these applications and determining how they use Directory Server.

Identifying Client Applications

The applications that access your directory and the data needs of these applications have a significant impact on performance requirements. When identifying client applications, consider the following:

• What types of client applications are accessing Directory Server?

• How many users access each of these applications?

• What kind of operations do these applications perform?

• What are the usage patterns for these operations?

Common applications that might use your directory include the following:

• Browser applications, such as white pages. Applications of this type generally access information such as email addresses, telephone numbers, and employee names.

• Messaging applications, especially email servers. All email servers require email addresses, user names, and routing information. Others require more advanced information such as the place on disk where a user’s mailbox is stored, vacation notification information, and protocol information.

• Directory-enabled human resources applications. These applications require more personal information such as government identification numbers, home addresses, home telephone numbers, and salary details.

• Security, web portal, or personalization applications. Applications of this type access profile information.

When you have identified the information used by each application, you might see that some types of data are used by more than one application. Performing this kind of exercise during the planning stage can help you to avoid data redundancy.

Determining the Number and Size of Directory Entries

The number and size of entries that are stored in the directory depend largely on your data requirements, as described in Chapter 4, Defining Data Characteristics.

Consider the following when calculating the number and size of entries:

• Does the deployment require repeated bulk import initialization?

• If so, how often are imports performed?

• How many entries are imported at a time?

• What types of entries are imported?

• Must initialization be performed online with the server running?

Determining the Number of Reads

In estimating read traffic, consider the following:

• How many searches per second are expected?

• What types of searches are expected?

  For example, unique ID searches, wildcard searches, exact match searches.

• What is the estimated peak search rate?

• What is the estimated average search rate?

• How many unindexed searches are expected?

  An unindexed search means that the database is searched directly, instead of the index file. Unindexed searches occur either when the All IDs Threshold is reached within the index file used for the search, when no index file exists or when the index file is not configured in the way required by the search.

  Unindexed searches are generally more time consuming than indexed searches.

• Are searches concentrated in a particular data center or geographic region?

  If one data receives proportionally more search traffic than other data centers, it might be worth placing additional, replicated servers in this data center to balance the load.

• Are searches concentrated at a particular time of day?

• How many searches are anticipated from within the firewall?

• How many searches are anticipated from outside the firewall?

If read performance is crucial to your enterprise, see Chapter 10, Designing a Scaled Deployment for suggestions on deploying a directory service that is scaled for reads.

Determining the Number of Writes

In estimating write traffic, consider the following:

• How many updates per second are expected?

• What types of updates are expected?

• What is the estimated peak update rate?

• What is the estimated average update rate?

• Are updates concentrated in a particular data center or geographic region?

  If one data receives proportionally more update traffic than other data centers, it might be worth placing additional writable servers in this data center to distribute the update load.

• Are updates concentrated at a particular time of day?

If write performance is crucial to your enterprise, see Chapter 10, Designing a Scaled Deployment for suggestions on deploying a directory service that is scaled for writes.

Estimating the Acceptable Response Time

For each client application, determine the maximum response time that is acceptable. The acceptable response time might differ for various geographical locations, and for different kinds of operations.

Estimating the Acceptable Replication Latency

Estimate the level of synchronicity that is required between master replicas and consumer replicas. The Directory Server replication model is loosely consistent, that is, updates are accepted on a master without requiring communication with the other replicas in a topology. At any given time, the contents of each replica might be different. Over time, the replicas converge until each replica has an identical copy of the data. As part of performance planning, determine the maximum acceptable time that replicas have to converge.

Starting with Directory Server 6.x, a new prioritized replication feature is added. This feature enables you to specify that changes to certain attributes must be replicated as soon as possible. Prioritized replication might affect your decisions about acceptable replication latency. For more information, see Prioritized Replication.

Defining Availability Requirements

Availability implies an agreed minimum up time and level of performance for your directory service. Failure, in this context, is defined as anything that prevents the directory service from providing this minimum level of service.

In assessing availability requirements, consider the following:

• Is your directory service accessed only at particular times of the day?

• Do you have different availability requirements for read and write operations?

• Does the service span multiple geographical sites, and if so, do these sites have different access time requirements?

• Can your system be shut down for maintenance?

  If so, what is the maximum acceptable downtime?

• Can the system be shut down during migration?

• What is the cost of downtime to your organization?

For suggestions on deploying a highly available directory service, see Chapter 12, Designing a Highly Available Deployment.

Defining Scalability Requirements

As your directory evolves, the service levels that must be supported might change. To raise the level of service after a system has been deployed can be difficult. Thus, the initial design must take future requirements into account.

When defining scalability requirements, consider the following:

• Is there an anticipated increase in entry volume?

• How many new users are expected within the next few years?

• What is the expected growth rate, over the next few years, in terms of data, users, and client applications?

• Are any new business processes expected?

Increase CPU estimates to make sure that your deployment does not have to be scaled prematurely. Look at the anticipated milestones for scaling and projected load increase over time to make sure that you allow enough latent capacity to reach the milestones.

Defining Security Requirements

Security requirements warrant separate discussion. These requirements are described in detail in Chapter 7, Identifying Security Requirements.

Defining Latent Capacity Requirements

In determining latent capacity requirements, estimate the peak load conditions for your directory service. Consider the following:

• If all client applications were running, what would be the maximum number of concurrent connections to Directory Server?

• What would be the load on the remaining servers in your deployment if one or more servers were to fail?

Defining Serviceability Requirements

Serviceability requirements are discussed in detail in Chapter 8, Identifying Administration and Monitoring Requirements.