toasters

toasters@lists.teaparty.net

13520 discussions

RE: Netapp and CIFS
by Fox, Adam 21 Sep '00

21 Sep '00

I haven't seen NT security problems with cluster. If a CIFS client is in the middle of a transaction and a takeover occurs, they will have to restart their transaction just as if the filer rebooted. CIFS is stateful and doesn't handle disconnects as gracefully as NFS. But once the takeover occurs, you can restart your transaction and you'll be fine. The client will re-connect to the server (this time the surviving partner) and keep running along. That's been my experience in the field. Others are welcome. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: Pesce, Nicholas (FUSA) [mailto:Nicholaspesce@firstusa.com] > Sent: Thursday, September 21, 2000 10:17 AM > To: 'toasters(a)mathworks.com' > Subject: Netapp and CIFS > > > Ok, > Here is my query...Being a Solaris administrator I have > unfortunately been > put in a situation where I have to build a Netapp for an NT > domain. We > already have one system running CIFS that is a single point > of failure. I > want to cluster this system, but I don't understand the > nuances of CIFS > clustering. I'm curious if the NT Domain security issues > pose any problems > to the clustering software, or if the Virtual Machine created > on a takeover > negates these problems. > > Your help is appreciated. > > >

1 0

RE: upgrading from 5.2.3 to 5.3.6.R2
by Clawson, Simon 21 Sep '00

21 Sep '00

I had a few 'orrible troubles when I went up. It could have been me, but I did loose some qtree info, and we had problems with some of our source safe software. I would advise you read the bug list carefully, as well as the start here. Once it is running it is OK, but you need to be prepared for the unexpected! -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: 20 September 2000 01:47 To: jmiddlebrooks(a)datalink.com Cc: toasters(a)mathworks.com Subject: Re: upgrading from 5.2.3 to 5.3.6.R2 Jason Middlebrooks <jmiddlebrooks(a)datalink.com> writes: > > Any tricks when upgrading from 5.2.3 to 5.3.6R2 aside from making sure the > filer is at the correct firmware revision? You'll find there is also a disc firmware upgrade if you have FCAL discs (ST118202FC, anyway). You might want to do this in advance with disk_fw_update after you've un'tarred the new /etc contents into place. > Do you loose you qtree > information or snapshots? Absolutely not! > Is there a doc on the NOW site on the steps to > take to do this particular upgrade. I think anything special to be aware of is covered in the start.pdf (the "Data ONTAP 5.3.6R2 Software Start Here" document). > Hopefully it is as simply as untaring the files to the filer and typing > download and reboot. Just about. The most immediately visible change will be the persistent "options" values in 5.3.x. The first time you boot 5.3.6R2 it will produce a number of messages that might alarm you if you weren't expecting them: it's just setting up /etc/registry for the first time. There's also a WAFL upgrade process that lasts a few minutes (it doesn't lock out access while it's doing it). Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

Netapp and CIFS
by Pesce, Nicholas (FUSA) 21 Sep '00

21 Sep '00

Ok, Here is my query...Being a Solaris administrator I have unfortunately been put in a situation where I have to build a Netapp for an NT domain. We already have one system running CIFS that is a single point of failure. I want to cluster this system, but I don't understand the nuances of CIFS clustering. I'm curious if the NT Domain security issues pose any problems to the clustering software, or if the Virtual Machine created on a takeover negates these problems. Your help is appreciated.

1 0

Employment wanted for a toaster trained engineer
by Stephen McMullan 20 Sep '00

20 Sep '00

Any of you got a job for a toaster trained engineer in UK. I have all the Network appliance related courses and experience. I Just need some work in UK preforably North West England. Is there any toasters or Netcache's in UK ? ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie

1 0

RE: Optimal volume size
by Kelly Wyatt 20 Sep '00

20 Sep '00

One drawback... someone has to remember to add the new qtree to the backup list each time. And why could you not restore specific qtrees from a volume backup in the same order? Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Senior Systems Programmer Strategic Recovery SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com <http://www.sas.com/> SAS... The Power to Know -----Original Message----- From: Eli Lopez [mailto:Eli.Lopez@netapp.com] Sent: Wednesday, September 20, 2000 3:28 AM To: Clarke, John L. (CIS); toasters(a)mathworks.com Subject: Re: Optimal volume size Hi guys, Backuping on a qtree level gives one very important advantage in case of disaster recovery: You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last. Regards, Eli ----- Original Message ----- From: Clarke, <mailto:John_Clarke@bose.com> John L. (CIS) To: 'toasters(a)mathworks.com' <mailto:'toasters(a)mathworks.com'> Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow. -----Original Message----- From: Louis Brune [ mailto:lbrune@sd.us.am.ericsson.se <mailto:lbrune@sd.us.am.ericsson.se> ] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters(a)mathworks.com Subject: Re: Optimal volume size Fortunately for me, someone else here takes care of backups, but... We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger. Can you not back up with qtree granularity instead of per volume? b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks. You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group. c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer. Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad. -- Louis

1 0

RE: upgrading from 5.2.3 to 5.3.6.R2
by Kelly Wyatt 20 Sep '00

20 Sep '00

If you use a third party backup solution, you should check to make sure that the backup software/ONTAP combination is supported. That has been the biggest headache for my group lately. Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Senior Systems Programmer Strategic Recovery SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com SAS... The Power to Know -----Original Message----- From: jmiddlebrooks(a)datalink.com [mailto:jmiddlebrooks@datalink.com] Sent: Tuesday, September 19, 2000 6:35 PM To: toasters(a)mathworks.com Subject: upgrading from 5.2.3 to 5.3.6.R2 Any tricks when upgrading from 5.2.3 to 5.3.6R2 aside from making sure the filer is at the correct firmware revision? Do you loose you qtree information or snapshots? Is there a doc on the NOW site on the steps to take to do this particular upgrade. Hopefully it is as simply as untaring the files to the filer and typing download and reboot. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

1 0

Solaris 2.5.1, stat/read/fcntl random freezes on NFS
by Brian Tao 20 Sep '00

20 Sep '00

Has anyone experienced a Solaris 2.5.1 (103640-29, in this case) NFS client block on a stat(), read() or fcntl() call only to a particular file (or small number of files)? We've seen this happen on rare occasions in the past. For no apparent reason though, a plague has hit our web server farm in the past week or so. We've had five or six instances recently where the only solution was to reboot the server. What happens is that a seemingly random file sitting on the Netapp can no longer be read or stat'd or locked by the Solaris client. There is no suspicious lock activity. Even an innocent "cat" or "ls -l" on the file (triggering one of the above sycalls) will hang. A truss shows that the syscall never returns. Other Solaris clients mounting the same filesystems have no problems accessing those files. The reboot is necessary because there is always at least one Apache httpd process (the first one to see this problem?) that becomes unkillable, thus port 80 is never unbound, and a new parent cannot be started. After a reboot, everything returns to normal. One of our servers had to be rebooted this morning. Eight hours later, it was wedged trying to access that same file, plus another one on the same NFS filesystem. At this point, I'm blaming Solaris (easy target ;-)), but I have no hard evidence that would incriminate the OS, the application, the network, or the filer. Rebooting the server seems to fix the problem (at least temporarily), suggesting an OS bug. We've never seen this happen with anything besides Apache, suggesting an application bug. However, the three most recent "problem" files have all been on the same exported filesystem on the same Netapp. Filer bug? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

3 3

Fw: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

1 0

Re: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

RE: Optimal volume size Hi guys, Backuping on a qtree level gives one very important advantage in case of disaster recovery: You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last. Regards, Eli ----- Original Message ----- From: Clarke, John L. (CIS) To: 'toasters(a)mathworks.com' Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow.

1 0

RE: Optimal volume size
by Clarke, John L. (CIS) 20 Sep '00

20 Sep '00

a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow. -----Original Message----- From: Louis Brune [mailto:lbrune@sd.us.am.ericsson.se] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters(a)mathworks.com Subject: Re: Optimal volume size Fortunately for me, someone else here takes care of backups, but... We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger. Can you not back up with qtree granularity instead of per volume? b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks. You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group. c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer. Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad. -- Louis

2 1

Jump to page:

2025

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