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.
We are currently focussing on better response to netgroup queries.
-Devi Netapp Engineering.
-----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Tuesday, March 28, 2000 1:34 AM To: Bond, Andrew; Timothy Demarest Cc: toasters@mathworks.com Subject: Re: NIS and netgroup file
The filer does not copy the NIS maps into /etc. NIS group information is cached, but otherwise the filer acts as a NIS client only, and will query
the
NIS server it has bound to ("nis info" will tell you which this is).
Is full server (non-master) functionality going to be included in the future? It would be very useful and would allow the filer to be more robust.
Bruce
----- 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
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
A lightweight slave implementation inside DOT would be a welcome feature.
Just as a brief information point, there is already some *partial* help here in Data ONTAP.
Specifically there are some new(ish) options that will make a filer aggressively cache UNIX group information obtained from an NIS server. The "nis.group_update.enable" controls whether the feature is switched on or not, and the "nis.group_update_schedule" specifies the times of day that refreshes are done. According to my documentation (the "Start Here" guide for Data ONTAP 5.3.5), the former option was new in version 5.3.5, and the latter in 5.3.4, which leads to a rather obvious question that I'll have to let Devi answer! :-)
While this is not exactly what is being requested on this thread, hopefully it demonstrates some good direction.
So why do this just for group information initially? The answer is a little involved, but it had to do with large (gazillion group) UNIX installations that use our CIFS implementation in a UNIX-centric manner.
Keith
Now, if you lost power and you are waiting on DNS and NIS servers to come back online, who is accessing your servers anyway?
-gdg
Bruce Sterling Woodcock wrote:
----- 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
-- --------------------------------------------------------------- G D Geen mailto:geen@ti.com Texas Instruments Phone : (972)480.7896 System Administrator FAX : (972)480.7676 --------------------------------------------------------------- Life is what happens while you're busy making other plans. -J. Lennon
We orignally used NIS for some time but we gave up because of various problems with the NetApp software, occasional network glitches and the chicken-and-egg problems when coming up after a power failure.
NetApp have probably fixed all the bugs by now, but it's a fairly trivial task to hack the Makefile on your NIS master so that it copies the passwd, group and netgroup files to all your filers whenever they have changed. This is funcionally very similar to having the filers act as their own slave server!
So here are my tips, some of them learned the hard way:
1) Avoid NIS and copy the NIS data to each filer
2) If you do use NIS, ensure that a local NIS server will still boot even if the filers are down. Care with the /etc/init.d files and use of the automounter will help here. The NIS data (eg on /var/yp) should be on a local disk even if the master files from which they are generated reside on a filer.
3) Ensure that your DNS servers will boot without the filers. Again it's a good idea for their DNS data to be on a local disk, regularly updated from a master copy on a filer.
-- Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin@york.ac.uk
Now, if you lost power and you are waiting on DNS and NIS servers to come back online, who is accessing your servers anyway?
The answer is in the message to which you were replying:
... 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.
The filer is trying to access the NIS server, in response to the NIS server's mount request (needed to access the NIS data).
This sort of power-up interdependency is a royal pain when managing a large installation. As Bruce notes, moving key data like DNS and NIS off the filer to local disk goes against the idea of having all of your data in a central, secure place.
Back when I was a customer of NetApp's, the way I solved the problem was to have the master data on NFS storage (we were just starting to buy filers when I left) but have slave/secondary servers which used local disk and which had no external dependencies for their core functions -- essentially, we turned SPARCservers into appliances for DNS, NIS, etc. If any of them roached their data, we could always bring the world up using other ones and then once the master was back rebuild the dead slave/secondary.
-- Karl
This sort of power-up interdependency is a royal pain when managing a large installation. As Bruce notes, moving key data like DNS and NIS off the filer to local disk goes against the idea of having all of your data in a central, secure place.
Right.
The very fact not everyone immediately sees the dependancy underlines my point. If Netapp wants to provide a simple, robust, reliable storage solution, that sometimes means including a few "auxilliary" services that may be required to perform this function. We don't want customers bitten by subtle bugs if it can be avoided, and NIS slave functionality is a small change purely for the filer's benefit; I'm not suggesting Netapp start making NIS appliances. :) (Although a DNS/NIS/WINS/LDAP/etc. appliance does have some appeal....)
Bruce
----- Original Message ----- From: "G D Geen" geen@msp.sc.ti.com To: toasters@mathworks.com Sent: Wednesday, March 29, 2000 6:37 AM Subject: Re: NIS and netgroup file
Now, if you lost power and you are waiting on DNS and NIS servers to come
back
online, who is accessing your servers anyway?
The NIS server is trying to access the filer for it's files, and the filer won't let it because it needs to talk to an NIS server for proper authorization. See Dave Atkin's email for a more details. (Yes, I know there are workarounds... as does Dave, who's obviously had experience in this area. :))
Bruce
-
Bruce Sterling Woodcock -
Dave Atkin -
G D Geen -
Jeff Krueger -
Keith Brown -
kls＠netapp.com -
Nagaraj, Devi