Analyzing Your Security and Privacy Needs

Understanding and Deploying LDAP Directory Services > 4. Directory Road Map > The Directory Life Cycle

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078208063107203199249193200

The Directory Life Cycle

The life cycle of your directory can be broken down into three general phases: the design phase , the deployment phase , and the maintenance phase . It will come as no surprise to many of you 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), then discover during the deployment phase that there are problems with your design that send you back to the design phase.

New features introduced at any phase can cause a new, miniature design-deploy-maintain cycle. Requirements can also change, even in the maintenance phase, causing a redesign of parts of the service.

You should 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. The important thing is that all the phases are covered.

Nevertheless, it is still helpful to think of the three phases as being separate, especially for discussion purposes. Each phase has distinct tasks:

  • During the design phase you will do a lot of data gathering about your environment and data sources, your users, applications that will use your directory, and other things. Using this data, you will design a service that fits your needs.

  • 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 its feedback. After the pilot is complete, you will put your directory service into production.

  • During the maintenance phase, you will continually update the data in your directory, keep the service running smoothly, 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, your 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 are 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 tradeoffs 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 a good one because it helps you organize and divide your design decisions. Breaking down the task in this manner also helps us 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 5, "Defining Your Directory Needs."

  • Data.   Whatever type of directory service you want to create, you can be assured that it involves 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 and understanding their relationship to your directory is important. Designing specifically for your organization's data is covered in Chapter 6, "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 7, "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 we shall see in Chapter 8, "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 9, "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. Replication design is covered in Chapter 10, "Replication Design."

  • 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 11, "Privacy and Security Design."

After you've answered the questions posed by these design areas, you will have the beginnings of a fairly 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 all 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, 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, miserable 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 acceptable technically might be disqualified for other, non-technical reasons. For example, you might have concerns about the long- term viability of the product's vendor, the support provided by the vendor might be inadequate, or the product might just be too expensive.

    Try to consider all factors that affect your choice of vendor, be they technical or practical. Don't choose a vendor without some real hands-on experience with its software. This topic is discussed in more detail in Chapter 12, "Choosing 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 (for example, whether it supports the access control capabilities your design calls for or if it supports your replication design). Piloting can also tell you whether the schema you've designed fulfills the needs of the applications that will be using it and whether the data gathering techniques you've designed are feasible . Most aspects of your design can be validated by piloting. More information on piloting your directory service can be found in Chapter 13, "Piloting Your Directory Service."

  • Performance and scale testing.   After you've verified that your design is functionally correct, your next task is to ensure that both your directory design and the directory software you have chosen are capable of handling a production environment. Can the directory scale up to the size required? Can it handle the load a production environment will place on it? What about future plans for expansion? These questions and others can be answered by doing performance and scale testing of your directory service.

    It's important to know what your goals are during this phase. How high must the system scale? How do you know when you are reaching the capacity limits of the current system? Answering these questions will help you avoid unpleasant surprises in your deployment.

  • Tuning the service.   Tuning the service goes hand-in-hand with performance and scale testing. Your goal is to make sure your directory is tuned to be as efficient as possible. Doing so can increase performance and the scale your directory can support. In this task, you should observe your directory in action, looking for bottlenecks or other inefficiencies . Make sure that your directory vendor has documentation describing how to tune the service for optimal performance in various configurations.

    It's equally important to examine the nonsoftware aspects of your service. For example, are your data gathering and maintenance procedures as efficient as possible? How does your service interact with other services on your network? Are the network links between your servers and clients optimal? Asking these questions before getting into full production is a good way to head off problems.

    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 maintenance and other costs as well. This is discussed in Chapter 14, "Analyzing and Reducing Costs."

  • User feedback.   Whatever type of service you are 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.

  • Going 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 15, "Going 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 quite 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 okay to recognize some tasks as exceptions that don't happen very 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 per 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 per day!

You should consider the following aspects of directory maintenance:

  • Data maintenance.   This is quite often the most important and time- consuming task involved in maintaining your directory. If you do not keep the data in your directory up-to-date, the whole service is much less useful. Make sure you have in place maintainable and scalable procedures for keeping your directory data updated. The topic of data maintenance is addressed in Chapter 17, "Maintaining Data."

  • Data backups .   Another important aspect of maintaining a reliable service is performing regular backups of your directory data. Make sure you design for this from the beginning, taking into account any limitations of your directory software. For example, does the software allow online backups, or does the system need to be taken down? You may be able to use the directory's inherent replication capabilities to provide backups. We discuss data backups in Chapter 16, "Backups and Disaster Recovery."

  • Schema additions.   As you deploy new directory-enabled applications, you will often need to extend your directory's schema. Make sure your directory software allows this and that you have in place a procedure for administrators or users deploying new applications to request their schema additions. Also bear in mind that applications may require other changes as well, such as a new indexing configuration.

  • 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 18, "Monitoring."

  • Expansion.   A natural part of maintaining your directory is managing the process by which it expands. In most environments, use of your directory will increase, as will the number of entries in the directory. Sometimes the change will be gradual; sometimes it will happen all at once. Make sure you have planned for this kind of expansion from the outset.

    It's a good idea to have some rules of thumb for when to upgrade. For example, you might want to begin upgrading relevant parts of the system when CPU utilization reaches 75% or when network bandwidth utilization reaches 50%. Knowing in advance what actions to take and when helps protect against unnecessary outages and makes the upgrade process a seamless part of service operation instead of a panicked fire drill.

  • Changing requirements.   Finally, 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.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

applications
         needs
                    designing directories
backups
         data
                    directory maintenance phase
changing
          expansion requirementsdirectory maintenance phase
choosing
         directory software
                    deployment phase 2nd
data
         backups
                    directory maintenance phase
         maintenance
                    directory maintenance phase
data types
          designing directories
deployment phase
          directories 2nd 3rd 4th 5th
                    choosing software 2nd
                    going to production
                    performance and scale testing
                    piloting
                    tuning the service 2nd
                    user feedback
design phase
          directories 2nd 3rd 4th 5th 6th
                    application needs
                    data types
                    data types;schemas
                    namespace
                    replication
                    security
                    topologies
directories
          deployment phase 2nd 3rd 4th 5th
                    choosing software 2nd
                    going to production
                    performance and scale testing
                    piloting
                    tuning the service 2nd
                    user feedback
          design phase 2nd 3rd 4th 5th 6th
                    application needs
                    data types
                    namespace
                    replication
                    schemas
                    security
                    topologies
          maintenance phase 2nd 3rd 4th 5th 6th 7th
                    changing expansion requirements
                    data backups
                    data maintenance
                    expansion 2nd
                    monitoring service
                    schema additions
expansion
          directory maintenance phase 2nd
maintenance phase
          directories 2nd 3rd 4th 5th 6th 7th
                    changing expansion requirements
                    data backups
                    data maintenance
                    expansion 2nd
                    monitoring service
                    schema additions
monitoring
         services
                    directory maintenance phase
namespace
          designing directories
performance and scale testing
          directory deployment
piloting
          directory deployment
production planning
          directory deployment
replication
          designing directories
scale testing
          directory deployment
schema
         additions
                    directory maintenance phase
schemas
          designing directories
security
          designing directories
software
         directory
                    choosing 2nd
testing
         performance and scale
                    directory deployment
topologies
          designing directories
tuning the service
          directory deployment 2nd
user feedback
          directory deployment

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net