Jeff/Bruce,

Your input is very valuable. We will take into account your suggestion while we improve the NIS services on the filer for the next release.

Jeff - instead of binding using broadcast, you can secify the NIS servers you want to bind to in the order of preference. This will make sure that the same NIS server is not bombarded by all the filers.

-Devi

-----Original Message----- From: Jeff Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, March 28, 2000 4:00 PM To: Bruce Sterling Woodcock Cc: Nagaraj, Devi; Bond, Andrew; Timothy Demarest; toasters@mathworks.com Subject: Re: NIS and netgroup file

We are in full accord with Bruce's comments below. Although recent enhancements to the NIS client have made it speedier and more robust, loss of communications with a NIS slave has consistently been one of our largest causes for NetApp services outages. Additionally, binding several NetApps to the same slave places tremendous strain on that slave due to continual hammering by the filers.

A lightweight slave implementation inside DOT would be a welcome feature. As Bruce mentioned, it need not provide maps to other machines, but only for its own purposes. This would reduce network traffic and strain on existing boxes, free up an external dependency, and likely improve the speed of authentication which may make the filer run faster overall.

As a side-note, our old Auspex ran a NIS slave for the same basic reason although it was horrible for machines to bind to. In broadcast mode, we found that our NetApps *loved* binding to it among the multitude of other slaves on that particular subnet. =)

-- Jeff

-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com

From "Bruce Sterling Woodcock" on Tue, 28 Mar 2000 14:10:10 PST:

----- Original Message ----- From: Nagaraj, Devi devi.nagaraj@netapp.com To: 'Bruce Sterling Woodcock' sirbruce@ix.netcom.com; Bond, Andrew abond@netapp.com; Timothy Demarest demarest@arraycomm.com Cc: toasters@mathworks.com Sent: Tuesday, March 28, 2000 9:15 AM Subject: RE: NIS and netgroup file

...

We are looking into ways of improving the NIS implementation to be more efficient. We are not planning on implementing the slave functionality on the filer though.

That's too bad, because it essentially makes a network less robust. See, if you rely on NIS files so you don't have to copy files to the filer locally, then lets say you have a power outage. The filer comes up and then can't do anything because it's waiting to talk to the NIS server (it's probably the DNS server too). The NIS server can't do anything because it's waiting to mount the filer. Stalemate. There are ways around this, like having your NIS/DNS server hold the data on a local disk, but then you have a kink in your whole centralized network storage scheme. Altenatively, you can copy everything to the filer, but then you've defeated the whole purpose of NIS.

Making filers slave servers is an ideal solution. You don't have to allow other clients to bind to them, but this way they can get data updated from a master and still have a local copy in the event of network problems.

Bruce