The optimum number of servers (master plus replicas) for a domain is determined by a number of factors:
Every domain should have at least one replica server so that NIS+ service is not disrupted when the master server is temporarily unavailable.
The type of clients. Older, slower client workstations require fewer replicas than do newer, faster machines.
If the domain hierarchy that you design spans a wide area network (WAN) link, it is prudent to place a replica on either side of the WAN link. In other words, have a master server and one or more replicas on one side of the link and one or more replicas on the other side. This could possibly enable clients on the other side of the link to continue with NIS+ service even if the WAN link were temporarily disabled. (Putting servers on either side of a WAN, however, does change the structure of a namespace that is organized by group function rather than by physical layout, since the replica might physically reside within the geographic perimeter of a different domain.)
In organizations with many distributed sites, each site often needs its own subdomain. The subdomain master is placed in a higher-level domain. As a result, there can be a great deal of traffic between point-to-point links. Creating local replicas can speed request response and minimize point-to-point traffic across the link. In this configuration, lookups may be handled locally.
The number of subnets in a domain. If you can, put one replica on each subnet (but do not use more than 10 replicas for the entire domain). Note that you do not have to have a replica for every subnet unless you have Solaris 1.x NIS clients and you want NIS+ servers in NIS-compatibility mode to support the NIS clients. NIS clients do not have access to servers that are not on the same subnet. The only exceptions are Solaris NIS clients, which can use ypinit(1M) to specify a list of NIS servers. The netmask number in these cases would have to be set appropriately.
How users and administrators perform lookups. A niscat table | grep name command uses far more server resources than does a nismatch name tablecommand.
The type of server. Newer, faster servers provide quicker, more efficient service than do older, slower machines. Thus, the more powerful your servers, the fewer of them you need.
Number of clients. The more clients you have in a domain, the more replica servers you need. Try to keep fewer than 1000 clients in a domain. NIS+ clients present a higher load on servers than NIS clients. A large number of clients served by only a few servers can impact network performance.
Table 2-1 summarizes the peak number of busy clients that a set of servers can handle without any slowing of response time. In the benchmark tests that produced these results, the clients were designed to make intensive use of NIS+ services. Each client made many NIS+ calls to simulate a peak load, rather than the average load experienced by normal production domains. Thus, the numbers shown in Table 2-1 illustrate configurations designed to meet peak load (as opposed to average load) without any slowing of response time.Table 2-1 Server Configurations and Number of NIS+ Clients
Server and Replica Configuration
Peak Number of "Busy" Clients
|Master: SS5-110 Replica: SS10-40||220|
|Master: SS5-110 Replica: SS10-40 Replica: SS20-50||580|
|Master: Ultra-167 Replica: SS10-40||840|
These numbers indicate that if your clients make extensive use of NIS+ services, you should add an extra replica for approximately every 100-400 clients. If your replicas are SS5s, you should add a new replica for every 100 clients; if your replicas are Ultras, you should add a new replica for every 400 clients. You should adjust these figures according to your needs.
One way you can have a sufficient number of replicas per domain without using a multiplicity of machines is to create multihomed servers. A multihomed server is a machine with multiple ethernet or network interfaces. A multihomed server can serve multiple subnets in a domain. (While it is possible to have a master or replica serve multiple domains, that is not recommended.)