toasters

toasters@lists.teaparty.net

13515 discussions

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

RE: Veritas NetBackup + NDMP == Doh!!
by Joe Luchtenberg 11 Oct '00

11 Oct '00

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

RE: Veritas NetBackup + NDMP == Doh!!
by Cormier, Darleen 11 Oct '00

11 Oct '00

Jeff, FYI, Workstation Solutions' Quick Restore package also allows all of the configuration options that Budtools allowed. If you want to take a look at their stuff, the url is www.worksta.com You're right that Veritas requires the drives in the library to be either directly attached to a filer, or attached to another filer. On the second issue, each F760 is able to support up to four tape drives, an F740 can support 2 and our newer F840 can support up to 8, so it depends on the model of filer you have. If your tape library supports splitting the internal bus, by daisy chaining a couple of drives together and cabling them directly to a filer, we have customers who are doing this, using Veritas to control the robotics. A backup package is required to control the robotics because we have no robotics control capability built-in to DataOnTap. Hope this helps. -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, October 10, 2000 7:04 PM To: toasters(a)mathworks.com Subject: Veritas NetBackup + NDMP == Doh!! We are currently using BudTool and implementing Veritas NetBackup as a replacement. We want to use NDMP to dump the filer's data off to a NetBackup server (big honkin' sun box w/ lots of library enclosed DLT7k's). Veritas says that in 3.2, they only support NDMP dump/restore to filer attached tape. In 3.4 they claim to support NDMP 3-way dump/restore from one NetApp to another NetApp with locally attached tape. So we are double hosed. Of course, BudTool effortlessly does NDMP to the filer attached tape, 3-way to another filer attached tape, and apparently right back into the BudTool host which is what we want with NetBackup. Anyone else trying to do the same thing? Any other ideas short of sitting on Veritas? On another topic entirely, does anyone have experience attaching many (2-4) DLT7k's per NetApp and using them as a backup tape server via 3-way NDMP? Something tells me that ONTAP and the filer are not designed to handle this well, but we'd like to see if anyone else is trying this. A possible solution for us would be using two or three filers with 4 drives attached to each as a pool of dump/restore servers for the other 20 or 30 filers. Thanks!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

3 2

FS: F200/F300/F500 parts and upgrades
by ScottUCE＠aol.com 11 Oct '00

11 Oct '00

Various older Netapp parts are priced as follows: X1101 FDDI dual attached cards 395.00 X1001 10Base-T/100Base-T cards 65.00 X311 2mb NVRAM expansions 75.00 X312 64mb system memory expansions 125.00 X212 4gb narrow disk drives 125.00 X217 4gb wide disk drives 250.00 X219 9gb fiber channel drives 450.00 Further, we have many other hard-to-find parts and upgrades for the F200, F300, F500 and F600 series systems. Please call for availability and pricing; we invite any offers. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 (952) 935-7282 (952) 935-5056 - FAX www.unioncomputer.com

1 0

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