- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
NIS High Availability Architecture Features
The main high availability feature of NIS is master-slave data replication. All updates are performed on the master, then propagated to the slaves. If one of the NIS servers fails, an NIS client can bind to another one. However, if the master NIS fails, no updates can occur until it comes back online or another NIS master is created. This may seem like a severe restriction, but in practice the information stored in NIS maps is relatively static, so a few hours of downtime is usually acceptable.
How the NIS client handles the failover from one NIS server to another is determined by the method it uses to bind to its NIS server. FIGURE 2-4 and FIGURE 2-5 illustrate how NIS client failover is handled with both the Broadcast and Specified Server methods.
){kind=link}
){kind=link}
FIGURE 2-4 NIS Client Failover with the Broadcast Method
FIGURE 2-5 NIS Client Failover with the Specified Server Method
In the Broadcast method, the NIS client sends out a broadcast to locate an NIS server in the domain of which it is a member. The client then binds to the first server that responds to the broadcast. If the NIS server to which the NIS client binds to fails, then the next time an NIS look up is performed, the operation will time out and the client will issue another ypbind broadcast.
In the Specified Server method, the NIS client maintains a list of potential NIS servers. When the client boots, it attempts to bind to the first server in the list. If that server is unavailable, then the client attempts to bind to the next server in the list and so on. The downside of this method is that the time-out period can be lengthy, which gives the impression that the service is down.
A form of load balancing can be achieved with the Broadcast method since the least busy NIS server will respond to the clients ypbind request. The disadvantage is that multiple NIS servers must reside on each subnet.