toasters

toasters@lists.teaparty.net

13515 discussions

Netapp, AIX, and disk pacing
by Richard L. Rhodes 21 Feb '00

21 Feb '00

<color><param>0100,0100,0100</param>Earlier this year we had a big thread about using NetApps as a DB disk subsystems. I had made the following comment in reference to performance on AIX: ></color>7) The one problem I do have, is that during a high sequential write >load, like creating an Oracle tablespace, the high sequential write >rate locks out other processes from doing I/o to the netapp. For >example, during a create of a 2gb db file, If I (in another window) >try and do anything that does I/O, I can wait for 5/10/15 seconds for >the command to come back. I'm not sure why this is, but I think >this is a problem in AIX, NOT the netapp - because if during the >massive sequential writes I try and access the netapp from another >computer I get great response. AIX must be queing NFS I/O's or<bigger> ><smaller>something - which doesn't make sense! Well, I kept looking for an answer . . . and finally found it. AIX has 2 options that control disk i/o pacing: minpout and maxpout. They are defined in the doc as follows: :D<color><param>0100,0100,0100</param>isk-I/O pacing is intended to prevent programs that generate very large :amounts of output from saturating the system's I/O facilities and causing :the response times of less-demanding programs to deteriorate. Disk-I/O :pacing enforces per-segment (which effectively means per-file) high- and :low-water marks on the sum of all pending I/Os. When a process tries to :write to a file that already has "high-water mark" pending writes, the :process is put to sleep until enough I/Os have completed to make the number :of pending writes less than or equal to "low-water mark." The logic of I/O- :request handling does not change. The output from high-volume processes is :just slowed down somewhat. The high- and low-water marks are set with <bold>smit</bold> :by selecting <bold>System Environments</bold> -> <bold>Change / Show Characteristics of :Operating System</bold> and then entering the number of pages for the high- and :low-water marks. The default value for the high- and low-water marks is 0, :which disables pacing. New I/O pacing parameters normally take effect :immediately and last until they are explicitly changed. The default for these parms is "0" - no limit. I found a comment in the performance tuning guide that said if your having problems with disk pacing, try setting these to maxpout=32 and minpout=16. After doing this i/o was much better (even normal) during a tablespace create. The manual stated that there is a small performance hit when setting these parms from default, but I didn't notice any in my testing. So, for those of you using a Netapp for a db on AIX, you might want to look into these parms for yourself! Rick <nofill> ---------------------------------------------------------------------- Richard L. Rhodes e: rhodesr(a)firstenergycorp.com Ohio Edison Co. p: 330-384-4904 f: 330-384-2514

1 0

RE: NVRAM memory
by Y. Hiro Kaneiso 20 Feb '00

20 Feb '00

You should also pay attention to cp_from_cp. If you see non-zero numbers there, it means a cp could not be made in the background (even forced) and responces to clients' requests were made waited until a cp is finished. The system is obviusly short of NVRAM. -hiro -----Original Message----- From: Bruce Sterling Woodcock <sirbruce(a)ix.netcom.com> To: Eyal Traitel <eyal.traitel(a)motorola.com> Cc: Eyal Traitel (r55789) <eyal.traitel(a)motorola.com>; Karl Swartz <kls(a)netapp.com>; Jay Orr <orrjl(a)stl.nexen.com>; lrazo(a)netapp.com <lrazo(a)netapp.com>; toasters(a)mathworks.com <toasters(a)mathworks.com>; beepy(a)netapp.com <beepy(a)netapp.com> Date: Sunday, February 20, 2000 2:35 AM Subject: Re: NVRAM memory ----- Original Message ----- From: Eyal Traitel <eyal.traitel(a)motorola.com> To: Bruce Sterling Woodcock <sirbruce(a)ix.netcom.com> Cc: Eyal Traitel (r55789) <eyal.traitel(a)motorola.com>; Karl Swartz <kls(a)netapp.com>; Jay Orr <orrjl(a)stl.nexen.com>; <lrazo(a)netapp.com>; <toasters(a)mathworks.com>; <beepy(a)netapp.com> Sent: Saturday, February 19, 2000 8:52 AM Subject: Re: NVRAM memory > Thanks. > > I already can see this on one of the more used ones: > > cp_from_timer = 288539 > cp_from_snapshot = 210065 > cp_from_low_water = 0 > cp_from_high_water = 2 > cp_from_log_full = 138834 > cp_from_timer_nvlog = 10 > cp_from_cp = 6006 > > > Can someone from NetApp answer on if it would be useful to have an upgrade > for such machine ? To me cp_from_log_full seems high. I did some digging in my old notes and found that one engineer recommened cp_from_log_full should only be 10% of cp_from_timer. I'm not sure what cp_from_snapshot is but even if you add that to cp_from_timer your log is still filling up over 25% of the time. cp_from_cp is not too bad, though, so maybe it is not hurting you that much. Again, I'd check systat 1 during heavy loads and if it looks okay, your NVRAM is being heavily utilized but not overloaded. Bruce

2 1

NetApp disk replacement "disaster": post-mortem
by Will Partain 19 Feb '00

19 Feb '00

Folks, I've just been through a "replace a disk" scenario that went wrong. It *isn't* a "disaster", because the machine wasn't being used for anything interesting at the time. I am recounting it here in case others can benefit (and so you can all smirk at my expense :-). Old NetApp F220. One disk died. Called support guys; they sent another disk. Typed 'disk swap', swapped a disk, typed 'disk unswap'. Hmmm. One thing wrong, another possibly. I'd swapped the wrong disk (counted them from the wrong end), and I'd possibly taken too long to complete the swap. All I know is, the filer went down in a blaze of glory. When I rebooted, it failed to load the OS; error "Invalid opcode" (i.e. it read junk off the disk). So I rebooted from floppies (after swapping the disks back around correctly), and that seemed cool -- it figured out which disk was what, and did all the necessary RAID reconstruction. Everything looked OK. Rebooted. Failed to load the OS: 'Invalid opcode' again. Hmmm... At this point, I said, "Never mind" and just rebuilt the whole thing from scratch. What I *think* I could've done was: reboot from floppies; splat the ontap stuff into /vol/vol0/etc from afar; typed 'download' at the filer, and it might've worked. (But would I have had reason to trust any of the ordinary RAID data at this point?) If you spot a place where I (+ support guy) went badly wrong, other than what I've outlined, I'd like to know. Thx, Will

5 5

Re: Backing up a filer
by mds＠gbnet.net 19 Feb '00

19 Feb '00

A few mails condensed here: On Tue 15 Feb, 2000, Jay Orr <orrjl(a)stl.nexen.com> wrote: > My understanding of Budtool and Quick Restore was that you could pull tar > files off of the tape directly. Generally, the desire for this ability is: > > 1) if the machine with the backup software goes down, you can still do > recoveries, and > 2) you can restore to differing systems. That was what used to be my line on tape formats too. Then I investigated how Legato could be used in the case of the backup server itself dying. The key is to know (have writtenfor yourself) a procedure for rebuilding a backup server efficiently. I used to think Legato was a pain at this, but it turns out that if you set up a server reasonably you can follow their Disaster Recovery Guide and be back in business pretty quickly. In about as much time as it would take you to find the right tapes somehow and trawl them by hand using tar or dump/restore. I'm assured ADSM and Veritas and presumably everyone else as well has their own Way. > I will grant that the Veritas solution of interleaving streams does sound > well thought out and probably more efficient, but from an admin's > perspective, you have to figure some day the worst will happen. AFAIK The interleaving thing was born of expediency, for all the backup product vendors: for backing up from slow individual clients to tapes that only work efficiently when streaming. Tape lifetimes are also reduced sharply when tapes are constantly stopped, rewound-a-bit and set to streaming again. The fact that most admins like to get their backups done in the same windows, and using the same policies, relying on the backup software to work at least some of it out for them, means many backups get scheduled for the same time anyway. On a more banal note, is it not tempting to set client-paralellism up a notch, it sounds sexy and you never know, it *might* help. > Reminds me of Microsoft's argument against solaris : "Sun is trying to > resurrect the 1960s-era mainframe paradigm and return computing to > old-style timesharing." (www.dot-truth.com) Amazing how marketing appeals > to feelings, not empirical data. Always the way. Often works too - like when vendors sell to managers who don't then employ their technical staff in product evaluation and selection cycles. Or worse, they do but it's all a shame exercise, which means that the time was wasted on top of the bogus decision.. I'm not bitter, really. 8) > Until the system with the backup-product fails.... Ah, well I refer to my point about having a good procedure for dealing with that. IMHO it's more important for business continuity to have the whole backup service back than it is to get the first restore done - because Murphy will most likely have the most restores you ever saw be requested in that window, just after you decided that doing that one restore *then* getting the backup system going again would be the best policy. Been there. Got bitten. > But that all said, your comments are appreciated and gives me food for > thought. I guess it weighs in as one of the older Unix paradoxes - ease > vs. utility (can't think of a better way to phrase that). Sure, who > wouldn't want the easiest to use backup software? But from an admin > perspective, we have to be able to pick up the pieces if it all explodes > and put it back together ASAP. Yup it's a balancing act - the two aren't necessarily mutually exclusive goals though. >-- End of excerpt from Jay Orr On Tue 15 Feb, 2000, Steve Kappel <steve.kappel(a)raistlin.min.ov.com> wrote: > Interleaving (multiplexing is the term in NetBackup) is optional in > NetBackup. You can turn it off for any class. This is good to know - though I guess you have to be confident of the ability of a given client to supply data to keep the tapes fed. > NetBackup NDMP does NOT use multiplexing. Also note that for NDMP > the tape format is determined by the NDMP server vendor. NDMP uses dump format as well doesn't it? So all the propositions above get a little messed around here anyhoo. >-- End of excerpt from Steve Kappel On Tue 15 Feb, 2000, "Eyal Traitel" <eyal.traitel(a)motorola.com> wrote: > Are there any plans / ideas from Veritas on improving backup/restore times of > filers ? Here's hoping. > It seems that the tape/backup s/w is not keeping up well with the filers' huge > sizes ? Oh the number of times I've bewailed this too. > What is the best configuration that can give us best performance ? Anyone fancy a quick poll on how fast they can backup how much? >-- End of excerpt from "Eyal Traitel" -- -Mark ... an Englishman in London ...

8 10

Re: Centralized backup of multiple filers
by Marion Hakanson 18 Feb '00

18 Feb '00

Barry Lustig wrote: > > Do any of the available backup solutions support a "dump to disk mode" > like amanda? Amanda uses the disk on the local backup machine as the cache. > After the backup completes to disk amanda dumps that file to tape. This > takes care of the streaming issues. This of course would be a problem with > large NetApp filesystems. But imagine if the packages (veritas, legato, > workstation solutions, etc.) took the incoming data stream and wrote it as > configurable chunks (100Mb, 1GB, etc.) to disk. They could then flush those > chunks to tape. Hmm, I recall reading that CommVault Systems was working on a product which migrated (HSM-style) older files to optical jukebox, and thence to tape (via backup system), and made all the migrated stuff look like a really huge "snapshots" area: http://www.commvault.com/net_apps.html It's not _exactly_ what the original poster was talking about, but it seems similar in feel. And automatic. Anyone had any experience with this product? It would seem pretty cool, especially since it looks like they have this integrated with Unix (NFS) and NT file servers, database servers, etc. Regards, -- Marion Hakanson <hakanson(a)cse.ogi.edu> CSE Computing Facilities

1 0

RE: Problems encountered with AIT-2 tape drive on F740 server
by Roth, William 18 Feb '00

18 Feb '00

David, AIT-2 in native mode isn't supported yet but... Depending on the compressibility of the data, 50 GB may fill the tape. What kind of data are we dealing with, binaries, graphics, image, etc.? What quantity of data are we dealing with on the filer, before any compression? Are you using the dump command, or third party software to manage your backups? If manually using dump, what is the command you're entering? I understand that you're using nrst0a, I don't know why the abort occurs. Is there anything in /etc/messages or /etc/ndmplog.yyyymmdd that help define why the abort occurs? If you're using third party backup software, are there any messages that help us define the cause of the abort? Based on the problem you've described, I don't think that going from 5.3.4R2 to 5.3.4R3 is going to resolve the issue. Thanks, Bill Roth -----Original Message----- From: David H. Brierley [mailto:dhb@ssd.ray.com] Sent: Thursday, February 17, 2000 3:05 PM To: toasters(a)mathworks.com Subject: Problems encountered with AIT-2 tape drive on F740 server I am having a problem on one of my machines and I was wondering if anyone has encountered anything similar. I have an F740 running 5.3.4R2, with a directly attached AIT-2 tape library. When I first tested the tape drive it performed wonderfully. Once I was happy with the 740 and with the tape drive, I moved the bulk of the data from a pair of old F230's over to the F740. The problem I then encountered is that when I am dumping to the tape it writes 50 gig and then aborts. I am using the "36C" AIT-2 tapes and I am accessing the tape drive using device "nrst0a", so I should be able to write approximately 72 gig of data to the tape. I have tried several different tapes and get the same results. I also tried setting the tape drive into DLT7000 emulation and I still get the same results. The qeustion now is: is there something wrong with the tape drive or is this a problem with 5.3.4R2? Should I try upgrading to 5.3.4R3? I have another F740 with a DLT7000 library on it and it seems to work just fine. Did I blunder badly by switching to AIT-2? Please help!!!!! -- David H. Brierley Raytheon Electronic Systems, Naval & Maritime Integrated Systems Engineering Technology, Operating Systems Support Group

1 0

RE: Centralized backup of multiple filers
by Kelly Wyatt 17 Feb '00

17 Feb '00

And another... if you use the filer in a multiprotocol manner, won't you lose the NT acls if you back it up from UNIX? -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Systems Programmer Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Wednesday, February 16, 2000 6:10 AM To: Brian Tao; Darrell Fuhriman Cc: toasters(a)mathworks.com Subject: Re: Centralized backup of multiple filers > I thought they were already quite busy. If they're so busy that > you don't feel you can attach a local tape drive, I'm not really > understanding how they're unbusy enough to hammer them with a > bunch of rsyncs. Another point: Is buying and attaching all that disk to the SUN systems really cheaper than simply attaching a local tape drive? And setting up a cluster with SnapMirror would probably be more expensive, but not prohibitively so. Bruce

2 1

Centralized backup of multiple filers
by Brian Tao 17 Feb '00

17 Feb '00

This is my plan, after having debated the merits of distributed tape libraries on each filer vs. centralized tape library with network backup. I've posted separately to both the toasters and bigbackup mailing lists (even though I figure most people on the second list are also on the first). - backup clients are 12 filers (mostly F740's), each with multiple 100 Mbps Ethernet interfaces - backup servers are 2 Sun E420R's with enough CPU, memory, U2SCSI and Gigabit interfaces to keep things humming - each filer has 1 or 2 100 Mbps interfaces plugged into a switch, with the backup servers on Gigabit (probably something like a Catalyst 3524XL: 24 10/100 + 2 Gigabit) - each backup server will have four U2SCSI channels or two FC-AL loops, initially with half a terabyte of local disk and an Exabyte X80 library with 4 Mammoth2 drives (expandable to 8) - stage 1 backup: filesystems on all the filers will be replicated to the tape servers' local drives (probably rsync over NFS) - stage 2 backup: local filesystems are streamed to tape This seems to work around most of the "problems" associated with backing up directly to tape, with a few extra side benefits thrown in. I can only realistically expect a peak of 8 to 10 MB/sec from our filers (for some of them, there is only "busy" hours and "really busy" hours). That's not enough to keep the tape drives streaming and happy. To do that, I'd have to multiplex backup streams to a single tape, and I always thought that was a bad idea. Hard drives, of course, have no "streaming" issues. They'll take the data however fast or slow the Netapps can send them. Once the Netapp filesystems have been replicated to local disk, you blast them out to tape. With compression turned on, I figure I'll need about 20MB/sec per tape drive to keep them chugging along. Less shoeshining, less wear-and-tear on the media, longer tape drive MTBF. Since all the filer filesystems are consolidated on local storage, you can slice-n-dice your backup sets to fit whatever drive/tape/time constraints you may have. This also gives you a nearline copy of all your data. Combined with the Netapp's snapshots, I should never ever have to go to tape to retrieve a current generation copy of a file that was accidentally deleted or corrupted. Disaster recovery of a downed filesystem can also come off local disk instead of tape. If you use commercial tape backup software, you don't have to worry about buying and maintaining licenses for all the Netapps: all the software sees is one server backing up its own drives to a tape stacker. This may result in savings greater than the cost of the local drive storage. I haven't had an opportunity to really test out how fast rsync works over NFS with the particular hardware setup described above, so that's the weak link. If the results from trial runs on a non- dedicated Ultra2 can be scaled up to a quad CPU E420R, I don't think there will be a problem. Multiple rsyncs can be fired up concurrently to keep the filers busy. For the amount of data we have (300GB at present), I expect the tape drives will only be busy for about an hour doing a weekly full backup, and only a few minutes each day for differentials. Anyone else doing it like this? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

5 6

Re: Centralized backup of multiple filers
by Darrell Fuhriman 17 Feb '00

17 Feb '00

Brian Tao <taob(a)risc.org> writes: > I can only realistically expect a peak of 8 to 10 MB/sec from our > filers (for some of them, there is only "busy" hours and "really busy" Is that from experience or theory? > out to tape. With compression turned on, I figure I'll need about > 20MB/sec per tape drive to keep them chugging along. Less Does M2 have the streaming issues of DLT? You'll certainly never push that much data into a DLT7000 or AIT. ~10MB/sec with bursts to 12 is the best you'll get. I think M2 is probably too new to know how it really behaves in the real world. > constraints you may have. This also gives you a nearline copy of all > your data. Combined with the Netapp's snapshots, I should never ever If you're doing that, it would seem to me it would make more sense to use a second (perhaps in a cluster) toaster and mirror the volumes using snapmirror. > I haven't had an opportunity to really test out how fast rsync > works over NFS with the particular hardware setup described above, so > that's the weak link. If the results from trial runs on a non- It's not all that fast (somewhere i have some numbers I ran). If you're syncing lots of smaller files, you'll burn through memory like mad, too. > there will be a problem. Multiple rsyncs can be fired up concurrently > to keep the filers busy. For the amount of data we have (300GB at I thought they were already quite busy. If they're so busy that you don't feel you can attach a local tape drive, I'm not really understanding how they're unbusy enough to hammer them with a bunch of rsyncs. Frankly, I think you've made the solution much more complicated than need/should be. Backups should be done as simply as possible -- you've added lots of opportunity for things to break, which really don't need to be there. > Anyone else doing it like this? I suspect not. Darrell

3 4

Does anyone have experience/knowledge of 9K frames ?
by Eyal Traitel 17 Feb '00

17 Feb '00

Hi ! Does anybody knows if it is supported now in NetApp ? What about Cisco switches ? Has anyone uses it with trunking also ? Eyal.

1 0

Re: wafl unicode options and conversion times
by Todd C. Merrill 17 Feb '00

17 Feb '00

Bruce Sterling Woodcock wrote: > From: Joan Pearson <jpearson(a)netapp.com> > > Yes, while a directory is being converted, all access to it should be > > locked out. Perhaps the nfs client was using information it had > > already cached before the conversion. > > Yeah, but doesn't the cache check something on the directory before > it makes assumptions? Access or modify time? > > Maybe the filer isn't updating that at the start of the conversion > process. I dunno. There's gotta be a way to defeat the client > cacheing other than mounting "noac". This was all "first contact" stuff, from both a freshly rebooted filer and client. No caching as far as I understand it was involved. In our debugging, we tried the "noac" option; it didn't work (for obvious reasons looking back on it now). The first contact initiates the conversion; unfortunately for us, it was the dirents() from the `rm -rf` returning an incomplete directory listing. Joan, the call was 83902. On Wed, 16 Feb 2000, Hal Siegel wrote: > This conversion took close to a day and a half on a 630 full of > hundreds of thousands of files of gzipped archive data. Interesting. I interpreted the docs as saying a single directory with 100,000 files took 9 minutes. I never expected a directory with 20-30 files to be converted in anything more than a negligible time. My expectations were just out of line with the behaviour of the filer. NetApp folks, perhaps this could be expounded upon in future docs with more warnings and other examples. > Note that you > can monitor the conversion taking place by watching sysstat - there's a > steady 3-400 disk reads per second going on while the conversion is > being done. Looking at our MRTG data a few days later, I figured that out. Doh! Eyal Traitel wrote: > Can one of you explain the need for this anyway ? It's really only a concern in a mixed CIFS/NFS environment, which we are heavily. The docs can explain the wafl ucode options much better than I can. But, one problem with not having the unicode information in the directory structure is this, which we ran into all the time: o create a directory via an NFS client o do not access this directory from a CIFS client o create a snapshot o try to access this directory via a CIFS client via the snapshot You will get "permission denied." The CIFS access tries to create the unicode information in the directory upon creation or access, but, since it's in a read-only snapshot, it can't. The wafl ucode options allow you to create directories with the unicode information already there, even if created via an NFS client, or to convert the directories upon any access, NFS or CIFS. It is the latter case that takes a non-trivial amount of time, enough to impact normal behavior. 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

wafl unicode options and conversion times
by Todd C. Merrill 16 Feb '00

16 Feb '00

Just thought I'd share a caveat that we ran into in the recent past in upgrading from 5.2.x to 5.3.x. It took two separate cases and 50+ emails and phone calls to figure out, so hopefully this info will save somebody else quite a bit of time. (Many thanks to Mike Smith in tech support for his patience and perseverance in resolving it.) 5.3 (?) introduced two new options, wafl.convert_ucode and wafl.create_ucode, to convert directories upon access and create directories from scratch with unicode bits, respectively, even if accessed/created via an NFS client. We updated our rc files with these options and proceeded with business as usual after the upgrade. Hours later, our entire automated testing environment came to a screeching halt with "permission denied" and other bizarre errors. For instance, an `rm -rf` of a directory would fail, leaving files around, when all the file and directory permissions would have allowed the removal: % rm -rf build.removeme rm: Unable to remove directory build.removeme/test/toolbox/map/map: File exists rm: Unable to remove directory build.removeme/test/toolbox/map: File exists ... Cut to the chase: after getting packet snoops and trying various things on different filers, and the usual troubleshooting, NetApp was able to reproduce the "problem." It wasn't a problem. The docs state, regarding unicode conversion of directories: "For example, converting a directory of 100,000 files takes the filer about 9 minutes on a netapp f540." I read this, and said to myself, "Self, we don't have any directories that big," so I dismissed as trivial the time it would take to convert our directories. We had maximum 2,000 files in our largest directories. Well, even with a semi-honkin' F740, two generations distant from the aforementioned F540, we were seeing `rm -rf` failures on small directories, with only tens of files. And, the clients doing the `rm -rf` weren't all that speedy, a 200 MHz Sun Ultra2, a 270 MHz Ultra5, and even a SPARC20, if I recall correctly (among other types of UNIX boxes, like 200 MHz Pentium Linux boxes). Turns out, this unicode conversion takes a non-trivial amount of time for *any* directory. System call traces showed directory entry calls returning not all files in that directory. Apparently, during the conversion, the "new" directory list can be incomplete. Hence, an `rm -rf` first gets an (incomplete) directory listing, then removes all those files, does a `cd ..` and then tries an rmdir(), at which point, since there are still files in the directory, it spits out an error like the above. Once we figured this out, we tried to forcibly convert all the directories by doing a `find . -print > /dev/null` to traverse the entire filer directory structure. Well, this apparently didn't work (my notes get sparse here) in all cases. Our final workaround was to go to a CIFS client (an NT box), right-click on each top level folder on the filer and select "properties," and let it finish calculating the folder size, thus doing the unicode conversion as usual (the way it had to be done before the wafl options in 5.3.x). So much for the interpretation of "wafl.convert_ucode" working via NFS access to the directory. At the conclusion of the call, I requested the docs to be expounded upon and made clearer regarding unicode conversions for future releases. To date, we have not had any further problems. The "access denied" messages when trying to access non-unicode directories (those created via an NFS client pre-5.3 or with the wafl.create_ucode option unset) from read-only snapshots via CIFS clients has been eliminated. Yea! Hope this helps others. 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 ---

4 3

New Gigabit Ethernet cards in cluster?
by Michael Rogan 16 Feb '00

16 Feb '00

Hello, Has anyone tried to use the new Gigabit Ethernet II (Intel) cards using a single vif in a cluster? I have tried these cards individually and failed the cluster over and everything works just fine but if I put them in a single/multi vif and fail the cluster, I can ping the machine, I can telnet to it and it states that it has failed over, I can http to it; however when I try NFS connections to it, it does not respond? Any suggestions? Config file (Partner rc is nearly identical): ## # RC, file san1 -- MJR # Network 172.17.1.0 to be changed after testing -- MJR # Modified for testing -- MJR ## hostname san1 options dns.domainname blackberry.net options dns.enable on options nis.enable off # Setup Virtual Interfaces ifconfig e6 flowcontrol none ifconfig e7 flowcontrol none vif create single sanvif e6 e7 vif favor e6 # configure interfaces ifconfig e0 192.168.200.110 netmask 255.255.255.0 mediatype 100tx-fd partner 192.168.200.111 ifconfig sanvif 172.17.1.110 netmask 255.255.255.0 trusted partner sanvif # Test, works if vif not configured - MJR #ifconfig e6 172.17.1.110 netmask 255.255.255.0 partner e6 route add default 192.168.200.1 1 savecore exportfs -a nfs on vol snapmirror on ## Michael Michael J. Rogan BlackBerry Sys. Adm. Research In Motion 519-888-7465 www.blackberry.net www.rim.net

1 0

Please add me to your list
by WAY,PETER (HP-Loveland,ex1) 16 Feb '00

16 Feb '00

Peter Way

1 0

RE: Which spare 9 or 18 or 36
by Barrett,Eric 16 Feb '00

16 Feb '00

Yup. When a disk is removed from a RAID group, for whatever reason, the filer will use the smallest possible hot spare disk that it can. (It cannot, of course, reconstruct onto a disk that was smaller than the original.) If a hot spare of the same size isn't available, it will pick the next largest one. -- Eric Barrett, TSE, Network Appliance ebarrett(a)netapp.com / 408-822-4779 (office) NetApp Tech Support: 1-888-4NETAPP > -----Original Message----- > From: Jim Harm [mailto:harm1@llnl.gov] > Sent: Tuesday, February 15, 2000 3:24 PM > To: toasters(a)mathworks.com > Subject: Which spare 9 or 18 or 36 > > > Dear super informative list; > > Let's say there is a volume of 9 GB drives in a 760 > and another volume of 18 GB(or 36 GB). > Now I have a 9 GB spare and an 18 GB spare in the box also. > When a drive dies, does the box pick the spare of the same size > as the failed disk to rebuild? > > }}}===============>> LLNL > James E. Harm (Jim); jharm(a)llnl.gov > (925) 422-4018 Page: 423-7705x57152

1 0

RE: Backing up a filer
by Kelly Wyatt 16 Feb '00

16 Feb '00

Hmmm... I just saw in the technote that Veritas NetBackup does not support that (a little table in that same technote indicates that)... I will be checking with Veritas on that because they know we plan to test this and have given no indication that this would not work. Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Systems Programmer Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com -----Original Message----- From: [ISS] Veritas-Users Sent: Wednesday, February 09, 2000 9:54 AM To: 'Roth, William'; 'gwong(a)futureshop.com' Cc: 'toasters(a)mathworks.com' Subject: RE: Backing up a filer I understand that you can do NDMP dump across the network to a media server... it is even mentioned in technote 3066, section 4.3 (# 4 below): ---- The NDMP protocol specification allows the following backup configurations: 1. Local backup from a filer to a SCSI-attached tape device 2. Three-way backup from a filer via the network to another filer with a local tape device 3. Backup from a UNIX or Windows NT server via the network to a NetApp filer with a local tape device 4. Backup from a NetApp filer via the network to a UNIX or Windows NT backup server with a local tape device ---- We currently backup filers via dedicated directly attached tape drives (using Veritas NetBackup)... but, this is a costly solution because the tape drives are idle probably 75% of the time. We will be testing NDMP across a dedicated GB ethernet network in the near future. Even if we see some decrease in backup throughput, it will good if we can get those 20 dedicated DLT7000 tape drives in S'Tek 9710's doing more work for us... Is anyone already using a private network and NDMP to backup a filer? Kelly -- Kelly Wyatt, Kelly.Wyatt(a)SAS.com Systems Programmer Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 http://www.sas.com -----Original Message----- From: Roth, William [mailto:William.Roth@netapp.com] Sent: Friday, January 07, 2000 11:21 AM To: 'gwong(a)futureshop.com' Cc: 'toasters(a)mathworks.com' Subject: RE: Backing up a filer Greg, If you want to use NetBackup with NDMP to back up the filer, you need to have at least one direct attached tape drive connected to the filer(not considering a three way NDMP backup using two filers with a tape device direct connected to the remote filer). You can dedicate one or more drives from an existing library controlled by NetBackup, or you can attach a new/different library to the filer(yes, the filer does support a locally attached library). Either the NetBackup host (NDMP client) or the filer can be direct connected to the robotic portion of the library(assuming the library has individual scsi ports for the connection). In the end, NetBackup ends up controlling the library either way. If the robot is direct connected to the NetBackup host via scsi, NetBackup controls it. If the robot is connected to the filer via scsi, the NetBackup host sends scsi cdb's via NDMP to the robot through the filer, thus the robot is still controller by NetBackup. What other information or assistance do you require? Bill Roth Technical Marketing Engineer Network Appliance, Inc. 495 East Java Drive Sunnyvale, CA 94089 Telephone 408-822-3308 -----Original Message----- From: Greg Wong [mailto:gwong@futureshop.com] Sent: Thursday, January 06, 2000 11:45 AM To: toasters(a)mathworks.com Subject: Backing up a filer Hi all, I'm kind of new to the this filer business and I have a question about backing it up. We have an F720 on site that isn't doing much since we aren't backing it up. I need some options on how to do this. We currently back up our other systems vith Veritas Netbackup and a tape library. Now, my question(s) is if I want to use Veritas to back up the filer using NDMP, do I have to dedicate a drive on the remote tape library to the filer? Will the filer support a locally attached library, and if it does, does Veritas control the library or does the filer? Thanks for your help Greg

6 7

RE: max file system size
by Jason Middlebrooks 16 Feb '00

16 Feb '00

So on a F760 I can have 56 32GB drives on one fibre loop? Is any performance lost here? Thanks Jason "Bond, Andrew" <abond(a)netapp.com> on 01/28/2000 09:48:33 AM To: Jason Middlebrooks/Datalink cc: toasters(a)mathworks.com Subject: RE: max file system size This question should really be addressed to your local NetApp sales person or SE, however: > Is the maximum storage per fibre loop still 464.4GB? No. The maximum storage per F760 is presently approx. 1.4TB raw disk space. This can be on one loop or more than one loop, in whatever config you require, subject to a maximum of 56 devices per loop. Regards, Andrew

4 3

Which spare 9 or 18 or 36
by Jim Harm 15 Feb '00

15 Feb '00

Dear super informative list; Let's say there is a volume of 9 GB drives in a 760 and another volume of 18 GB(or 36 GB). Now I have a 9 GB spare and an 18 GB spare in the box also. When a drive dies, does the box pick the spare of the same size as the failed disk to rebuild? }}}===============>> LLNL James E. Harm (Jim); jharm(a)llnl.gov (925) 422-4018 Page: 423-7705x57152

1 0

Re: Backing up a filer
by Steve Kappel 15 Feb '00

15 Feb '00

mark wrote: >> NetBackup NDMP does NOT use multiplexing. Also note that for NDMP >> the tape format is determined by the NDMP server vendor. > >NDMP uses dump format as well doesn't it? So all the propositions above >get a little messed around here anyhoo. No, NDMP is format neutral. NetApp's implementation of NDMP uses dump. tar is used by some others. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

Re: Backing up a filer
by Steve Kappel 15 Feb '00

15 Feb '00

Eyal, >Are there any plans / ideas from Veritas on improving backup/restore times of >filers ? The only time NetBackup has a performance impact on backup is when there are a very large number of files in the backup (on the order of millions). Currently we get all the NDMP history in DIR & NODE messages which we then have to convert into full paths for our catalog. This can be CPU, RAM, and disk intensive. We are investigating options for how we might address this issue. As for restore time there isn't much we can do besides add support for 'direct access restore'. Sounds easy but it isn't. Even when NetApp supports it, it may not be what you want - it will have limitations. It is a hard thing to do with a dump-style backup. Because of the limitations and the NetBackup model, we may not be able to support it reliably. We always take the conservative approach of doing everything we can to make sure you get the correct data and any new optimizations have to be bullet-proof. In the end, all we can do is support what NDMP and each NDMP server implementation provides to us. >It seems that the tape/backup s/w is not keeping up well with the filers' huge >sizes ? I don't think it is just filers - the whole industry is seeing an explosion of data. Tape drives certainly haven't kept up with disk. Of course NetBackup has other features that are not available in the NDMP world simply because 1) we have raw access to the disk, and 2) we control the tape format. >What is the best configuration that can give us best performance ? From a NetBackup perspective the only thing you can do is try to keep the number of files per backup from getting very large. Trouble is that breaking a volume up into different backups has an impact on filer efficiency (unless you use quota trees). __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

Re: Backing up a filer
by Darrell Fuhriman 15 Feb '00

15 Feb '00

"Eyal Traitel" <eyal.traitel(a)motorola.com> writes: > Are there any plans / ideas from Veritas on improving > backup/restore times of filers ? In this case the issue is primarily the fact that Netapp continues to use dump, which is not the speediest way to recover files. (Being that it has to search the entire tape(s) to get even a single file.) Of course, Veritas has plenty of it's own problems (restore times being only one of them) -- don't get me started. > It seems that the tape/backup s/w is not keeping up well with > the filers' huge sizes ? No question. I've been continually making noises at Netapp to improve the way they do backups, but haven't heard of any movement. > What is the best configuration that can give us best performance ? Well, you could consider using legato and the netapp clientpak, though that requires you to do backups over the network, which is really sub-optimal. Given the current state of affairs at Legato Corporate, who knows what's going to happen in the future with the product. Restores should be dramatically faster though. I think ultimately, right now, the only thing you can do is use faster tape drives and/or smaller volumes, neither of which is really good solution. Darrell

1 0

Re: Backing up a filer
by Steve Kappel 15 Feb '00

15 Feb '00

>> > supported. I liked the fact that both QR and Veritas used an ISO standard >> > tar format for the backup. This ruled Legato out early, since they use >> >> Hmmm, I suspect from what I've learned from Veritas and others, that >> you don't see tar format on the tapes used for the basic backups. The >> reasoning being that the backup software usually interleaves several >> streams of data from clients to ensure streaming onto tapes (to extend >> tape lifetimes as well as reduce the overall backup window). Cloning the >> tapes in some manner allows the backup software to reduce the chance of >> data loss AND also to rationalize the interleaving so you do get tape >> files with coherent tar format inside.. but some folks don't clone >> tapes, so they may well never get tar-readable tapes. > >My understanding of Budtool and Quick Restore was that you could pull tar >files off of the tape directly. Generally, the desire for this ability is: > >1) if the machine with the backup software goes down, you can still do >recoveries, and >2) you can restore to differing systems. > >I will grant that the Veritas solution of interleaving streams does sound >well thought out and probably more efficient, but from an admin's >perspective, you have to figure some day the worst will happen. Interleaving (multiplexing is the term in NetBackup) is optional in NetBackup. You can turn it off for any class. NetBackup NDMP does NOT use multiplexing. Also note that for NDMP the tape format is determined by the NDMP server vendor. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

2 1

strange NT errors when copying a file
by Steve Bos 15 Feb '00

15 Feb '00

Has anyone experienced a "session was canceled" error before? When copying a file from a NT box to a 720, the file seems to be copying fine, then at the very end the "session was canceled" error pops up on the NT machine. The strange thing is the file seems to have copied, at least the file sizes are the same. This error doesn't exactly fill you with confidence that the copy went o.k. In the environment, it seems that some machines are more susceptible to this error than others. Has anyone ever run into this before? Thanks in advance... Steve -- Steve Bos steve(a)intervision.com InterVision Systems (408) 567-4223

1 0

Re: AW: Backing up a filer
by Steve Kappel 15 Feb '00

15 Feb '00

>- Do you know, when Netbackup v3.4 will be released? It will be going beta in a few weeks. So probably a few months away. >- Backing up Files without ACL´s? >We also have many UNIX-Files and dont need the use of ACL´s. Is there a >possibility >to disable NDMP-Backup with ACLs? If possible, does this affect restore >times, because the acl´s on the end of the file are not needed. I'm not sure I understand the question. If you are wondering about turning off the backup of ACLs, I believe there is a NetApp NDMP environment variable that can do that. As far as I am aware this wouldn't affect the restore time - it still reads the entire image (I think). Someone from NetApp can correct me if I'm wrong. With NDMP the backup product just positions to the beginning and tells the NDMP server to start the restore. What happens after that is up to the NDMP server implementation. >- NDMP v3: >Are ther any real enhancements with this implementation and when will it be >released >with Veritas/Netapp? V3 adds some minor things to the protocol but that doesn't mean they are used by a given NDMP client. V3 is not in NetBackup 3.4. I can't tell you what is in the following release because the feature content hasn't been finalized (and maybe even then I can't say ;). V3 is in the pipeline but I wouldn't expect any functionality impact because of it. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

AW: Backing up a filer
by Micheler Klaus (EZM, Villach) 15 Feb '00

15 Feb '00

Hi Steve! Thanks for the answers. Please let me ask some more questions. - Do you know, when Netbackup v3.4 will be released? This alternate client restore is very vital to us, because the filer tends to crash, if Data is changed while Restores. One idea is to make a volume for restores only. With the current solution it had to be done on each filer, with alternate Client restore it had to be done only on one Filer - Backing up Files without ACL´s? We also have many UNIX-Files and dont need the use of ACL´s. Is there a possibility to disable NDMP-Backup with ACLs? If possible, does this affect restore times, because the acl´s on the end of the file are not needed. - NDMP v3: Are ther any real enhancements with this implementation and when will it be released with Veritas/Netapp? Thanks in advance for your answers. regards, Klaus Micheler mailto:klaus.micheler@infineon.com -----Ursprüngliche Nachricht----- Von: Steve Kappel [mailto:steve.kappel@raistlin.min.ov.com] Gesendet am: Montag, 14. Februar 2000 20:38 An: Klaus.Micheler(a)infineon.com Cc: toasters(a)mathworks.com Betreff: RE: Backing up a filer Hi Klaus, > -NDMP alternate client Restore: Restore Data backuped from Client A >directly to Client B? > What must I do to make this possible? This functionality is implemented in the upcoming NetBackup 3.4 release. > -NDMP Direct Acces Recovery: > Restore of single Files/Directories in a short time (Our Backup >Images are currently about 100 - 150GB). > What Restore times do you have? (In my case, it looks like the >Filersearches the whole dump, which can take up to 8 hours). Is there any >possibility to speed this up? Yes, the entire dump image is read by restore. Neither OnTap or NetBackup support direct access restore in currently shipping releases. This is a complicated problem to solve in a dump-style backup. The only suggestion I can make to improve restore speed is to breakup the backup into smaller dumps. If you are doing full volume dumps now then this may be less efficient as far as backup speed is concerned. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

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