Hi List,
I don't own a Netapp, but joined this list a couple weeks ago when we decided to take a closer look at and possibly eval one. I must say it's refreshing to see a list where the vendor allows their people to help out.
The comment below by Oliver gets to my biggest concern: remote support. I've made very clear to the sales and tech reps that my biggest concerns with a netapp (or anything I would purchase) is remote support. I would need to put netapps at remote sites locked in phone closets with our other networking equipment and servers. Everything is interconnected by a wan and support would be by myself from a central, but remote site.
May I ask a couple of question?
1) How effectively can you support a netapp from a remote site?
2) I would be interested in hearing from anyone using a netapp for a oracle database on rs/6k computers.
Thanks
Rick
On 22 Apr 99, at 12:49, Oliver Krause wrote:
Hello Brian,
also from me a big thank you for this feature. Without it remote support would be very hard. And a command to change to firmware variables from a running system would be really valuable.
Oliver
---------------------------------------------------------------------- Richard L. Rhodes e: rhodesr@firstenergycorp.com Ohio Edison Co. p: 330-384-4904 f: 330-384-2514
Richard,
I have been supporting NAC boxes for about 4 years now starting with the NFAS-1300 and working my way up to several F760 cluster pairs. Other than hardware problems, such as replacing a bad disk drive, I never need to enter the data centre. I telnet into the box to perform most of my administration. I have the option on the "Lightwave" terminal servers to add remote connectivity so that it would look like I was at the console from home. I have not needed that type of capability.
I can see the need for the remote capability in rare instances, especially for remote site administration like you are doing. Through remote connectivity of the "Lightwave" term server, I am local to the filer not remote. NAC will ship replacement parts anywhere you want them to. If you want the replacement drive at the remote site, then that is where it will go. If you want it in your hot hands and deliver it to your remote site yourself, then they will do that as well. Overall, I am very happy with the support staff at NetApp.
If you have problems with support, bring it to the attention of your Sales Advisor. NetApp is very good about communicating internally the issues of their customers. Also some very heavy hitters at NetApp read this mail list. So use this forum to address your concerns. Please note, NetApp is not the only provider of network filers out there. If you are not happy, ask Auspex why they don't have a mail list like this. I did and was surprised by the answer. I have not asked EMC about a mail list yet, but I am interested in hearing the answer.
BTW, if you remove the terminal and plug it back in later, it does not bring *my* filers down. I do this all the time when I am configuring a new system pair. My SE usually brings his laptop and we use that as our terminal.
Well, enough of the sales pitch. I have administrative work to do and NetApp is not paying me enough. :)
-gdg
Richard L. Rhodes wrote:
The comment below by Oliver gets to my biggest concern: remote support. I've made very clear to the sales and tech reps that my biggest concerns with a netapp (or anything I would purchase) is remote support. I would need to put netapps at remote sites locked in phone closets with our other networking equipment and servers. Everything is interconnected by a wan and support would be by myself from a central, but remote site.
May I ask a couple of question?
How effectively can you support a netapp from a remote site?
I would be interested in hearing from anyone using a netapp for a
oracle database on rs/6k computers.
Thanks
Rick
On Fri, 23 Apr 1999, G D Geen wrote:
BTW, if you remove the terminal and plug it back in later, it does not bring *my* filers down.
Right, because you can't halt a filer by sending it a break. I would like to be able to enable this feature by setting some OpenBoot variable, which can (and probably should) be disabled by default.
Tom
Remote work is complicated mostly for me by the two floppy OS. It is a real pain to walk across the street to change floppies.
And BTW; can Network Appliance make the filer capable of formating and downloading the OS onto its own floppy?
At 11:38 AM -0500 4/23/99, tkaczma@gryf.net wrote:
On Fri, 23 Apr 1999, G D Geen wrote:
BTW, if you remove the terminal and plug it back in later, it does not bring *my* filers down.
Right, because you can't halt a filer by sending it a break. I would like to be able to enable this feature by setting some OpenBoot variable, which can (and probably should) be disabled by default.
Tom
}}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov (925) 422-4018 Page: 423-7705x57152
On Fri, 23 Apr 1999, Jim Harm wrote:
Remote work is complicated mostly for me by the two floppy OS. It is a real pain to walk across the street to change floppies.
That's why you boot it off the net from the comfort of your desk or home.
And BTW; can Network Appliance make the filer capable of formating and downloading the OS onto its own floppy?
Why would you need this?
Tom
Going there once is ok, when you only have to boot once on floppies. When trouble shooting a problem with NetApp support, and booting off a test OS repeatedly and having to return to my office where the computer is and 'ftp'ing core dumps and rebooting the same test OS To try another command from NetApp support and core dumping again and waiting four hours for wack to complete in a freezing machine room and ... Remote work means a little more than boot once off the floppy device. Of course, this may actually be partly a support issue.
At 4:27 PM -0500 4/23/99, tkaczma@gryf.net wrote:
On Fri, 23 Apr 1999, Jim Harm wrote:
Remote work is complicated mostly for me by the two floppy OS. It is a real pain to walk across the street to change floppies.
That's why you boot it off the net from the comfort of your desk or home.
Enlighten me, please. How do I boot off the net to an OS? You may mean to install the new OS onto the disk and reboot on that OS. But my experience was that support recommended a test OS that was not to be installed on the system by direction of the NetApp support, and had no back out assurance/experience, and in fact kept crashing so I am glad I didn't install it on the disks. If you mean the bootp protocol, I had not thought of that; is that a recommended/available boot procedure for NetApp boxes? Maybe I just didn't notice the OS download procedure for the bootp server and setup procedure for the bootp proctocol. Well, I am not sure I would want to set it up to boot that way all the time anyway.
And BTW; can Network Appliance make the filer capable of formating and downloading the OS onto its own floppy?
Why would you need this?
System administrators sometimes use different machines. One procedure for floppy download and copy to disk is easier than one for each of AIX, Solaris, Compaq, HP, ... It would be easier to explain to the on-site admin than to see which system they have access to and then try to remember the procedure for that particular OS/Machine.
Tom
}}}===============>> LLNL James E. Harm (Jim); jharm@llnl.gov (925) 422-4018 Page: 423-7705x57152
On Fri, 23 Apr 1999, Jim Harm wrote:
When trouble shooting a problem with NetApp support, and booting off a test OS repeatedly and having to return to my office where the computer is and 'ftp'ing core dumps and rebooting the same test OS
Tell me about this. I had a faulty LRC in the bottom shelf. Apparently the only way to test it is to floppy boot the damn thing slowly connecting shelf after shelf until you can't see the drives anymore.
Tom
tkaczma@gryf.net writes:
On Fri, 23 Apr 1999, G D Geen wrote:
BTW, if you remove the terminal and plug it back in later, it does not bring *my* filers down.
Right, because you can't halt a filer by sending it a break. I would like to be able to enable this feature by setting some OpenBoot variable, which can (and probably should) be disabled by default.
[I don't generally like `me too' posts, but...]
I fully agree with Tom, in that the NetApps should support `BREAK drops to ok prompt', but it should be off by default. This won't break things for existing setups but give some of us needed flexibility.
"Richard L. Rhodes" wrote:
- I would be interested in hearing from anyone using a netapp for a
oracle database on rs/6k computers.
We haven't been running at remote sites, but we have been running oracle on a Sun server and using nfs mounted file systems. I am not the oracle dba, but we haven't had any complaints from our users. We made sure that only data tablespaces were on the netapp and all the logging was done on files systems local to the oracle server. I would even go so far as to keep index tablespaces local too.
JT
On Fri, 23 Apr 1999, Richard L. Rhodes wrote:
- How effectively can you support a netapp from a remote site?
If NAC would provide us with a "break" from console to get into the "ok" prompt, you could do everything short of replacing hardware, upgrading firmware (this could be changed by NAC easily), or pushing the on/off button (although the latter could be emulated with the use of a remote switch). You CAN boot the NAC from the network (a lot faster than from floppies) as long as you have something serving rarp and bootparams and/or tftp on that subnet.
So come on guys, since this is a NETWORK appliance, why can't we halt the thing from the network?
Tom
Dear Tom,
After much discussion, we've decided not to change the current behavior of the system. We don't believe the potential cost of recognizing "breaks" outweighs the benefits.
But we do recognize there are benefits. Here in NetApp Engineering, we put machines on remote power strips, so if a filer really isn't responding to the console at all we can yank its power. As others have noted, you can interrupt a boot sequence in the firmware by typing <del> during the POST and initialization sequence; you get a nice pliable ok prompt. The combination of terminal servers and remote-controlled power strips gives us enough functionality that we don't notice the lack of <break>. And yes, we're sensitive to the issues of remote administration because that bites us too: I'd much rather develop and test in my office, with my coffee warmer and my headphones, than up in a crowded, chilly, noisy lab.
Regarding net booting: we've had issues with functionality, testing and documentation, and it's never been a high enough priority to steal resources from other projects. But we've started drafting requirements for formally supporting net booting in the future, and I believe we will eventually officially document its use. I can't tell you when because I honestly don't know.
Yours, Mike Tuciarone Platform Software
On Fri, 23 Apr 1999, Michael J. Tuciarone wrote:
As others have noted, you can interrupt a boot sequence in the firmware by typing <del> during the POST and initialization sequence; you get a nice pliable ok prompt.
This technique should be sufficient for most of my needs. Thank you for responding. I will test it out at the next opportunity. NAC number 1x should be going up by the end of the first week of May given that the blessed gods of networking provide me some connections on time.
Regarding net booting: we've had issues with functionality, testing and documentation, and it's never been a high enough priority to steal resources from other projects.
It appears to work whether it is officially supported or not. That also meets most of my requirements.
Although I wish that the two issues above would be supported and documented so that others can benefit from them, my immediate needs are mostly met.
Thanks Tom
-
G D Geen -
Jim Harm -
John Tatar -
Luke Mewburn -
Michael J. Tuciarone -
Richard L. Rhodes -
tkaczma＠gryf.net