I have a netapp with several shelves that is going to have to be moved. Various servers have NFS mounts from it. What is the proper procedure to shut it down and start it up? I would guess shutting down the servers before the netapp and then the otherway when starting it up would make sense… what about the netapp itself?
Proper Steps to Shutdown NetApp FAS 3020 with Shelves
netapp
Related Solutions
So you do not have a server IP listed. Thus it is trying to use the DNS RR record for the domain name. Is that available? It should have a _msdcs.domain.com entry that somewhere in there lists of the IP address of all the Domain Controllers in the domain. Sounds like the second and thrid error line are pointing that out.
My guess is that the Could not get passwd entry for name = <random user> error is a cascade from that previous error.
Adding the noac nfs mount option in fstab was the silver bullet. The total throughput has not changed and is still around 100 MB/s, but my read and writes are much more balanced now, which I have to imagine will bode well for Postgres and other applications.
You can see I marked the various "block" sizes I used when testing, i.e. the rsize/wsize buffer size mount options. I found that an 8k size had the best throughput for the dd tests, surprisingly.
These are the nfs mounts options I'm now using, per /proc/mounts:
nfsc:/vol/pg003 /mnt/peppershare nfs rw,sync,noatime,nodiratime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0
FYI, the noac option man entry:
ac / noac
Selects whether the client may cache file attributes. If neither option is specified (or if ac is specified), the client caches file attributes.
To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server's version of each file's attributes for updates. Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.
In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately. That way, other clients can quickly detect recent writes when they check the file's attributes.
Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.
I read mixed opinions on attribute caching around the web, so my only thought is that its an option that is necessary or plays well with a NetApp NFS server and/or Linux clients with newer kernels (>2.6.5). We didn't see this issue on SLES 9 which has a 2.6.5 kernel.
I also read mixed opinions on rsize/wise, and usually you take the default, which currently for my systems is 65536, but 8192 gave me the best tests results. We'll be doing some benchmarks with postgres too, so we'll see how these various buffer sizes fare.
Best Answer
As far as the filer itself, "halt" from the CLI is pretty much all you need to know. (You'd obviously want be sure that no servers are using it). Power off the head, then the shelves, and do in reverse after you've moved.
http://now.netapp.com has some valuable best-practice guides for this sort of scenario - as an aside, if you're physically moving the netapp, it would be very wise to make sure that your netapp support is current.