Remember that a domain is not an object, but a reference to a collection of objects. Therefore, a server that supports a domain is not actually associated with the domain but with the domain's directories. A domain consists of four directories: domain, ctx_dir.domain, org_dir.domain, and groups_dir.domain, as shown below.
Figure 26-3 Server Relationship to Domain
Organizational or Geographical Mapping
One of the major benefits of NIS+ is its capability of dividing the namespace into smaller, more manageable parts. You could create a hierarchy of organizations, such as those of the hypothetical corporation, Doc Inc., as shown below.
Figure 26-4 Sample NIS+ Hierarchy by Logical Organization
You could also organize the hierarchy by buildings instead of organizations, as shown below.
Figure 26-5 Sample NIS+ Hierarchy by Physical Location
The scheme you select depends primarily on how you prefer to administer the namespace and how clients will tend to use the namespace. For example, if clients of factory.com. will be distributed throughout the buildings of Doc Inc., you should not organize the namespace by building. Because the clients constantly need to have access to other domains, you need to add their credentials to the other domains and you increase traffic flow through the root master server. A better scheme would be to arrange clients by organization. On the other hand, building-sized domains are immune to the reorganizations that require organization-based domains to be restructured.
Do not be limited by the physical layout of the network; an NIS+ namespace does not have to be congruent with the physical network, except where it has to support NIS clients. The number of domains your namespace needs depends on the kind of hierarchy you select.
Consider future expansion plans. Will today's NIS+ root domain be beneath another NIS+ domain in the future? Changing this arrangement would entail a great deal of work. Try to estimate the need for future domains in the namespace and design a structure that can accommodate them without disruption.
Connection to Higher Domains?
Consider whether the NIS+ namespace will be connected to higher domains, such as those of the Internet or DNS. If you currently use NIS under a DNS hierarchy, do you want to replace only the NIS domains or do you want to replace the entire company-wide DNS/NIS structure with an NIS+ namespace?
Client Support in the Root Domain
In the two Doc Inc., domain hierarchies illustrated in Figure 26-4 and Figure 26-5, are all the clients placed in domains beneath the root domain? Or do some belong to the root domain? Is the purpose of the root domain to act only as the root for its subdomains, or will it support its own group of clients? You could place all clients in the lowest layer of domains, and only those used for administration in the root and any intermediate domains. For example, if you implemented the plan in Figure 26-4, all clients would belong to the big.sales.com., small.sales.com., and factory.com. domains, and only clients used for administration would belong to the .com. and sales.com. domains.
Or you could place the clients of general-purpose departments in higher-level domains. For example, in Figure 26-5, where the domain is organized by building, you could put the clients of the Facilities Department in the .com. domain. It is not recommended that you do so, however, because the root domain should be kept simple and relatively unpopulated.
Domain Size Compared With Number of Domains
The current NIS+ implementation is optimized for up to 1000 NIS+ clients per domain and for up to 10 replicas per domain. Such a domain would typically have 10,000 table entries. The limitations come from the current server discovery protocol. If you have more than 1000 NIS+ clients, you should divide your namespace into different domains and create a hierarchy.
Creating a hierarchy, however, may introduce more complexity than you are prepared to handle. You may still prefer to create larger domains rather than a hierarchy; because one large domain requires less administration than multiple smaller domains. Larger domains need fewer skilled administrators to service them, since tasks can be automated more readily (with scripts you create), thus lowering the administrative expense. Smaller domains provide better performance, and you can customize their tables more easily. You also achieve greater administrative flexibility with smaller domains.
Number of Levels
NIS+ was designed to handle multiple levels of domains. Although the software can accommodate almost any number of levels, a hierarchy with too many levels is difficult to administer. For example, the names of objects can become long and unwieldy. Consider 20 to be the limit for the number of subdomains for any one domain and limit the levels of the NIS+ hierarchy to 5.
Security Level
Typically, you will run the namespace at security level 2. However, if you plan to use different security levels for different domains, you should identify them now. "Understanding the Impact of NIS+ Security" provides more information about security levels.
Domains Across Time Zones
Geographically-dispersed organizations may determine that organizing their domain hierarchy by functional groups causes a domain to span more than one time zone. It is strongly recommended that you do not have domains that span multiple time zones. If you do need to configure a domain across time zones, be aware that a replica's time is taken from the master server, so the database updates will be synchronized properly, using Greenwich mean time (GMT). This may cause problems if the replica machine is used for other services that are time critical. To make domains across time zones work, the replica's /etc/TIMEZONE file has to be set locally to the master server's time zone when you are installing NIS+. After the replica is running, some time-critical programs may run properly and some may not, depending on whether these programs use universal or local time.
Information Management
It is best to use a model of local administration within centralized constraints for managing the information in an NIS+ namespace. Information should be managed, as much as possible, from within its home domain, but according to guidelines or policies set at the global namespace level. This provides the greatest degree of domain independence while maintaining consistency across domains.
Domain Names
Consider name length and complexity. First, choose names that are descriptive. For example, "Sales" is considerably more descriptive than "BW23A." Second, choose short names. To make your administrative work easier, avoid long names such as administration_services.corporate_headquarters.doc.com.
A domain name is formed from left to right, starting with the local domain and ending with the root domain. The root domain must always have at least two labels and must end in a dot. The second label can be an Internet domain name, such as "com."
Also consider implications of particular names for email domains, both within the company and over the Internet.
Depending on the migration strategy, a viable alternative is to change domain names on NIS to the desired structure, then migrate to NIS+ domain by domain.
Email Environment
Because NIS+ can have a domain hierarchy while NIS has a flat domain space, changing to NIS+ can have effects on your mail environment. With NIS, only one mail host is required. If you use a domain hierarchy for NIS+, you may need one mail host for each domain in the namespace because names in separate domains may be no longer unique.
Therefore, the email addresses of clients who are not in the root domain may change. As a general rule, client email addresses can change when domain names change or when new levels are added to the hierarchy.
In earlier Solaris releases, these changes required a great deal of work. This release provided several sendmail enhancements to make the task easier. In addition, NIS+ provides a sendmailvars table. The sendmail program first looks at the sendmailvars table (see Figure 26-7, then examines the local sendmail.cf file.
Note - Be sure that mail servers reside in the NIS+ domain whose clients they support. For performance reasons, do not use paths to direct mail servers to tables in other domains.
Consider the impact of the new mail addresses on DNS. You may need to adjust the DNS MX records.
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.