Edward Ned Harvey wrote:
>> From: Richard Chycoski [mailto:rskiad...@chycoski.com]
>>
>> AD has excellent failover characteristics - much better than NIS's
>> slave
>> server concept. You can have replicas all over the world, all
>> containing
>> the same data, and AD will manage replication and failover quite
>> transparently. And cached tables mean that even if the AD servers go
>> away for a while, you usually get no interruptions (except that you can
>> only log in to IDs that have have been logged into on that server
>> recently). It even works for laptops and other disconnected devices,
>> just like with a Windows device. If you have logged in to the domain
>> while connected, you can pull the machine off the net, take it
>> elsewhere, and you can still log into it. NIS - if you lose contact for
>> more than three seconds at a critical time, the transaction will fail
>> and your calling process will usually abort.
>>
>
> While I agree AD has excellent failover characteristics, and I also agree
> that NIS is not quite as good as AD in this regard, I would say that NIS has
> excellent failover characteristics as well. Just not quite as good as AD.
>
> Every NIS client has a list of servers, which you may populate manually or
> automatically. During startup, and at regular intervals, it essentially
> ping's each one, and makes the default server whichever one is responding
> the fastest. If any one server is not responding, then it triggers another
> ping scan, and repeats the query to whichever server is able to respond.
>
> The failure of NIS happens when your client is removed from the network, or
> *all* of the servers are removed.
>
If the server that is currently pointed at fails, NIS takes too long to
fail over to a new server. NFS mounts can be refused when this happens
(and a netgroup is being used to control a mount). (I've had this issue
with NIS clients that were bound to NIS+ servers. NIS+ was originally
single-threaded, and would cause NIS clients to fail over to another
server rather frequently.) It's the client end that isn't quick enough
about failover. It waits for TCP to time out, which is far too long. NIS
uses nscd for caching, which doesn't retain much data, so most mount
requests require at least one NIS query. A caching AD client can be
configured to retain entire maps, which can mean that you almost never
need to do a NIS query at a critical time, the cache is essentially
maintained in the background. This has a two-pronged advantage over NIS
- high reliability, and virtually instantaneous lookups.
> The only reason I would say this failover isn't as good as AD failover is:
> Because in AD there are no mater/slaves. They're all equally authoritative,
> and replication is automatic. In NIS, when you update something, you have
> to update the master and push down to the slaves.
>
The multi-master AD architecture is only one part of it - AD clients
switch servers faster than NIS clients when a server becomes unavailable
for any reason. The extra caching on the client further enhances
resiliency and response time. There's nothing stopping anyone from
building a caching NIS client, which would erase much of this advantage,
but I've yet to see a caching NIS client. AD caching reduces the amount
of network traffic by using doing smart requests that only ask for the
deltas since the last time the cache was updated - NIS doesn't have this
mechanism available, so caching could cause network storms if too many
clients updated at the same time, and hence is not as scalable a
solution with NIS.
> >From an administrator's perspective, I think AD is better for failovers.
> >From a client perspective, unless you are talking about a laptop which will
> leave the network, I think they're both equal.
>
- Richard
_______________________________________________
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
