| The life cycle of your directory can be broken down into three general phases: design, deployment, and maintenance. It will come as no surprise that the life cycle is not actually this simple, nor is it so easily segmented. In practice, you may design for a while (until you think you've got it right) and then during the deployment phase discover problems with your design that send you back to the design phase. New features introduced at any phase can necessitate a new, miniature design-deploy-maintain cycle. Requirements can also change, even in the maintenance phase, making it necessary to redesign of parts of the service. View the life cycle of your directory, then, as a series of design, deployment, and maintenance tasks for the original service itself, for new applications that use the directory, and for new features of your directory service. The tasks may appear distinct, or they may blend together. Nevertheless, it is still helpful to think of the three phases as being separate, especially for discussion purposes. Each phase has distinct tasks: -
Design phase . During the design phase you will gather data about your environment and data sources, your users, and your directory-enabled applications. Using this data, you will design a service that fits your needs. -
Deployment phase . During the deployment phase you will pick a directory vendor; pilot your service in a test configuration; and do stress, scale, and performance testing. You will also test the reliability, redundancy, and fault tolerance capabilities of the system. This phase is also where you first expose the system to a relatively small group of users to get feedback. After the pilot is complete, you will put your directory service into production. -
Maintenance phase . During the maintenance phase you will continually update the data in your directory, keep the service running smoothly, accommodate new applications, and continue to improve the service. As your service grows and matures, you may often find yourself in all three of these phases at once. For example, you may be designing a new aspect of the service, deploying the latest addition to the service, and maintaining the current service all at the same time. The following sections delve into each phase of the life cycle in more detail. Design is first, followed by deployment and maintenance. Our goal in this chapter is to give an overview, or road map, of each topic, but not a complete treatment. Subsequent chapters cover each topic in more detail. Design During the design phase of your directory service, the most important task is to understand the requirements that will be placed on your directory. Armed with a clear understanding of these requirements, the rest of your design task will be much easier. The directory will not exactly design itself, of course, but your decisions will be relatively uncomplicated if you fully understand your requirements. The result of the design phase is most likely a document or set of documents describing your directory service, the applications it will serve, the major design decisions made during the design process, and the trade-offs those decisions represent. There are many ways to segment your design process. We've chosen to break things up in the manner described in this chapter. In our experience, this approach is good because it helps you organize and divide your design decisions. Breaking down the task in this manner also helps provide a framework for discussion. Keep in mind, however, that other methodologies may be equally valid. Feel free to explore different approaches, but make sure that you cover all the bases mentioned here. You will find in practice that design decisions you make in one area affect the design of other areas as well. The design phase is aimed at designing a directory to suit your environment in the following areas: -
Directory needs . Your directory service will need to meet the needs of the directory-enabled applications you plan to deploy and the needs of the people who will use those applications. Understanding your applications' needs is covered in Chapter 6, Defining Your Directory Needs. -
Data . Whatever type of directory service you want to create, you can be assured that it will involve some kind of data. Chances are good that you have in your organization many existing sources of data that may prove useful in creating your service. Cataloging these data sources, identifying their owners , and establishing an ongoing relationship to your directory is important. Designing specifically for your organization's data is covered in Chapter 7, Data Design. -
Schema . Your directory exists to support one or more directory-enabled applications. These applications have certain requirements concerning the data contained in the directory, its format, and how the data is interpreted. These characteristics are determined by the directory schemas, as discussed in Chapter 8, Schema Design. -
Namespace . After you determine what data you want to put in your directory, you need a way to organize and reference that data. This is the purpose of a directory namespace. As you will see in Chapter 9, Namespace Design, the choices you make here can have wide- ranging implications for other aspects of the service. -
Topology . Topology design involves determining the number of servers you will need, how your directory data will be split among those servers, and where those servers need to be located. The directory topology that determines these factors is discussed in Chapter 10, Topology Design. -
Replication . Directory-enabled applications often place severe performance and reliability requirements on the directory. Replication is the means by which the same directory data is maintained in multiple directory servers, leading to a more reliable service and more servers that can answer application queries ”thus increasing performance. This subject is the topic of Chapter 11, Replication Design. Note Namespace design, topology design, and replication design are interconnected topics. The decisions you make in one area will constrain your options in the other two areas. Completing the design process for these three areas will involve an iterative approach in which you make assumptions in one area, see how they work out in the other two, and make adjustments until you have arrived at an optimal solution.
-
Security . The security aspect of your design cuts across all other design areas. You must plan to protect the data in the directory itself, as well as design the other aspects of the service to meet the security and privacy requirements of your users and their applications. Many directory design decisions have these security implications. This topic is covered in Chapter 12, Privacy and Security Design. After you've answered the questions posed by these design areas, you will have the beginnings of a complete directory service. The next phase in the development of your directory service is to deploy the service you've designed. Deployment The directory deployment phase is where things start to get real. Until now, you've been collecting data and creating paper designs. In this phase of the project, you actually try things out. You'll work the kinks out of your design, select appropriate directory software, and perform tests to ensure that your design can handle the anticipated load. Finally, you'll roll the directory service into production. Although the deployment phase varies somewhat depending on your design and your user community, there are certain things you should be sure to do. The following list describes some tips for picking the right directory software and the importance of piloting your directory, doing performance and scale testing, and getting user feedback during the deployment phase: -
Choosing directory software . Choosing the proper directory software is important. If you choose software that cannot satisfy your design requirements or cannot scale or perform up to your requirements, it's back to the design drawing board ”or time to choose some new directory software. Either way, you are in for a costly, unpleasant experience that will delay final deployment of your service. Evaluating and choosing directory products can be complicated. You may have requirements not reflected in your ideal design, such as an organizational preference for a particular vendor. Directory products that are technically acceptable might be disqualified for other, nontechnical reasons, such as cost. Try to consider all factors ”technical and practical ”that affect your choice of vendor. Don't choose a vendor without some real hands-on experience with its software. This topic is discussed in more detail in Chapter 13, Evaluating Directory Products. -
Piloting . The purpose of the deployment phase is to validate your design decisions (or prove them invalid, which calls for a redesign) and determine whether your directory service is functioning properly. The best way to do this is by piloting your directory service. A directory pilot requires you to set up, usually on a smaller scale, the directory you have designed and expose it to a limited user community to get feedback. Piloting your directory service can tell you whether the software you have chosen is appropriate. Piloting can also tell you whether the decisions you've made concerning schema, namespace, topology, and replication fulfill the needs of your directory-enabled applications, and whether the data-gathering techniques you've designed are feasible . Finally, in the pilot phase you will test your directory's performance and scaling characteristics to understand better how you will scale the service to meet future needs. More information on piloting your directory service can be found in Chapter 14, Piloting Your Directory Service. -
Analyzing costs . It is also crucial to look at the costs of your directory service from all angles; you need to analyze not only implementation costs, but also maintenance and other costs. This topic is discussed in Chapter 15, Analyzing and Reducing Costs. -
Obtaining user feedback . Whatever type of service you're deploying, it's important to expose it to some users. They are, after all, the reason you're doing all this work in the first place. The service may look great to you but still not meet the needs of your users. Getting user feedback is one of the most important steps in validating your design. It is imperative to get feedback from a cross section of users representing a wide variety of requirements. Without it, you won't know whether you've done a good job meeting your objectives with the service. -
Moving to production . Finally, during the deployment phase you need to develop and execute a plan for taking the directory service from a pilot to production. Think about how you can do this smoothly and incrementally, if possible. Moving into production is discussed in Chapter 16, Putting Your Directory Service into Production. A more complete treatment of directory deployment is covered in Part III, Deploying Your Directory Service. Maintenance The maintenance of your directory service is the longest- lasting phase, but this important aspect of the service often receives the least amount of attention during the design phase. Designing up front for an easy-to-maintain directory can really pay off in lower maintenance costs and happier users and administrators. Not thinking about maintenance until your directory is deployed can result in a fragile system strung together with various kludges. This kind of system leads to higher administrative overhead, higher costs, and, ultimately, unhappy users. For example, consider a directory service design that does not take into account data maintenance. Other aspects of the service may be designed well, and users may be happy with the service initially. But what happens in the weeks and months that follow when the data contained in the directory becomes out-of-date? The service becomes less useful, user satisfaction plummets, calls to the Help Desk skyrocket, and the service designer goes from hero to zero quickly. When designing for a maintainable directory service, think about the everyday or other periodic tasks you will need to perform. How will users be added to the directory? How will data obtained from other sources be kept up-to-date? How often will entries change names , and how painful a process will this be? It's OK to recognize as exceptions some tasks that don't happen often and therefore don't need to be made all that convenient . But keep in mind that your definition of exceptions may change as the number of users in your directory changes. For example, an annoying administrative task that needs to be done once a month on average for every 1,000 users may be perfectly acceptable for a 1,000-user directory. But if your directory grows to 100,000 users, you'll be doing this task more than three times a day! Consider the following aspects of directory maintenance: -
Data backups and disaster recovery . An important aspect of maintaining a reliable service is performing regular backups of your directory data. It's also vitally important to verify your backups to be sure that the data can be restored in the event of a disaster. Finally, if your directory service falls victim to a disaster, having a complete disaster recovery plan is crucial. We discuss these topics in Chapter 17, Backups and Disaster Recovery. -
Data maintenance . Maintaining the data is often the most important task involved in maintaining your directory. If the data in your directory is not up-to-date, the whole service is much less useful. Make sure that you have in place maintainable and scalable procedures for keeping your directory data updated. The topic of data maintenance is addressed in Chapter 18, Maintaining Data. -
Monitoring . Naturally, you'll want to monitor your directory service. You need to know when it goes down so that you can bring it back up quickly. You also need to ensure that it's performing well for your users and then tune it if it is not. You may have an existing monitoring infrastructure in your organization that you want to plug into. The topic of monitoring your directory service is covered in Chapter 19, Monitoring. -
Troubleshooting . Even the best-designed directory service occasionally has problems. Effective troubleshooting of problems is critical to your directory service's success. In Chapter 20, Troubleshooting, we discuss strategies for identifying and remedying problems. -
Changing requirements . Part of your maintenance plan should include contingency plans for handling changing requirements beyond the normal expansion already described. Think about what you would do if any of your fundamental design assumptions were to change, or if additional directory-enabled applications needed to be deployed. Any change in requirements might require that you kick off a small design cycle to accommodate the new requirements, revisiting your data, schema, namespace, topology, replication, and security design. |
