Determining Server Requirements

Each NIS+ domain is supported by a set of NIS+ servers. Each set contains one master and one or more replica servers. These servers store the domain's directories, groups, and tables, and answer requests for access from users, administrators, and applications. Each domain is supported by only one set of servers. While a single set of servers can support more than one domain, this is not recommended.

The NIS+ service requires you to assign at least one server, the master, to each NIS+ domain. How many replica servers a domain requires is determined by the traffic load, the network configuration, and whether NIS clients are present. The amount of server memory, disk storage, and processor speed is determined by the number of clients and the traffic load they place on the servers.

Any machine, running in the Solaris operating environment, can be an NIS+ server, as long as it has its own hard disk of sufficient size. The software for both NIS+ servers and clients is included in the Solaris product. Therefore, any machine that has the Solaris operating environment installed can become a server or a client, or both.

When determining what servers are needed to support your NIS+ namespace, consider these factors, discussed in the following sections.

Number of Supported Domains

To begin, you assign one master server to each domain in the hierarchy.The following figure shows one possible assignment.

Figure 26–6 Assigning Servers to Domains

Add one or more replicas to each domain. Replicas allow requests to be answered even if the master server is temporarily out of service. (See Number of Replica Servers for information on how many replicas to use.)

Figure 26–7 Adding Replicas to a Domain

Number of Replica Servers

The optimum number of servers (master plus replicas) for a domain is determined by a number of factors:

• NIS+ master servers require fewer replicas than NIS servers, since NIS+ does not depend on broadcasts on the local subnet.

• Every domain should have at least one replica server so that NIS+ service is not disrupted when the master server is temporarily unavailable.

• No domain should have more than 10 replicas. This is because of the increased network traffic and server load when information updates are propagated to many replicas.

• The type of clients. Older, slower client machines 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.

  The table below 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 in the table below, illustrate configurations designed to meet peak load (as opposed to average load) without any slowing of response time.

  Table 26–1 Server Configurations and Number of NIS+ Clients

  Server and Replica Configuration	Peak Number of "Busy" Clients
  Master: SS5-110	120
  Master: SS5-110 Replica: SS10-40	220
  Master: SS5-110 Replica: SS10-40 Replica: SS20-50	580
  Master: Ultra-167	420
  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.)

Server Speed

The faster the server, the better NIS+ performs. (However, at this time NIS+ servers cannot take advantage of SMP multithreaded hardware.) Your NIS+ servers should be as powerful, or more powerful, than your average client. Using older machines as servers for newer clients is not recommended.

In addition to server speed, many other factors affect NIS+ performance. The numbers and kinds of users and hosts, the kinds of applications being run, network topology, load densities, and other factors, all affect NIS+ performance. Thus, no two networks can expect identical performance from the same server hardware.

The benchmark figures presented in the table below, are for comparison purposes only; performance on your network may vary. These benchmark figures are based on a test network with typical table sizes of 10,000 entries.

Table 26–2 Hardware Speed Comparison NIS+ Operations

Machine	Number of Match Operations Per Second	Number of Add Operations Per Second
SS5-110	400	6
SS20-50	440	6
PPro-200	760	13
Ultra-167	800	11
Ultra-200	1270	8

Server Memory Requirements

Although 32 Mbytes is the absolute minimum memory requirement for servers, it is better to equip servers of medium-to-large domains with at least 64 Mbytes.

Ideally, an NIS+ server should have enough memory to hold all the entries of all the searchable columns of all the operative NIS+ tables in RAM at one time. In other words, optimal server memory is equal to the total memory requirements of all the NIS+ tables.

For illustration purposes, the table below shows memory requirements for the netgroup table with five searchable columns, and Table 26–4 shows the approximate memory requirements for the passwd, t, and cred tables.

Table 26–3 Server Memory Required for netgroups Table

Number of Entries	Server Memory Usage in Mbytes
6,000	4.2
60,000	39.1
120,000	78.1
180,000	117.9
240,000	156.7
300,000	199.2

Table 26–4 Approximate Memory Required for passwd Table

Number of Entries	Server Memory Usage in Mbytes
6,000	3.7
60,000	31.7
120,000	63.2
180,000	94.9
240,000	125.8
300,000	159.0
1,000,000	526.2

For the other tables, you can estimate the memory size by multiplying the estimated number of entries times the average number of bytes per entry for each searchable column. For example, suppose you have a table with 10,000 entries and two searchable columns. The average number of bytes per entry in the first column is 9, the average number of bytes per entry in the second column is 37. Your calculation is: (10,000x9)+(10,000x37)=460,000.

---

Note –

When estimating the number of entries in the cred table, keep in mind that every user will have two entries (one for the user's Local credential and one for the user's DES credential). Each machine will have only one entry.

---

See NIS+ Standard Tables for the number of searchable columns in each of the standard NIS+ tables.

Server Disk Space Requirements

How much disk space you need depends on four factors:

• Disk space consumed by the Solaris operating environment.

• Disk space for /var/nis (and /var/yp if using NIS compatibility).

• Amount of server memory.

• Swap space required for NIS+ server processes.

The Solaris operating environment can require over 220 Mbytes of disk space, depending on how much of it you install. For exact numbers, see your Solaris installation guides. You should also count the disk space consumed by other software the server might use. The NIS+ software itself is part of the Solaris operating environment distribution, so it does not consume additional disk space.

NIS+ directories, groups, tables, and client information are stored in /var/nis. The /var/nis directory uses about 5 Kbytes of disk space per client. For example purposes only, if a namespace has 1000 clients, /var/nis requires about 5 Mbytes of disk space. However, because transaction logs (also kept in /var/nis) can grow large, you may want additional space per client—an additional 10–15 Mbytes is recommended. In other words, for 1000 clients, allocate 15 to 20 Mbytes for /var/nis. You can reduce this if you checkpoint transaction logs regularly. You should also create a separate partition for /var/nis. This separate partition will help during an operating system upgrade.

If you will use NIS+ concurrently with NIS, allocate space equal to the amount you are allocating to /var/nis for /var/yp to hold the NIS maps that you transfer from NIS.

You also need swap space equal to twice the size of rpc.nisd—in addition to the server's normal swap space requirements. To see the amount of memory being used by rpc.nisd on your system, run the nisstat command. See the rpc.nisd man page for more information. Most of this space is used during callback operations or when directories are checkpointed (with nisping -C) or replicated, because during such procedures, an entire NIS+ server process is forked. In no case should you use less than 64 Mbytes of swap space.