| Test Objectives Covered: Use Index Manager to improve directory performance. Configure replica filters. Maintain eDirectory 8.6.
As you learned at the beginning of the chapter, eDirectory is a distributed, replicated database. Therefore, it's imperative that you develop an eDirectory maintenance plan to help maintain the health of the directory. Your maintenance plan should accomplish two important goals: performance and reliability. In this final eDirectory management lesson, you will learn some critical strategies for maintaining a healthy, high-performing eDirectory: eDirectory indexes eDirectory gives you the ability to create trees with a very large number of objects. To maintain a high level of performance with a large tree, eDirectory records frequently requested information and stores it in indexes. In this lesson, you will learn how to use the Novell Index Manager to create, delete, and associate eDirectory indexes. eDirectory filtered replicas eDirectory partitioning has many advantages because it enables you to separate the tree into smaller segments. You can also increase network fault tolerance by placing copies of other partitions on local servers. This process is known as replication. eDirectory 8.6 lets you configure filtered replicas of a partition so that you can limit synchronization across the network and reduce the overall size of the directory database. In this lesson, you learn what filtered replicas are and learn how to configure them with the Filtered Replica Configuration Wizard. eDirectory cache The most significant setting that affects eDirectory performance is the cache. eDirectory 8.6 provides two default cache settings for controlling cache memory consumption. In this lesson, you learn how to configure cache limits by using DSTRACE. eDirectory health checks You should run regular health checks to keep eDirectory running smoothly and to make upgrades and troubleshooting much easier. You should adjust the frequency of health checks as your environment changes. Some of the factors that influence the timing of your health checks include the number of partitions and replicas in your Directory; the stability of replica holding servers; the amount of information in an eDirectory partition; the eDirectory object size; and the number of errors in previous DSREPAIR operations. For more information regarding specific eDirectory health check procedures, refer to the "eDirectory Integration" section in the first lesson of this chapter.
Now, let's create an eDirectory maintenance plan by using indexes, filtered replicas, and cache. eDirectory Indexes eDirectory relies on distributed indexes to maintain its scalability and high level of performance. An index is an attribute of a Server object and is stored in the Directory. As such, each index is unique to one server and is not shared by other servers in the eDirectory tree. For example, suppose you have a tree with a single partition and three replicas. If you want to index the Telephone Number attribute of User objects in the tree, you would have to create an index on each server that holds a replica. Although indexes improve search performance, additional indexes can also add overhead to server operations. Therefore, avoid putting duplicate indexes on the same replica. In this first component of the eDirectory maintenance plan, you will learn how to use eDirectory indexes and Predicate Statistics Data to increase the search performance of large directory trees. Understanding Indexes and Predicate Statistics eDirectory 8.6 includes a ConsoleOne utility called Index Manager that enables you to create, configure, and maintain eDirectory indexes. With Index Manager, you can view a variety of properties of each index, including the index name, state, type, rule, and specific attribute indexed. The following index types are available in eDirectory 8.6: User This type of index is user-defined and is the only type that can be added using Index Manager. It can be edited and deleted as well. Auto Added eDirectory adds this type of index when certain attributes are created. It can also be edited and deleted. (See Table 3.5 for more information.) Operational These indexes must be present to run the system. They cannot be edited or deleted. (See Table 3.5 for more information.) System These indexes must be present to run the system. They also cannot be edited or deleted.
Table 3.5 shows the default indexes created during NetWare 6 installation. As you can see from the table, eDirectory automatically creates several Operational and Auto Added index types. As a NetWare 6 CNE, you should consider creating a number of User-type indexes to ensure an acceptable level of directory searching performance. Table 3.5. Default eDirectory IndexesINDEX NAME | ATTRIBUTE INDEXED | TYPE |
|---|
CN | cn | Auto Added | CN_SS | cn | Auto Added | dc | dc | Auto Added | Given Name | Given Name | Auto Added | Surname | Surname | Auto Added | uniqueID | uniqueID | Auto Added | uniqueID_SS | uniqueID | Auto Added | Aliased Object | Aliased Object Name | Operational | Obituary | Obituary | Operational | Member | Member | Operational | Reference | Reference | Operational | Equivalent to Me | Equivalent to Me | Operational |
TIP In earlier versions of NDS, administrators were advised to keep partitions limited to between 3,500 and 5,000 objects to maintain an acceptable level of searching performance. Because eDirectory has no such limit, indexing was implemented to provide fast access to a database that could potentially become very large.
eDirectory 8.6 includes an assessment tool to identify the types and quantities of Directory Services queries that are being requested by your server. This information is called Predicate Statistics Data. By using this information, you can create indexes for the most frequently requested information. Now let's take a look at the step-by-step procedures for gathering Predicate Statistics Data, analyzing that data, and creating appropriate eDirectory indexes. Configuring eDirectory Indexes Creating an eDirectory index with the help of Predicate Statistics Data is a three-step process: Step 1: Enable Predicate Statistics Data Gathering Step 2: Check Predicate Statistics Data Step 3: Create an eDirectory Index
Step 1: Enable Predicate Statistics Data Gathering The index assessment tool built into eDirectory is based on the ndsPredicateStats object. Before you can analyze the Predicate Statistics Data and create an eDirectory index, you need to enable data gathering at the server level. In the property of your Server object, there is a Predicate Data tab that displays the frequency of Directory Service queries as they are recorded by the ndsPredicateStats object. See Figure 3.5 for more information. Figure 3.5. Viewing Predicate Data information at the Server Object.
To create an ndsPredicateStats object and associate it with a Server object, complete the following steps: Open ConsoleOne and browse to the container where your Server object resides. Right-click the container and select New, Object. In the New Object field, select ndsPredicateStats, and click OK. In the Name field, enter an appropriate name. Make sure to incorporate the name of the server so you can track which object hosts the predicate statistics. In the Server field, browse to and select the Server object you want to gather statistics for. Select Advanced and mark the following three options: Enable, Display Value Text, and Write to Disk. Select OK twice and predicate statistics data gathering has been enabled.
Step 2: Check Predicate Statistics Data Once the ndsPredicateStats object has been created and associated with your server, allow 24 hours to pass so that a reasonable amount of data can be recorded. During this time, the ndsPredicateStats assessment tool will gather enough directory services data to represent your typical network demands. To check Predicate Statistics Data for your server, complete the following steps: Activate ConsoleOne and right-click your Server object. Select Properties and select the Predicate Data tab. The Predicate Data statistics that the server gathered for the past 24 hours are displayed. (This is similar to the screen shown in Figure 3.5.) Identify the Object Class attributes that are queried most often on your network. These will become the foundation of your new eDirectory indexes.
When you have finished checking your Predicate Statistics Data, make sure to disassociate the ndsPredicateStats object from the server and to disable it. Otherwise, server performance will be impacted. Step 3: Create an eDirectory Index After you have gathered your server's Predicate Statistics Data and identified the most frequently queried attributes, it is time to create several eDirectory indexes to increase search performance. To create an eDirectory index, complete these steps: Activate ConsoleOne and right-click your Server object. Select Properties and the Indexes tab. A complete list of already defined indexes for this server will appear. Initially, this list should match the list of default indexes shown in Table 3.5. Also note that the state of each index is Online. To add a new index for an attribute that you identified using the ndsPredicateStats object and the Predicate Data tab in ConsoleOne, select Add. The Create Index dialog box should appear (as shown in Figure 3.6). This dialog requires three pieces of information: Index Name Usually matches the attribute. Attribute Matches the attribute that you identified as having a high frequency in the Predicate Statistics Data step. Rule Applies one of the following rules for the index: value (reports the presence of an attribute and its value), presence (reports the presence only of an attribute), or substring (matches a part of the larger, stored attribute string).
Figure 3.6. The Create Index dialog box in ConsoleOne.
After you have entered all the required information in the Create Index dialog box, select OK and your new index will be created. ConsoleOne will respond with a new Indexes list (as shown in Figure 3.7). Notice in the figure that the new index is italicized and has a state of New. Figure 3.7. The Indexes tab in ConsoleOne.
In this section, you have learned the three-step process for identifying frequently accessed attributes and creating an index for each of them. Remember that balance is the best policy when it comes to creating eDirectory indexes. It is possible to have too much of a good thing and your server performance will suffer. Now let's shift our focus away from searching performance to eDirectory partitioning and replication. Lab Exercise 3.3: Create Novell eDirectory Indexes As you learned in this lesson, creating an eDirectory index is a three-step process: Step 1: Enable Predicate Statistics Data gathering Step 2: Check Predicate Statistics Data Step 3: Create an eDirectory index
As the ACME administrator, you have decided that you want to create some eDirectory indexes on the WHITE-SRV1 server. In the first step, you have already created the ndsPredicateStats object and associated it with the WHITE-SRV1 server. After 24 hours, you analyzed the data and determined that the most actively used attribute is the Internet E-mail Address. Now it's time to create an eDirectory index for the Internet E-mail Address attribute. In this exercise, you will learn how to use eDirectory data to populate your users' Netscape address books with names and e-mail addresses. To increase performance, you will use ConsoleOne to create an index on the WHITE-SRV1 server for the Internet E-mail Address attribute. In this lab exercise, you'll need the WHITE-SRV1 server created in Lab Exercise 2.2. Complete the following tasks: At the WHITE-SRV1 server console prompt, execute ConsoleOne. If necessary, authenticate as admin. When the ConsoleOne screen appears, navigate to the WHITE-SRV1 Server object. Right-click WHITE-SRV1, and then select Properties. When the Properties of WHITE-SRV1 screen appears, navigate to the Indexes tab, and then select it. When the Index Manage page appears, select Add. When the Create Index dialog box appears In the Index Name field, enter E-mail Index. In the Attribute drop-down list, select Internet EMail Address. In the Rule drop-down list, select Value. Select OK.
When the Index Manage page reappears, note that the status of the E-mail Index is either New or Building. To refresh the view, select the Media tab, and then reselect the Indexes tab. When the Index Manage page reappears, verify that the status of the E-mail Index has changed to "Online," and then select OK.
eDirectory Filtered Replicas eDirectory 8.6 includes a segmentation strategy known as partitioning. Partitioning breaks up your eDirectory tree into two or more logical divisions that can be separated and distributed. Copies of partitions can be distributed on multiple file servers in a strategy known as replication. eDirectory replicas increase network performance (by decreasing the size of database files and by placing them closest to the users that need them) and increase fault tolerance (because extra copies of the database are distributed throughout the network). eDirectory supports four types of full replicas: Master The Master replica is the original read/write copy of a partition. The Master replica is created by default when you define the partition and contains a complete copy of the object data for the partition. Only 1 Master per partition, please. Read/Write A Read/Write replica is a read/write copy of a partition. The Read/Write replica contains a complete copy of the object data for the partition. Each partition can have multiple Read/Write replicas. Read-Only A Read-Only replica is a read-only copy of a partition. The Read-Only replica contains a complete copy of the object data for the partition. These replicas are only used for searching the eDirectory tree and viewing objects. Subordinate References Subordinate References are a special type of replica that are created and maintained by eDirectory. They do not contain object data; they simply point to replicas that do.
Because eDirectory is a distributed, replicated database, NetWare servers continually share information and synchronize changes with each other. When you modify objects in a Read/Write or Master replica, those changes are propagated to all other replicas of the same partition. This process, known as replica synchronization, creates background traffic over network communication lines. The amount of time required for a change to be replicated and synchronized depends on the type of change, the size of the partition, and the number of servers the partition is replicated on. Fortunately, eDirectory 8.6 allows you to create filtered replicas that limit background synchronization traffic and improve overall network performance. In this lesson, we will explore the fundamentals of filtered replicas and explain how to create them using the Filtered Replica Configuration Wizard. Understanding Filtered Replicas Filtered Replicas are partial versions of full Read/Write or Read-Only replicas that limit synchronization to a specific set of attributes and/or values of selected objects or object classes. The filtered replica is a property of each Server object and can be customized at the server level. A filtered replica operates just like a traditional one, except for two important differences: 1) Filtered replicas are associated with Server objects, not stored on physical server machines, and 2) Filtered replicas can filter the data stored and updated in a server replica. A filtered replica can be changed back to a full replica at any time. Filtered replicas offer three benefits. They reduce Synchronization traffic to the server by reducing the amount of data that must be replicated from other servers. The number of events that must be filtered by directory applications such as DirXML. The size of the directory database on your local server.
eDirectory synchronization is accomplished within a group of servers known as a replica ring. A replica ring is an internal system group that includes all servers that contain replicas of a given partition. Because filtered replicas support all versions of eDirectory, you can receive synchronization from any server in the replica ring. The benefits provided by filtered replicas, however, behave very differently, depending on which version of eDirectory your server is running. Following is a timeline of the two most popular eDirectory versions and how they synchronize filtered replicas: Filtered Replica Synchronization Before eDirectory 8.5 Before eDirectory 8.5, a full replica of a given partition was stored by all servers in the replica ring. One server stored the Master replica while the other servers stored a Read/Write or Read-Only version of the Master. Changes made to Master or Read/Write replicas were broadcast to all other servers in the replica ring. A server running a version of eDirectory before 8.5 will not recognize filtered replicas. It simply sends all changes in an update to the target server it is synchronizing with. If the target server (running eDirectory 8.5 or later) has a filtered replica, only the filtered changes are made to the server's replica database. However, all data in the update is broadcast over the network. In fact, it defeats the network bandwidth efficiency that would normally be achieved using filtered replicas. Filtered Replica Synchronization After eDirectory 8.5 Replica synchronization became a lot more sophisticated in eDirectory 8.5 with the dynamic recognition of filtered replicas. With eDirectory 8.5 or 8.6, the sending server reads the target server's replica filter and stores the filter information in memory. Then, the sending server uses this filter to send only the data allowed by the target server's replica filter. This way no unnecessary information is broadcast over the network. If you change the filtered replica on a target server, the target sends notification to the sending server and the sending server updates its filter information before sending the changes to the target. This is the dynamic aspect of eDirectory 8.5 and 8.6 synchronization. Now that you understand the basic fundamentals of filtered replicas, it's time to learn how to configure them using the Filtered Replica Configuration Wizard. TIP Following are two examples of how you may apply Filtered Replicas to your eDirectory network: Remote sales office Suppose your company has a remote sales office with a single server. Salespeople from all over the company pass through the office and log in while they are there. Rather than placing full replicas of the entire eDirectory database on this server, you can create a set of filtered replicas on the server that contain only User objects from various partitions in the tree. LDAP-compliant applications Novell's LDAP implementation requires that a replica containing each user be present on the local server to be available through LDAP. Rather than place a full replica of every partition containing users on the server running NLDAP.NLM, you could place filtered replicas containing only User objects.
Using the Filtered Replica Configuration Wizard ConsoleOne includes a Filtered Replica Configuration Wizard that enables you to define filters for specific attributes on specific servers for a set of eDirectory replicas. Before we explore the step-by-step procedure for setting up a server's replica filter and partition scope, let's discuss some important configuration guidelines: Master partition replica The Master partition replica of a filtered replica must be hosted on a server running eDirectory 8.5 or later. Scopes and filters The descriptions of a given server's partition, scope, and data filters are stored as attributes of the Server object and are managed using ConsoleOne. Attribute subsets In addition to filtering by Object Class, you can also include only a subset of a specific object's attributes. For example, you could filter by Given Name, Surname, and Telephone Number attributes of the User object. Filter modification A server's filter can be modified at any time, however, the operation generates a resynchronization of the replica and can consume server resources and take time to complete. Filter limitation A server filter contains the set of eDirectory classes and attributes you want the server to host. Remember that you can only set up one filter per server. This means that any filter defined for a server applies to all filtered replicas on that server. However, it does not apply to full replicas.
Follow these steps to set up a server's replication filter and partition scope using the Filtered Replica Configuration Wizard: Activate ConsoleOne and select Wizards. Next, choose Filtered Replica Configuration. The Filtered Replica Configuration Wizard will appear. Select the Server object that will host the filtered replicas and choose Next. To define the replication filter for this server, select Define the Filter Set. Next, choose Edit Filter and a list of available classes and attributes will appear. Refer to Figure 3.8. Figure 3.8. Editing filtered replicas in ConsoleOne.
Add the classes and attributes you want in the replica using the Select Filter checkboxes shown in Figure 3.8. Notice in the figure that object classes are listed in the left window with their corresponding attributes appearing in the right window. After you have configured the specific object classes and attributes for this replica, select OK. Select OK, Next, and the Configuration Wizard will ask you to define the partition scope. The partition scope is the set of partitions that you want replicas of placed on this server. The Partition Scope screen in ConsoleOne provides an expandable view of the eDirectory partitions. You can select individual partitions, a set of partitions of a given branch, or all partitions in the tree. To define the partition scope for this server, select Define the Partition Scope and click OK when you are finished. After you have configured the filtered replica and defined the partition scope, you must change the replica's type. First, select the replica from the list and select Change Replica Type. Choose one of two types in the Select Replica Type dialog box: Filtered Read/Write or Filtered Read-Only. Select OK when you are finished. Select OK, Next, and then Finish to complete the Filtered Replica Configuration Wizard. The replica you have just created now appears in the Partition and Replica view of ConsoleOne. See Figure 3.9. Figure 3.9. Viewing the new filtered replica in ConsoleOne.
You can appreciate the sophistication of this eDirectory tool as you work hard to optimize eDirectory synchronization and performance. Now let's complete our eDirectory 8.6 maintenance plan with a quick lesson in eDirectory caching. Lab Exercise 3.4: Configure Filtered Replicas In this exercise, you learn to use ConsoleOne to create partitions of the Organizational Unit containers you imported in Exercise 3.2. You then create filtered replicas of these partitions on the WHITE-SRV1 server. In this lab exercise, you need the following servers: Complete the following tasks: At the WHITE-SRV1 server console prompt, execute ConsoleOne. If necessary, authenticate as admin. Create a partition for the Administrators container in ACME by performing the following tasks: Right-click the Administrators container; then select Views, Partition and Replica View. Select Edit, Create Partition. When the Create Partition window appears, select OK. When the Creating Partition window appears, select Close. Select View, Refresh. (You might need to select Refresh twice to view the results.)
Create a partition for the Contractors container in ACME by performing the following tasks: Right-click the Contractors container and then select Views, Partition and Replica View. Select Edit, Create Partition. When the Create Partition window appears, select OK. When the Creating Partition window appears, select Close. Select View, Refresh. (You might need to select Refresh twice to view the results.)
Use the Filtered Replica Configuration Wizard to create a filtered replica of the partition you created that contains administrator objects and associated attributes: Select Wizards, Filtered Replica Configuration. When the first Filtered Replica Configuration Wizard window appears, browse to and select the LABS-SRV1 server (which should hold a read/write replica of each partition you created in steps 2 and 3), and then select Next. When the next Filtered Replica Configuration Wizard window reappears, select Define the Filter Set. When the Properties of LABS-SRV1 window appears, select Edit Filter. When the Select Filter dialog box appears In the left column, select the User object class. In the Attributes column, select All Attributes. Select OK.
When the Properties of LABS-SRV1 window reappears, verify that Enable Local Login is selected, then select OK. When the Filtered Replica Configuration Wizard window reappears, select Next. When the next Filtered Replica Configuration Wizard window appears, select Define the Partition Scope. When the Properties of LABS-SRV1 window appears In the ACME-TREE folder, select the Administrators replica you created in step 2. Select Change Replica Type.
Next, choose Filtered Read/Write; then select OK. When the Properties of LABS-SRV1 window reappears, select OK. When the Filtered Replica Configuration Wizard window reappears, select Next. When the next Filtered Replica Configuration Window appears, select Finish to complete the operation of configuring the filtered replicas on LABS-SRV1.
Verify that the filtered replicas were created on server LAB-SRV1: Select the Administrators partition you created in step 2. Confirm that a filtered replica of the partition exists.
eDirectory Cache The most significant setting that improves eDirectory performance is the cache. eDirectory 8.6 caches physical blocks from the server disk into file server memory using one of following two types of cache: Block cache Block cache caches only physical blocks from the hard disk without any organization of the information contained in the block. This is the older cache type used by earlier versions of NDS. Block cache is most useful for update operations. It can also improve query performance by speeding up index searching. Entry cache Entry cache is a new feature in eDirectory 8.6 that caches the logical directory structure of the eDirectory tree. By caching the logical structure of containers and objects, eDirectory can use this cache to quickly find and retrieve entries from memory. Entry cache is most useful for operations that browse the eDirectory tree by reading through entries (such as name resolution). Finally, entry cache can improve query performance by speeding up the retrieval of entries referenced from an index.
Although there is some redundancy between these two eDirectory cache types, each cache boosts performance for different types of operations. Earlier versions of eDirectory created multiple versions of blocks and entries in its cache for transaction integrity. eDirectory 8.5 (and prior) did not remove these blocks and entries from the cache when they were no longer needed. This caused considerable overhead in cache memory consumption. Fortunately, eDirectory 8.6 includes a background process which periodically browses the cache and cleans out older versions. The default browsing interval is 15 seconds. The total available memory for eDirectory caching is shared between these two cache types. The default is an equal division. The more blocks and entries that are cached, the better your overall Directory performance. The ideal strategy is to cache the entire database in both the entry and block caches (although this is impossible for large trees). In general, you should try to achieve a 1:1 ratio of block cache to eDirectory database size and a 1:2 or 1:4 ratio for entry cache. eDirectory 8.6 provides two default cache settings for controlling cache memory consumption: Dynamically Adjusting Limit The dynamically adjusting limit causes eDirectory to periodically adjust its memory consumption in response to the needs of the network. In this option, you specify the limit as a percentage of available physical memory and eDirectory recalculates a new memory limit at fixed intervals. The new memory limit is the percentage of physical memory available at the time. Along with the percentage, you can set a maximum and minimum threshold as either the number of bytes to use or the number of bytes to leave available. The minimum threshold default is 16MB (8MB for entry cache and 8MB for block cache). The maximum threshold default is 4GB. With the dynamically adjusting limit, you can also specify the interval length (15 seconds by default). The shorter the interval, the more memory consumption is based on current conditions. However, shorter intervals are not necessarily better because the percentage recalculation will create more memory allocation and freeing. Fixed Memory Limit The fixed memory limit is the method used by earlier versions of NDS. In this cache memory consumption method, you can set a fixed memory limit in one of the following ways: fixed number of bytes (this is a set number of bytes assigned to the memory limit), percentage of physical memory (the percentage of physical memory at the interval becomes a fixed number of bytes), or percent age of available physical memory (the percentage of available physical memory at the interval becomes a fixed number of bytes).
You can use either of these two methods for controlling cache memory consumption but you cannot use them at the same time because they are mutually exclusive. The last method used always replaces prior settings. If the server you are installing into the tree does not have a replica, the default fixed memory limit is 16MB (with an even split between block and entry cache). However, if your server does contain a replica, the default memory is a dynamically adjusting limit of 51 percent of available server memory with a minimum threshold of 8MB per cache and a maximum threshold of keeping 24MB server memory available for other processes. TIP If the minimum and maximum threshold limits are incompatible when using the dynamically adjusting limit method, the minimum threshold limit is followed.
When using eDirectory on NetWare, you can use the DSTRACE utility at the server console to configure dynamically adjusting or fixed memory limits. You do not need to restart the server for the changes to take effect. To set a fixed hard limit, enter the following DSTRACE command at the server console: SET DSTRACE=!MB[memory in bytes] An example of setting a fixed hard limit of 8MB: SET DSTRACE=!MB8388608 To set a calculated limit, enter the following DSTRACE command at the server console: SET DSTRACE=!MHARD,%: [percent], MIN:[bytes],MAX:[bytes],LEAVE:[bytes],NOSAVE An example of a calculated limit of 75 percent of total physical memory with a minimum of 16MB and an option indicating that these options should not be saved to the startup file is SET DSTRACE=!MHARD,%:75,MIN:16777216,NOSAVE To set a dynamically adjusting limit, enter the following DSTRACE command at the server console: SET DSTRACE=!MDYN,%: [percent], MIN:[bytes],MAX:[bytes],LEAVE:[bytes],NOSAVE An example of a dynamically adjusted limit of 75 percent of available memory with a minimum of 8MB is SET DSTRACE=!MDYN,%:75,MIN:8388608 This completes our detailed lesson in configuring the eDirectory cache to tune database performance. As you have learned, this is the most significant setting that can be configured to improve eDirectory performance. In this lesson, you learned about the benefits of block and entry cache and as well as how to distribute memory between these two cache types. In addition, you learned about two different default cache settings (dynamically adjusting and fixed memory) for controlling cache memory consumption. Now that's what I call eDirectory fun. Congratulations! Your eDirectory database has been integrated, maintained, and optimized. This completes our lesson in eDirectory 8.6 management. In this chapter, you learned four procedures for eDirectory integration and used the eDirectory Import/Export Wizard to add large batches of objects to the eDirectory tree using LDIF files. We then turned our attention to eDirectory maintenance and learned how to improve eDirectory performance using indexes, filtered replicas, and cache. Now it's time to move beyond the NetWare 6 directory into a chapter full of NetWare 6 advanced administration tasks, including: managing NetWare 6 remotely, configuring NetWare 6 DNS/DHCP, configuring NetWare 6 to use SLPv2, and using NetWare 6 multitasking, multithreading, and multiprocessing. Ready, set, take off! Lab Exercise 3.5: Understanding Novell's Newest eDirectory (Word Search Puzzle) | Q1: | Circle the 20 Novell eDirectory terms hidden in this word search puzzle using the hints provided. 
Hints Index automatically created by eDirectory when certain attributes are created. Older type of Directory cache that caches only physical blocks from the hard disk without any organization of the information contained in the block. Component that has the most significant impact on eDirectory performance. New type of cache found in eDirectory 8.6 that caches the logical directory structure of the eDirectory tree. Type of replica that can be used to limit background synchronization traffic and improve overall network performance. Allows ICE to send several update operations in a single request and receive a response for all update operations in a single response. Text file format used to exchange data between LDAP-compliant directories. Type of replica that is automatically created when a partition is defined. Segmentation strategy that allows you to break up your eDirectory tree into two or more logical divisions that can be separated and distributed. Public key encryption system used by Novell Certificate Server. Increases network fault tolerance by placing copies of eDirectory partitions on local servers. Defines the eDirectory naming structure for all network resources. eDirectory files that hold information such as print job configurations and login scripts. Type of required index that cannot be edited or deleted. Only type of index that can be added using Index Manager.
|
See Appendix C for answers. Lab Exercise 3.6: Novell eDirectory Management (Crossword Puzzle) | Q1: | 
Across 4. eDirectory can support billions of objects 7. Servers holding replicas of a partition 8. NDS is distributed and _____ 11. Predecessor to NDS 13. Predecessor to eDirectory 14. Least popular replica type
Down 1. eDirectory's highly-scalable, indexed database core 2. Secure, high-performance NetWare 6 Directory service 3. Programming language supported by eDirectory 4. Collection of patches and fixes 5. Directory access protocol supported by eDirectory 6. Main NDS file 9. Used to configure cache limits 10. NDS database core 12. Main eDirectory control file
See Appendix C for answers. |
|
