| Prior to Mac OS X Server 10.3, Open Directory Server was not particularly useful to any but the smallest organizations. This was mainly because of its lack of redundancyOpen Directory had no redundancy, so if the single master disappeared, clients would be left without any directory service. Both the client-side behavior and the server-side redundancy have gradually improved with every Mac OS X Server release, and now Open Directory presents a relatively robust, suitably redundant infrastructure for small to medium organizations. When choosing a role for the Mac OS X Server, the Open Directory Replica option causes the Mac OS X Server to import the necessary data from the specified Open Directory master, thus turning the replica into a secondary copy of the OD master's LDAP, PWS, and KDC. Creating a replica has several benefits. The most obvious is that it eliminates any single point of failure. Second, having more than one server to authenticate users means that requests for authentication can be spread across several servers, possibly in various areas of the country. Apple has done a good job making the replica creation process as simple as possible. To create an Open Directory replica using Server Admin, you must first, of course, have an Open Directory master and know the IP address, shared (LDAP) administrator's name, password, and local root password. Also, make sure that your server is up to date and that forward and reverse DNS entries are properly configured. If the Mac OS X Server is also a DNS server, refer to Chapter 6. Password-authenticated ssh logins should be enabled on the master, at least temporarily during the replica-creation process. To create an Open Directory replica 1. | Launch Server Admin, located in /Applications/Server, select Open Directory from the services list, and click the Settings tab.
| 2. | Click the General tab and choose Open Directory Replica from the Role pop-up menu (see Figure 3.1).
| 3. | In the dialog that appears, specify the IP address of the Open Directory master, the root password on the master, and the username and password of an Open Directory administrator. Then click OK (Figure 3.23).
Figure 3.23. Information required for a Mac OS X Server to take on the role of an Open Directory replica. 
| 4. | In the Server Admin window, click Save and wait for the replication to occur.
After a few moments, the window will update showing the replication information (Figure 3.24). During the replica-creation process, the LDAP and KDC data is scp'd (secure copied, a file transfer protocol based on ssh) over to the new replica. Password Server data is replicated using the Password Server protocol.
Figure 3.24. Server Admin showing completion of an Open Directory replica. 
| 5. | Check your Open Directory master to make sure that the replica was created and choose how often you wish your master to push information down to your replica (Figure 3.25):
- Replicate to Clients Determines how frequently (defined in the GUI as minutes or days) data is sent to Open Directory replicas. Can be set on a time interval or whenever directory data is changed. If the time interval is less than 60 minutes, data is sent to replicas whenever any changes are made is on the Open Directory master.
- Replicate Now Forces immediate replication of the Password Server and LDAP data.
Figure 3.25. Server Admin of the Open Directory master showing its list of replicas and options for updating them. 
|
 Tips
During this process of replica creation, the master's LDAP server will be temporarily stopped in order to ensure that its exported LDAP data is up to date. This will result in a temporary service outage. So create your first replica as soon as possible. The more user, group, and computer records in your domain, the longer this could take. KDC (Kerberos) data is actually replicated and maintained by the Password Server. So the only two replication protocols are critical, Password Server and OpenLDAP.
How Many Replicas? Sizing an Open Directory environment is highly dependent on your usage pattern and network topology. As a rule of thumb, however, you should have at least one replica for redundancy and one replica for every 250 to 500 concurrently active users. For example, a school with 1,500 student machines would be best served with one OD master and three to five replicas (one OD system for every 250 to 375 users). A medium-sized business of 400 client machines could probably get away with just one master and a replica, since office workers typically do not log on and off as much as students do. It's also a good idea to deploy replicas at geographically remote locations to allow for authentication if the link to the main site goes down, reduce site-to-site traffic, and increase services times for those remote clients. Because replicas are relatively easy to set up, you can add replicas as needed to reduce load on existing systems and increase redundancy. |
|
