toasters May 2005

toasters@lists.teaparty.net

61 participants
76 discussions

R100 with 256 meg cf card
by George, Andrew 01 Mar '06

01 Mar '06

I've tried to upgrade two r100's from 32 meg CF cards to 256 meg CF cards (so we can have a backup boot image with OnTap 6.5) On both occasions it's pretty much choked as soon as it's tried to see the 256 meg card and we've had to do some messing around to get a single image onto the card I'm beginning to think that an R100 running 6.4.x just can't see a 256meg cf card correctly and was wondering if anyone else has had a problem doing this? Andrew

3 2

RE: IPsec NFS to Unix clients
by Muhlestein, Mark 17 Jun '05

17 Jun '05

Gee, 30,000 * 300 is not even 10 million entries! :-) Yes, you are right that this isn't going to work in every case. But I wanted to mention it because it is useful in some situations. As to the MultiStore comment I made, I was thinking of a case where you want to use the same physical filer to serve an unprotected network (such as your normal campus network, it sounds like) and also serve a trusted network (on a different NIC or VLAN, say). As long as there is no way to access a vfiler's IP address using a client on the untrusted network, the vfiler boundary checks will prevent all access from all protocols (including NFS handle spoofing) coming from those untrusted clients. Mark -----Original Message----- From: Brian Parent [mailto:bparent@calvin.ucsd.edu] Sent: Friday, August 20, 2004 2:41 PM To: toasters(a)mathworks.com Subject: Re: IPsec NFS to Unix clients Thanks Mark. We do have CIFS. However, we have >30,000 accounts, and >300 NFS clients. And besides, any account is allowed access from any NFS client. Plus, it doesn't solve the problem of spoofing IPs. We don't have MultiStore, but even if we did, I don't see how it solves the problem of spoofing IPs. Spoofing IPs is painfully simple here, (as at most Universities, I would think) where labs aren't supervised, and network jacks are not physically secured. Re: > Subject: RE: IPsec NFS to Unix clients > Date: Fri, 20 Aug 2004 13:31:42 -0700 > From: "Muhlestein, Mark" <mark.muhlestein(a)netapp.com> > To: "Steve Losen" <scl(a)sasha.acc.virginia.edu>, > "Brian Parent" <bparent(a)calvin.ucsd.edu> > Cc: <toasters(a)mathworks.com> > > Here are a couple of other things you can do to improve NFS security: > > 1. If you have CIFS you might consider using the > nfs.require_valid_mapped_uid option. That allows you to set up the > usermap.cfg file to do things like this: > > # allow the following UIDs NFS access from the specified IP addresses > tom <= 192.168.3.34:tom > jerry <= jerrypc.dorm.foo.edu:jerry > jerry <= lab1.foo.edu:jerry > jerry <= lab2.foo.edu:jerry # etc. > > # allow root from the admin network > Administrator <= 10.10.20.0/24:root > > # prevent all other NFS access > "" <= * > > The nfs.require_valid_mapped_uid option causes the usermap.cfg entries > to be consulted even for access to data on qtrees with UNIX security. > Combined with the normal export controls, this approach works as long as > clients are not allowed to successfully spoof source IP addresses. It is > also more manageable if the number of combinations of users/hosts is not > overly large or dynamic; however I know we have had sites that have used > this type of approach with a script-generated usermap.cfg. > > 2. If you have MultiStore available you can also use that to fence off > NFS access. NFS clients accessing an IP address associated with a vfiler > are not allowed to access storage assigned to another vfiler. This is > enforced at the WAFL layer, so even if clients attempt handle spoofing > the access is denied as long as the potentially rogue clients are not > allowed to access the other vfilers' IP addresses (e.g. different > networks on separate NICs). > > Mark

2 2

RE: Non disruptive upgrade of FAS960c cluster
by Watanabe, Steve 31 May '05

31 May '05

> From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] > > We want to upgrade a FAS960c cluster from 7.0.0.1 to 7.0.1R1. > The cluster is only doing FC SAN, providing LUNs for our > central email servers, which are Suns running Solaris 8 and > Veritas volume manger and filesystem. Veritas is configured > to to multi-pathing. > > We do not want to schedule downtime for the email servers > whenever we upgrade the filers. I have been reading about > the "non disruptive" upgrade procedure where you install the > new system files, download, and instead of reboot, you "cf > takeover" one filer and "cf giveback", then do the same with > the other filer. > > Is this really significantly less disruptive than doing a > normal upgrade where you "cf disable" and then just reboot > both filers? Hi Steve, The non-disruptive upgrade (NDU) process is the same level of disruptiveness as a reboot (e.g. no disruption for NFS; connection lost for CIFS). The difference is that the length of time the filer isn't servicing the clients is shorter in the NDU case. The takeover time, while dependent on the load of the filers, is faster than a reboot which requires the filer to do POST, load the kernel, scan the Pci bus, init the adapters, init all the processes, etc. > > When you "cf takeover" the current SAN data path that the Sun > boxes are using to access some LUNs becomes unavailable, so > they must switch to an alternate data path through the > surviving filer. How long does this take and how disruptive > is it? Then when you "cf giveback", the Sun boxes need to > switch back to the original data path. If you simply reboot > both filers, then all of the LUNs are unavailable during the > reboot and come back after a minute or two. I've cc'd our FCP person for his answer to this but again the service "pause" is shorter for takeover/giveback then a reboot. > > Is it really less disruptive and "safer" to use the > takeover/giveback procedure in our situation? NDU is a tested, documented procedure. > > I am also concerned about the disk firmware upgrade that may > happen as part of an ONTAP upgrade. Is it better to upgrade > the disk FW before upgrading ONTAP, to make the ONTAP upgrade > as fast as possible? Yes, in fact the current recommendation is that you don't use NDU if you need a disk f/w upgrade and you have raid-4 aggregates. It is ok to use NDU if you use raid-dp or mirrored raid-4 aggregates. -Steve Watanabe NetApp Cluster Group > > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > University of Virginia ITC Unix Support > >

1 0

Non disruptive upgrade of FAS960c cluster
by Steve Losen 31 May '05

31 May '05

We want to upgrade a FAS960c cluster from 7.0.0.1 to 7.0.1R1. The cluster is only doing FC SAN, providing LUNs for our central email servers, which are Suns running Solaris 8 and Veritas volume manger and filesystem. Veritas is configured to to multi-pathing. We do not want to schedule downtime for the email servers whenever we upgrade the filers. I have been reading about the "non disruptive" upgrade procedure where you install the new system files, download, and instead of reboot, you "cf takeover" one filer and "cf giveback", then do the same with the other filer. Is this really significantly less disruptive than doing a normal upgrade where you "cf disable" and then just reboot both filers? When you "cf takeover" the current SAN data path that the Sun boxes are using to access some LUNs becomes unavailable, so they must switch to an alternate data path through the surviving filer. How long does this take and how disruptive is it? Then when you "cf giveback", the Sun boxes need to switch back to the original data path. If you simply reboot both filers, then all of the LUNs are unavailable during the reboot and come back after a minute or two. Is it really less disruptive and "safer" to use the takeover/giveback procedure in our situation? I am also concerned about the disk firmware upgrade that may happen as part of an ONTAP upgrade. Is it better to upgrade the disk FW before upgrading ONTAP, to make the ONTAP upgrade as fast as possible? Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

Snap restore hung...
by Mats.Oberg＠tietoenator.com 31 May '05

31 May '05

Hi, I was going to test snap restore the other day on one of our filers, it didn't work out the way I was hoping... Anyway, the problem was that the volume is snapmirrored to another filer and the "snap restore" told me that you can't restore on volumes that are snapmirrored. I didn't think that was a big problem until today I discovered that the snapmirroring stoped at around the time I tried the restore.. So now I have a volume that can't do snapshots anymore.. I couldn't even take the volume offline because the snap restore is still running (But restoring a single file shouldn't really take a week to complete, right?) Anybody know how to kill the snap restore?(or remove the lock/flag) I'd rather not reboot unless theres no other option. (the filer is a fas920 running 7.0.0.1p6 if thats any help...) / Mats

1 0

ISCSI boot problems.
by Jeff Mohler 28 May '05

28 May '05

Ive got the Qlogic 4010c card, and so far NO problems at all, except I cannot transfer an existing HDD partition to it, and boot from it. Ive created the LUN, windows mode, and using Ghost I can see it, and do a disk to disk transfer of the old C: drive to the LUN. Then it wont boot, I get the PC error that it cant find anything to boot from. The Qlogic card during boot sees the Lun, and there is even a few moments of activity to the LUN before the PC says it cant. Ive even re-ghosted with the 'copy boot sectors' option no to avail. I can start an XP install from the CD, using the driver floppy, and it will install files, and boot just fine, fast too I might say. If I let XP restart for the disk based install from the LUN, it runs fine, so I reboot again into ghost off a floppy, and go to Xfer the HDD image to the LUN. Same error as the first try..cant boot. Any idears?? I need to work up a plan to migrate from HDD to LUN, and it cant be a dynamic LUN either..so I cant do a simple mirror operation.

1 0

Qlogic 4010c Feedback
by Jeff Mohler 27 May '05

27 May '05

Other than I had up update the BIOS and Firmware to the latest levels (and that the BIOS in the card when I got it reported corrupted), I found the instasllation and configuration of booting via iscsi on the netapp to be pretty painless. Thumbs up from my end.

1 0

RE: amd / netapp issue?
by Leeds, Daniel 26 May '05

26 May '05

hrm, i am also seeing odd cpu issues with 7.0.0.1 on some new deployments. with only a few systems we are constantly over 75% cpu and alot of times well into the 90's steadily on cpu usage. i havnt seen anything related on NOW yet. -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of Langborg Tom Sent: Thu 5/26/2005 6:10 AM To: 'Jay(a)Williamsons.org'; toasters(a)mathworks.com; am-utils(a)am-utils.org Subject: SV: amd / netapp issue? There were some problem with redhat7.3 and nfs. That bug on redhat break down my tru64 fileserver. For that bug you need to update the kernel. We run now 2.4.20-28 on the old rehat7.3. I have also a problem with ontapp 7.0 with 100% cpu. We think it was nfs logical problem who crashed my netapp. So we upgraded now to 7.0.1R1 and hope it works. /tom -----Ursprungligt meddelande----- Från: Jay Williamson [mailto:jay_williamson@yahoo.com] Skickat: den 26 maj 2005 14:20 Till: toasters(a)mathworks.com; am-utils(a)am-utils.org Ämne: amd / netapp issue? Hi. I'm sending this to am-utils and toasters since I'm not entirely sure where the problem is. These systems (redhat73-1, redhat73-2, etc.) are in a cluster. These errors all occur around the same time on all the clients (freqently different jobs) but sometimes spread out across 10-30 minutes. My first guess is simply that the netapps are to busy to answer the clients. *If* that's the case, then what can I change on the netapp or the client-end to mitigate this problem? What other options are there? From the /var/log/amd on clients: redhat73-1: May 25 13:48:01 redhat73-1 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp1": RPC: Timed out redhat73-2: May 25 13:48:07 redhat73-2 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp2": RPC: Timed out clients are dual Xeons running redhat 7.3 am-utils-6.0.7-4 2.4.20-28.7smp mount options=(rw,hard,intr,grpid,retrans=30,timeo=30,retry=10,dev=00000010,vers=3,proto=tcp) # Interesting note: We actually set retry=10000 but the rh7.3 systems use 10 instead netapps are 960/980 class systems ontap=6.5.2R1P13 They are typically very busy (100%) when the errors occur Network switches show no errors NIC cards on client and netapps show nothing Nothing in the messages file in clients nor on the netapps. Thanks in advance and I'll summarize if I get some good input. - Jay __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

SV: amd / netapp issue?
by Langborg Tom 26 May '05

26 May '05

There were some problem with redhat7.3 and nfs. That bug on redhat break down my tru64 fileserver. For that bug you need to update the kernel. We run now 2.4.20-28 on the old rehat7.3. I have also a problem with ontapp 7.0 with 100% cpu. We think it was nfs logical problem who crashed my netapp. So we upgraded now to 7.0.1R1 and hope it works. /tom -----Ursprungligt meddelande----- Från: Jay Williamson [mailto:jay_williamson@yahoo.com] Skickat: den 26 maj 2005 14:20 Till: toasters(a)mathworks.com; am-utils(a)am-utils.org Ämne: amd / netapp issue? Hi. I'm sending this to am-utils and toasters since I'm not entirely sure where the problem is. These systems (redhat73-1, redhat73-2, etc.) are in a cluster. These errors all occur around the same time on all the clients (freqently different jobs) but sometimes spread out across 10-30 minutes. My first guess is simply that the netapps are to busy to answer the clients. *If* that's the case, then what can I change on the netapp or the client-end to mitigate this problem? What other options are there? From the /var/log/amd on clients: redhat73-1: May 25 13:48:01 redhat73-1 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp1": RPC: Timed out redhat73-2: May 25 13:48:07 redhat73-2 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp2": RPC: Timed out clients are dual Xeons running redhat 7.3 am-utils-6.0.7-4 2.4.20-28.7smp mount options=(rw,hard,intr,grpid,retrans=30,timeo=30,retry=10,dev=00000010,vers=3,proto=tcp) # Interesting note: We actually set retry=10000 but the rh7.3 systems use 10 instead netapps are 960/980 class systems ontap=6.5.2R1P13 They are typically very busy (100%) when the errors occur Network switches show no errors NIC cards on client and netapps show nothing Nothing in the messages file in clients nor on the netapps. Thanks in advance and I'll summarize if I get some good input. - Jay __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

amd / netapp issue?
by Jay Williamson 26 May '05

26 May '05

Hi. I'm sending this to am-utils and toasters since I'm not entirely sure where the problem is. These systems (redhat73-1, redhat73-2, etc.) are in a cluster. These errors all occur around the same time on all the clients (freqently different jobs) but sometimes spread out across 10-30 minutes. My first guess is simply that the netapps are to busy to answer the clients. *If* that's the case, then what can I change on the netapp or the client-end to mitigate this problem? What other options are there? From the /var/log/amd on clients: redhat73-1: May 25 13:48:01 redhat73-1 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp1": RPC: Timed out redhat73-2: May 25 13:48:07 redhat73-2 amd[965]/error: get_nfs_version: failed to contact portmapper on host "netapp2": RPC: Timed out clients are dual Xeons running redhat 7.3 am-utils-6.0.7-4 2.4.20-28.7smp mount options=(rw,hard,intr,grpid,retrans=30,timeo=30,retry=10,dev=00000010,vers=3,proto=tcp) # Interesting note: We actually set retry=10000 but the rh7.3 systems use 10 instead netapps are 960/980 class systems ontap=6.5.2R1P13 They are typically very busy (100%) when the errors occur Network switches show no errors NIC cards on client and netapps show nothing Nothing in the messages file in clients nor on the netapps. Thanks in advance and I'll summarize if I get some good input. - Jay __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters May 2005