toasters

toasters@lists.teaparty.net

3 participants
13513 discussions

DLT stackers for NetApp?
by Gregory Gulik 13 Oct '97

13 Oct '97

I heard once that the NetApps support DLT stackers (not libraries) so you can automatically do multi-volume backups without manual intervention. Is this true? If so, which tape stackers are supported?

2 1

migrating an F330 to a mixed-disc configuration
by Tom Yates 13 Oct '97

13 Oct '97

well, that was an interesting weekend. we dump/restore upgraded an F330 to a mixed-disc configuration. i thought i'd share some of the high points in case anyone else is thinking of doing this. i'd add that i'm typing this at 0300 on monday, so excuse the typos. this is also quite long, so feel free to ignore completely. if you just want to find my recommendations, look for digits in column one. that F330 had three shelves of 4Gb FSCSI discs. we wanted to upgrade to two shelves of 4Gb FSCSI discs and one shelf of 9Gb FWSCSI discs. ONTAP 4.2 is a prerequisite for this, so we'd been running stably at 4.2 for about ten days prior to the weekend (thanks, ja mah). our vendor (OSS) was lending us an F330 with two shelves of 9Gb FWSCSIs to dump my toaster to, as i'd prefer not to get 98% of the way through a tape restore and have i/o errors (thanks, OSS). design note: first impression on the eurologics shelves. these things came from the hans giger school of weird and creepy alien design. also, they look substantially less well-made than the old storageworks shelves. i'm putting that down to the lack of a guide bar ensuring that all the discs are precisely lined up. not that it matters. i hope. having installed the loaner toaster, the question of how to dump arose. i'd already borrowed an Ultra-2 from another project, and set it up as administration host for both local and loaner toasters. we'd heard that good things arose from fddi - dump times very significantly faster than even 100bT - so we tried using fddi/cddi on all three boxes connected to our cddi/fddi concentrator. the dump failed after about ninety minutes. just hung. i presumed that this was due to the cddi drivers being somewhat old, and decided to punt to 100bT, connecting all machines to our main switch (catalyst 5000). the dump hung after about ninety minutes. i presumed that this was an old dump bug biting us and down-rev'ed the local toaster to 4.0.1cD10 (which it had been running stably for some while before this) and restarted the dump over 100bT. the dump hung after about ninety minutes. i presumed i was being stupid and needed sleep and went home. in the light of day, some console messages gave us a clue to the truth: our cisco router was lying about the ethernet address of the administration host, and the local toaster was losing touch with the admin host. although this is a feature of our local network topology, i think recommendation one has to be 1) use a private network. i don't care how good your main networking kit is, you can do without the other packets. we put them onto a private fddi/cddi conentrator and started the dump. whilst it didn't hang, i wasn't getting stellar dump times, so we aborted the dump, and moved everything onto a private 100bT switch. dump times were much better, which i put down to the fddi drivers on the Sun being somewhat crufty, whilst the FE drivers are cutting-edge. recommendation two: 2) doesn't matter how great fddi is if the drivers aren't stellar. FE may well be better. if anyone's curious, the dump syntax was brutally simple: admin# rsh local "dump 0f - /" | rsh loaner "restore rfD - /restore" dumps finished about midnight (after an excellent sushi dinner for the unix and networking crew. thanks, shogun 9.). it took fifteen hours to dump 70Gb over FE, with fairly aggressive writing on the destination toaster (continuous writes and CPU at 70-80%). which leads me to 3) the netapp white paper on migration suggests doing a level 0 to your destination machine in work time a day or so beforehand, and following up with a level 1 in downtime. i really wish i'd done that instead of doing my level zero in (expensive) downtime. i then zeroed out all the disc labels on my toaster (floppy boot, option 5) and pulled off the third shelf. removed slot 9 SCSI card, replaced it with FWSCSI card, tried to boot. F330 hangs in "probing devices" phase of boot. thanks to some excellent late-night phone support by tony liu (MANY thanks, tony) it turns out that the FWSCSI card requires firmware 1.6, although ONTAP 4.2 doesn't. i'd already asked my vendor that question directly and got a different answer (grumble). emergency firmware upgrade to 1.6 ensues. toaster now boots, so i can get on with making a new file system (floppy boot, option 4). you've never known true nervousness until you watch all your users' home directories being newfs'ed. we've been told that the correct way to get a 9Gb and a 4Gb hot spare is to allow the newfs to allocate a 9Gb hot spare, and then RAID SWAP in a 4Gb into a slot left unoccupied in shelf 0. when we try the RAID SWAP, the bus fails to reset properly, and the damn thing goes into a variety of raid panic situations. all discs in the shelf on slot 0 are also showing amber "failure" lights, although they appear to work fine. lengthy calls to netapp fail to rectify this problem, and it's getting to the point where the restore won't finish until after 0001 monday, which is getting closer to the promised 0700 "everything back" time than i'd like, so i decided to go with a system which seems to handle the hot spare disc correctly - in the event of a disc failure, it RAID reconstructs to the 9Gb hot spare - but can't do hot swap. it's no worse than my old 450s, though i hope netapp will be able to rectify this later in the week, as does tony. the precise positioning of the thin gray ribbon cable that used to go to the narrow SCSI card in slot 9 seems to be an important unknown, since i understand this cable is responsible for carrying raid swap information around. in the event, the restore finishes around 0130 monday, and the servers (mostly) restart happily. summary: any migration involving a dump-and-restore is highly traumatic. we were right to avoid this when we went to the F330s, and we'd be well advised to avoid it in any future migrations - data copy to a new toaster is tolerable for our datasets, but copy-and-back isn't viable any more. the mixed-shelf configuration isn't exactly bug-free yet. sleep is a much under-rated phenomenon. Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

2 1

Re: migrating an F330 to a mixed-disc configuration
by sirbruce＠ix.netcom.com 13 Oct '97

13 Oct '97

Three comments: 1. Dump and restore is traumatic, but it's really the best way for large datasets. I think what it tells you more is: plan ahead! Know the limits of the filer you have so you won't have to do migration ahead of time, and when you do have to do it, know all the steps involved and have a good backoff plan. Also, backup and restore is much, much better than it used to be... I would not try this scheme with anything less than the latest software. 2. Your comment about the CDDI drivers is very true. I have also found the old Crescendo/Cisco cards to be lacking, and have had the best success with the NuBus CDDI cards. 3. Sounds like the bottom line for the mixed-shelf scheme is: "not yet." Still some bugs and lack of enough documentation. Oh, and always go direct instead of through third-party vendors if you can, but I came to that conclusion a long time ago... it applies to almost all computer companies, not just Netapp. Bruce PS - How about the NTAP stock?

1 0

reducing the size of a NetApp -- temporarily
by Daniel Quinlan 10 Oct '97

10 Oct '97

We recently purchased an F630 system with 26 9GB drives (two shelf pairs of 13 drives). Because multiple RAID groups (and to a less extent, multiple filesystems) are not supported, I have concerns about bringing a 200GB filesystem into the world. All of the space won't be needed for at least several months. The main problems brought on by large filesystems and are backup dataset size (and time), but the biggest concern is that when a disk goes, the raid reconstruction affects more of your data if you have a single RAID group. (As well as worse fault tolerance, etc.) And since we can add new drives by swapping them in, it doesn't seem like it would hurt to only bring 13 drives online at first. Since we have an active filesystem, can someone tell me what the best route to do this is? Any caveats? I have had one report from someone at NetApp that I should erase disk labels (I don't know if he meant all of them, just the ones being removed, or the ones staying) before starting, and another that it would be fine to just yank the disks I don't want and newfs the remaining ones. Dan

2 1

subscribe gsterlin@jjprayc1.jnj.com
by Greg Sterling 09 Oct '97

09 Oct '97

subscribe gsterlin(a)jjprayc1.jnj.com

1 0

Re: raid swap question
by sirbruce＠ix.netcom.com 08 Oct '97

08 Oct '97

On 10/07/97 21:12:31 you wrote: >Can you "raid swap" and add more than one spare disk at a time? No... you want to raid swap, shove a disk in, wait for it to detect, raid swap again, shove another disk in, etc. The fastest way to do lots of disks at once is to halt and power off the filer, shove the disks in, and then turn it back on. Bruce

2 1

raid swap question
by Daniel Quinlan 08 Oct '97

08 Oct '97

Can you "raid swap" and add more than one spare disk at a time? Dan

1 0

Re: DLT7000 streaming
by sirbruce＠ix.netcom.com 07 Oct '97

07 Oct '97

On 10/07/97 13:31:50 you wrote: >Maybe it's the wrong question, but I remember from other drive types >that once you drop into start-stop mode (or shuffling), the throughput >goes through the floor. Our SE thought that a 7000 being fed below >streaming speed might be actually slower than a 4000 being fed at the >same speed. Hmmm... I must admit ignorance in this area; I suppose it is possible, but it's not something I would believe off the cuff. >I agree that network backup is not great, but we're managing (just >about) to get it to work at the moment using amanda and exabytes. I'd >like to keep to one system, so we'll probably modify amanda to use the >DLT (either locally or on the filer). > >Has anyone any hard figures for backup speeds both locally on a filer >and remotely via 100Mbps ethernet and rmt or rsh? We don't have >anything that supports NDMP at the moment, but might consider Budtool, >though it doesn't support all the machines we have at the moment. Well, I have some numbers for FDDI.... rmt was abyssmal (500 K/sec), but that was several releases ago. A more recent release, uses a third host to rsh a piped dump and restore across a dedicated FDDI network, drove the tape drive much closer to it's limit, but I don't have exact numbers. 100Mbps ethernet isn't great but I would expect you'd see numbers much closer to local backup speed if you use rsh, but still not as fast as local. >Our main interest in the 7000 is capacity (single tape backup at the >moment), rather than speed. What if it takes 2 tapes? Are you going to get a 7000 stacker, or will you have to spend a lot of effort breaking the backup into pieces? At least a 4000 stacker will be able to keep up with your expansion. FYI, my experience with 7000 on the filer suggests that the capacity isn't as great as you might hope. A DLT-IV cartridge on a 4000 could often get 35-40GB on it (almost max 2:1 compression), but on a 7000 I could only get about 50GB, not the 60-70GB expected with max compression. It was not clear if this was a Netapp issue or a 7000 issue... perhaps they have resolved it? You would have to inquire and find out. >I'm told that they've now released a wide card supported on the F230 >in the latest release, so you can attach a 7000. Neato. I wish they'd update the web pages to actually reflect this. Bruce

1 0

Re: DLT7000 streaming
by Alan Judge 07 Oct '97

07 Oct '97

>>>>> On Tue, 07 Oct 1997 06:28:55 CDT, sirbruce(a)ix.netcom.com said: Bruce> Perhaps you are asking the wrong question? The 7000 isn't going to Bruce> be any slower than the 4000, I don't think, whether you keep it fed Bruce> or not. Maybe it's the wrong question, but I remember from other drive types that once you drop into start-stop mode (or shuffling), the throughput goes through the floor. Our SE thought that a 7000 being fed below streaming speed might be actually slower than a 4000 being fed at the same speed. I agree that network backup is not great, but we're managing (just about) to get it to work at the moment using amanda and exabytes. I'd like to keep to one system, so we'll probably modify amanda to use the DLT (either locally or on the filer). Has anyone any hard figures for backup speeds both locally on a filer and remotely via 100Mbps ethernet and rmt or rsh? We don't have anything that supports NDMP at the moment, but might consider Budtool, though it doesn't support all the machines we have at the moment. Our main interest in the 7000 is capacity (single tape backup at the moment), rather than speed. Bruce> PS - Is the 7000 even supported on the F230? I'm told that they've now released a wide card supported on the F230 in the latest release, so you can attach a 7000. -- Alan

1 0

Re: DLT7000 streaming
by sirbruce＠ix.netcom.com 07 Oct '97

07 Oct '97

On 10/07/97 10:38:50 you wrote: >Our SE raised an issue about streaming with the DLT7000 and how the >drive can slow down a lot if you don't keep it fed. Has anyone any >experience with either local or remote DLT7000s? Can a 230 keep one >streaming? Can you stream one over 100Mb ethernet, or at least keep >it going at a reasonable rate? Perhaps you are asking the wrong question? The 7000 isn't going to be any slower than the 4000, I don't think, whether you keep it fed or not. It may be that even local backup can't feed a 7000 fast enough under many "real world" circumstances. So if you're looking at 7000 for speed reasons, that's one thing; but then, I wouldn't be doing network backup at all in that case. My experience with rmt is that you won't get anything near what you want; if you are using NDMP, maybe the performance is substantially better. If you want fast backup, keep it local; if you're concerned about capacity, get a 7000, local or not. Bruce PS - Is the 7000 even supported on the F230? Unless they released a wide or wide differential card, it's SCSI-2 only. Or do they have a narrow version of the 7000? In either case, I would suspect that performance for such a peripheral to be severely reduced when compared to the wide version.

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