toasters October 2000

toasters@lists.teaparty.net

90 participants
109 discussions

RE: cifs.home_dir values
by White, Lance 14 Oct '00

14 Oct '00

See http://now.netapp.com/NOW/knowledge/docs/ontap/rel60/html/sag/cifs19.htm#14… for info on setting up multiple directories. (Note that this is for OnTap 6.0 which will run on your F760 (assuming you pass the WAT test). -----Original Message----- From: Coder, James (STP) [mailto:james.coder@guidant.com] Sent: Friday, October 13, 2000 7:53 PM To: 'toasters(a)mathworks.com' Subject: cifs.home_dir values I have a 760 being used for home file server in Solaris / windows environment. This is replacing my e3500 filer server running samba. Can you have more than one volume listed in for cifs.home_dir? If so, how do you set it up? thx in advance - jcc James C. Coder UNIX Administrator Guidant Corporation Phone: 651-582-4797 Email: james.coder(a)guidant.com

1 0

cifs.home_dir values
by Coder, James (STP) 14 Oct '00

14 Oct '00

I have a 760 being used for home file server in Solaris / windows environment. This is replacing my e3500 filer server running samba. Can you have more than one volume listed in for cifs.home_dir? If so, how do you set it up? thx in advance - jcc James C. Coder UNIX Administrator Guidant Corporation Phone: 651-582-4797 Email: james.coder(a)guidant.com

1 0

FILERS IN A HIGH-TRANSACTION SYBASE APP ENVIRONMENT
by Joe Luchtenberg 13 Oct '00

13 Oct '00

Is anybody using NetApp filers for backend storage in a high-transaction Sybase app environment? I have a customer considering this configuration and would appreciate any insight/lessons learned from the field. Thanks. Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com

1 0

RE: F760/F840, ONTAP 5.3.x/6.x gripes
by Reidenbach, Edward 13 Oct '00

13 Oct '00

Thanks for the feedback on the Data ONTAP release model. There were numerous factors we considered in the decision making process for both Data ONTAP 6.0 and 5.3.6H1. Factors including * time to market * time frame for separation of code lines * feature/function and regression/reliability testing scope * project schedule differences * and the risk profile of the various alternatives were critical in the decision making process. We believe the resulting release model decisions provided the highest quality solution for you in the most timely manner. Follow-on maintenance releases for both Data ONTAP 5.3.6H1 and 6.0 will address the platform specific issues associated with the above mentioned releases. Ed Reidenbach Marketing Manager, Data ONTAP, Multiprotocol and High Availability Network Appliance Phone: 408-822-6167 Email: edr(a)netapp.com -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Thursday, October 12, 2000 7:11 AM To: toasters(a)mathworks.com Subject: F760/F840, ONTAP 5.3.x/6.x gripes Can someone from NetApp comment on these following concerns? It seems...inconvenient for those who upgraded to ONTAP 6 on F760s to have to revert back to 5.3.6.x in order to upgrade to the F840s. The release of ONTAP 6 couldn't wait until a port to the x86 code was ready for the F840s? And, also, why won't 5.3.6H1 run on an alpha-based filer? I couldn't test 5.3.6H1 *anywhere* in my environment, except on my new F840 which I needed immediately on a high-visibilty filer. I upgraded and went live with 5.3.6H1 and crossed my fingers that there would be no problems with this new release. Very unnerving. I'm now running with two different ONTAP versions on a group of filers, and hoping I don't run into any inconsistencies across my environment due to this. Again, a port of 5.3.6H1 couldn't have been made for the alpha-based filers coincident with the x86-based F840? Lastly, could the boot process be made smarter to load the appropriate microkernel, x86 or alpha, if *both* were included on disk? These gyrations to install and download x86- or alpha-based code from *floppy* (slllooowwwww) just seems so...so...kludgy. Probably not, but I'm just asking. Makes a simple head-swap upgrade not so simple. In summary, in comparison to the usual elegant and quick upgrades and downgrades for previous ONTAP versions, these points above just increased my downtime [0] and decreased my comfort level. (BTW, the 840 is taking the load of our previous 760 without even breaking a sweat. Yipee!) [0] Just one of these migrations or ugprade/downgrades takes you far below a 99.999% uptime metric. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

F760/F840, ONTAP 5.3.x/6.x gripes
by Todd C. Merrill 12 Oct '00

12 Oct '00

Can someone from NetApp comment on these following concerns? It seems...inconvenient for those who upgraded to ONTAP 6 on F760s to have to revert back to 5.3.6.x in order to upgrade to the F840s. The release of ONTAP 6 couldn't wait until a port to the x86 code was ready for the F840s? And, also, why won't 5.3.6H1 run on an alpha-based filer? I couldn't test 5.3.6H1 *anywhere* in my environment, except on my new F840 which I needed immediately on a high-visibilty filer. I upgraded and went live with 5.3.6H1 and crossed my fingers that there would be no problems with this new release. Very unnerving. I'm now running with two different ONTAP versions on a group of filers, and hoping I don't run into any inconsistencies across my environment due to this. Again, a port of 5.3.6H1 couldn't have been made for the alpha-based filers coincident with the x86-based F840? Lastly, could the boot process be made smarter to load the appropriate microkernel, x86 or alpha, if *both* were included on disk? These gyrations to install and download x86- or alpha-based code from *floppy* (slllooowwwww) just seems so...so...kludgy. Probably not, but I'm just asking. Makes a simple head-swap upgrade not so simple. In summary, in comparison to the usual elegant and quick upgrades and downgrades for previous ONTAP versions, these points above just increased my downtime [0] and decreased my comfort level. (BTW, the 840 is taking the load of our previous 760 without even breaking a sweat. Yipee!) [0] Just one of these migrations or ugprade/downgrades takes you far below a 99.999% uptime metric. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 4

SAN's and backups (Was: Re: Veritas NetBackup + NDMP == Doh!!)
by mds＠gbnet.net 12 Oct '00

12 Oct '00

On Wed 11 Oct, 2000, Marion Hakanson <hakanson(a)cse.ogi.edu> wrote: > I think things are headed toward the use of SAN-connected tape > drives and libraries for this type of setup. The backup software > tells the SAN switch to connect up the appropriate number of drives > to the backup client (NetApp), and then uses NDMP to initiate the > backup on the client, using "direct attached" tape drives. When > that backup is done, you "direct attach" the drives to the next client. I can think of a rather neat scenario along those lines: as described tape drives and disk drives are all on a switched FC fabric along with one or more NetApp filers, and possibly an NDMP backup host or two. When a backup host starts a backup running, the NetApp starts causing blocks to be transferred directly from the disks it manages to the tape drive(s) that the backup host controls, mingled with a little metadata it originates itself, while sending the lion's share of metadata to the NDMP backup host. Nothing should go across any piece of wire any more times than is absolutely necessary. The same scenario could go for any normal open system (Unix, NT, AS400, whatever) in a similar fabric, but I'm not sure who's best placed to actually make it work. I'd like to think NetApp were. See, until these scenarios start coming true, SAN's aren't much more than an overworked buzzword for big flipping messes made of disks and fibre. I still think SAN's are an about-to-be-useful item, but I've yet to see much real progress. > Heck, some libraries (ATL, for one) are becoming available with NDMP > servers right in them, ethernet interface included. Dunno where > you put the file history or tape indexes, but it's getting interesting. With the nominated backup controller boxes, which keep the metadata on-line (on disk) so that restores, archival, cloning etc. remain first-order activities, as much as running databases and maintaining other applications. Backups should never be afterthoughts as they so often are. Sorry, got a bit bitter and twisted there. 8) > Speaking of NAS & tape libraries, does anybody have any experience > with the Grau Data "Infinistore Virtual Disk System" (www.graudata.com)? > It's apparently a NAS box with a RAID cache in front of a tape library. Sounds like fun. Crafted well, the scenario I describe would ideally have the IO balanced to keep the tape drives well-fed, the backup window small, the filer heads serving out of the front-door performantly and the backup controllers adequately busy. Otherwise, what would be the point? Strikes me that they're angling toward HSM which is related but not the same. > The brief article I saw in Server/Workstation Expert magazine mentioned > that an "entry level" system starts at around $100k, so I didn't read > beyond that (:-). We sure wish NetApp had something like this, > since somewhere around 80% of our filer's capacity is tied up in > files that haven't been accessed in a year or more. And that final comment makes me think you'd quite like an HSM product with NetApp-style qualities. I've often thought that it'd be nice if NetApp could make such boxes, by way of extension beyond the filers, but I don't know if anyone's tested the market to see what sort of demand there might be. >-- End of excerpt from Marion Hakanson -- -Mark ... an Englishman in Derby ...

2 1

RE: Migrating 2 x F740 => F840
by Knight, Graham 12 Oct '00

12 Oct '00

If you have two volumes that will be merged on to one F840 and they have the same name, I would suggest attaching only the volume you'd like to use as the root of the F840 first. Then follow the procedure at the link below. After the F840 is up and running on the new volume then add the second volume. When the second vol0 is added the system will recognize it as a foreign volume and leave it offline. At that point you can rename it and bring it online with the other volume. Graham -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Wednesday, October 11, 2000 8:52 PM To: toasters(a)mathworks.com Subject: Migrating 2 x F740 => F840 Is it possible to "merge" the disk shelves from two or more F740's onto a single F840 without losing the data? It sounds like it might be as simple as having to rename volumes (to avoid having multiple /vol/vol0's) when attaching the shelves to the F840. Has anyone tried this? Any requirements or caveats to watch out for? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

RE: Migrating 2 x F740 => F840
by Ljungberg, Anders 12 Oct '00

12 Oct '00

Hello Brian, Well first you have to decide which volume to be your new root. (or you may be using a brand new one) ( vol options volname root) The volumes will come up as "foreign" and named /vol/vol0 and /vol/vol0(2) Bring them online with "vol online" and change the names with "vol rename" Anders Ljungberg -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Thursday, October 12, 2000 6:12 AM To: toasters(a)mathworks.com Subject: Re: Migrating 2 x F740 => F840 On Wed, 11 Oct 2000, Brian Tao wrote: > > Is it possible to "merge" the disk shelves from two or more F740's > onto a single F840 without losing the data? It sounds like it might > be as simple as having to rename volumes (to avoid having multiple > /vol/vol0's) when attaching the shelves to the F840. Has anyone tried > this? Any requirements or caveats to watch out for? Here is the document on NOW describing the migration procedure (including kernel and bootblock update) going from an F700 series to an F840: http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.6869703.2865011 It doesn't specifically cover adding another volume of disks that was once considered to be the /vol/vol0 boot volume on different filer, but I imagine that is easily solved by renaming the volume once it is on the destination filer? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Migrating 2 x F740 => F840
by Brian Tao 12 Oct '00

12 Oct '00

Is it possible to "merge" the disk shelves from two or more F740's onto a single F840 without losing the data? It sounds like it might be as simple as having to rename volumes (to avoid having multiple /vol/vol0's) when attaching the shelves to the F840. Has anyone tried this? Any requirements or caveats to watch out for? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 1

RE: Veritas NetBackup + NDMP == Doh!!
by Alvarado, Michael 11 Oct '00

11 Oct '00

Here are two documents that overview the new library with the Gigabit Ethernet interface along with the ported NDMP tape server. http://www.atlp.com/pdf/ctrjuly2000.pdf ATL supports NDMP/NAS/GbE http://is.pennnet.com/home/articles.cfm?ARTICLE_ID=81787&VERSION_NUM=1&PUBL… ON_ID=23&Section=CurrentIssue -----Original Message----- From: Joe Luchtenberg [mailto:joe.luchtenberg@data-line.com] Sent: Wednesday, October 11, 2000 2:06 PM To: 'Marion Hakanson'; Scott Mikusko Cc: Cormier, Darleen; 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: Veritas NetBackup + NDMP == Doh!! Didn't take time to check the archives, but I believe the NAS w/SAN centralized tape backup has been addressed here before. The "certified" solution incorporates NetApp/Veritas/Vixel/Spectra Logic. Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com > -----Original Message----- > From: Marion Hakanson [SMTP:hakanson@cse.ogi.edu] > Sent: Wednesday, October 11, 2000 2:27 PM > To: Scott Mikusko > Cc: Cormier, Darleen; 'Jeffrey Krueger'; toasters(a)mathworks.com > Subject: Re: Veritas NetBackup + NDMP == Doh!! > > > . . . > > This is where allowing NDMP to dump to a remote tape library is very > > important, because systems such as I support require more than 4 drives > > and having local tapes drives on filers is not really feasible. > > > > -Scott > > I think things are headed toward the use of SAN-connected tape > drives and libraries for this type of setup. The backup software > tells the SAN switch to connect up the appropriate number of drives > to the backup client (NetApp), and then uses NDMP to initiate the > backup on the client, using "direct attached" tape drives. When > that backup is done, you "direct attach" the drives to the next client. > > I think Veritas and NetApp claim to support something like this, but > only with certain SAN switching equipment. If you've got SCSI drives > (as opposed to FC), then you'll need a SCSI-to-FC converter while > you're at it. > > Heck, some libraries (ATL, for one) are becoming available with NDMP > servers right in them, ethernet interface included. Dunno where > you put the file history or tape indexes, but it's getting interesting. > > Speaking of NAS & tape libraries, does anybody have any experience > with the Grau Data "Infinistore Virtual Disk System" (www.graudata.com)? > It's apparently a NAS box with a RAID cache in front of a tape library. > > The brief article I saw in Server/Workstation Expert magazine mentioned > that an "entry level" system starts at around $100k, so I didn't read > beyond that (:-). We sure wish NetApp had something like this, > since somewhere around 80% of our filer's capacity is tied up in > files that haven't been accessed in a year or more. > > Regards, > > -- > Marion Hakanson <hakanson(a)cse.ogi.edu> > CSE Computing Facilities >

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

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 October 2000