Previously, we looked at setting up an Open Directory Master in macOS. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default. If SSH is not enabled, you will not be able to create an Open Directory Replica. SSH is enabled on a server by opening the Server app, clicking on the name of the server and then clicking on the Settings tab. here, check the box for “Secure shell connections (SSH)”.
Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In OS X Server, I’ve seen each find things that other misses. Additionally, in Yosemite and above, OS X Server now requires to be able to lookup whatever the hostname is set to in order to actually promote either to a replica or a master. To use changeip to verify the hostname is set appropriately:
sudo changeip -checkhostname
The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.
Primary address = 192.168.0.26
Current HostName = odr.krypted.com
DNS HostName = https://krypted.com/
The names match. There is nothing to change.
dirserv:success = “success”
Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of 192.168.0.250:
/usr/sbin/slapconfig -preflightreplica 192.168.0.250 diradmin
Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica. 
Then, click on the Open Directory service. 
Then, use the ON button to start the configuration process. When prompted, click on “Join an existing Open Directory domain as a replica” and click on the Next button. 
When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password. 
Then click on the Next button again to setup the services. 
At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Check Server app on both the Replica and the Master and verify that the server is displayed under the Master. 
Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees.
Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD:
sudo slapconfig -destroyldapserver
Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option:
sudo slapconfig -enableslapdlog
You can use the -addreplica option to add replicas manually while running tail on the slapd logs:
sudo tail -f /var/log/slapd.log
Once the replica has been created, you can add more and split them into locales. You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with logging intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd.
The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.
