- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
- NIS+ Architecture Overview
- NIS+ Client Server Architecture
- How NIS+ Clients Bind to the NIS+ Server
- NIS+ Tables
- NIS+ Interaction with DNS
- NIS+ High Availability Architecture Features
- Solaris DNS Architecture Overview
- DNS Client Architecture
- DNS Server Architecture
- DNS High Availability Features
- LDAP Architecture Overview
- LDAP Information Model
- LDAP Naming Model
- LDAP Functional Model
- LDAP Security Model
- LDAP Replication
- Comparison with Legacy Naming Services
NIS+ Client Server Architecture
The architecture of NIS+ is similar to that of NIS in that both naming services employ a master server, in which updates are made, and slave servers or replicas, in which a mirror of the data contained on the master is maintained. However, the similarity ends there.
NIS+ supports two types of masters:
- Root domain master
- Subdomain master
The root master, as the name suggests, acts as the top node in the hierarchal tree. Below the root masters are subdomain masters with other subdomain masters below them. At each level, replica servers can exist to provide redundancy for that section of the tree.
NOTE
An interesting feature of NIS+ is that the subdomain master is actually a client to the master above it, with the exception of the root master. The ramification of this is that NIS+ must be deployed in a top-down fashion since the domain above it must be configured before a subdomain master is configured.
Propagation of changes from master to replicas is different from NIS. Instead of pushing an entire map when changes are made, NIS+ propagates only the incremental changes. FIGURE 2-6 shows the NIS+ architecture.
FIGURE 2-6 NIS+ Architecture