toasters

toasters@lists.teaparty.net

13531 discussions

Common MIB's wanted.
by Brian Hostetter 24 Feb '00

24 Feb '00

I am looking for a list of common mibs used to monitor filers. Specifically I am looking for cpu percent and number of disk writes. We are looking to do a snap mirror over a wan connection and need to know what kind of bandwidth will be needed. Has anyone compiled a list of commonly used mibs? I will be graphing these results with mrtg if that helps. --Brian

2 1

rsync and nfs file systems
by Greg Kitch 24 Feb '00

24 Feb '00

We have experienced the following problem with the --delete option when using rsync to mirror data... When a directory on the source file system is replaced by a symbolic link with the same name, the directory is deleted from the destination file system by rsync by unlinking the directory without having recursively removed all files/directories under the parent (deleted) directory. The net effect on our local destination file system seems to be that this leaves unreferenced files and directories that must be cleaned up by fsck at some future date. We noticed this by accident simply because we decided to take an rsync-mirrored disk offline and fsck it to check its integrity. Our question is...What will happen to a wafl file system if rsync deletes a directory in this fashion? Does NFS deal with this properly or is it a potential issue? Thanks in advance. Greg Kitch UCLA SEASnet Computing Facility

6 7

RE: Disk drive technology
by Mohler, Jeff 24 Feb '00

24 Feb '00

I dont have any solid data on data/stripe/drivesize performance handy, but it is a wise move to not span raid-groups over multiple FCAL controllers. There will be write degredation involved with that that I have seen. With two F760s rebuilding a manually failed drive while doing nothing else, the machine without a stripe split across FCAL cards completed about 25% before the machine that did span FCAL cards for a raid stripe. mkfile tests from Solaris confirmed what Id heard..and saw in the reconstruct as part of my test. :-----Original Message----- :From: mds(a)gbnet.net [mailto:mds@gbnet.net] :Sent: Wednesday, February 23, 2000 5:04 PM :To: toasters(a)mathworks.com :Subject: Re: Disk drive technology : : :On Wed 23 Feb, 2000, "Bruce Sterling Woodcock" :<sirbruce(a)ix.netcom.com> wrote: : :> The article doesn't say, but bigger, faster disk drives :often draw more :> power. Thus, NetApp needs to have shelves that can support them :> first, before they can test them for reliability. There are :a lot of issues :> involving mechanical vibration and so on that have to be :assessed before :> such a drive could be qualified. It may be that this :particular drive is :> not appropriate for certain shelves. : :Well, yeah, so much so obvious. So how soon was that? 8) : :> More spindles is better performance, if you are read-heavy. :If your filer :> seems slow and it's reading constantly but the CPU is still :under 100%, :> more spindles could help. : :So much for conventional wisdom. However, my question was trying to :elicit something a little more, well, complete as a model of :performance. : :I mean FCAL is a loop technology, and filers can come with 1, 2 or 3 :loops. How much does performance differ when using 1 chain as opposed :to 3 balanced chains, using which drives, using what RAID set sizes and :volume mappings? How does performance get affected by the size of the :disks you use? : :See, if none of these things makes any difference to performance I'd :love to know why. If they *do* then I'd love to know how to build :faster filers. : :I'd be happy with an analytical model, or a set of tables taken from :either real lab testing with real filers, or simulator results. As it :stands though, all we have are rules of thumb that sound plausible. : :The same goes for backup performance. There's been so much discussion :on the list about both topics, but I can't honestly hand-on-heart tell :someone how best to set-up their filers. I'd write something if I knew :the answers myself. : :The best I can find is things like: :http://now.netapp.com/NOW/knowledge/contents/FAQ/FAQ_560.shtml : :I've been meaning to brush up on queueing theory so maybe I *will* try :to work something up myself on this. I'd just hate to reinvent :the wheel :if someone's done it already. I also don't know anything about the :buffers in the filer, on FCAL interfaces, the network interfaces, the :precise use of the WAFL, etc.. So my model might be under-informed. : :Here's a thought to mull over: if you have 20 18 gig drives on 2 loops :and 16MB nvram, will you see better or worse performance than :with 40 9GB :drives on 1 loop with 16MB nvram presuming your clients are all writing :as fast as they are allowed? Please disregard any "such configs aren't :shipped" objections as this is an in-principle hypothetical. Please do :consider the effect of RAID sets, and incremental disk-additions over :the lifetime of the filer in question. I picked writing as the task :because I wanted to point out also that there's an impact on the DOT :algorithms, based on the spindles, the RAID set sizes, and maybe the :chains too. : :I don't know the answer, but I'd like to. Without such models we all :have to purchase filers somewhat in the dark, and either pray that :we got it right, or expend more time than we could in evaluating our :purchases for suitability. : :One question - is anyone else interested in this or am I just shooting :my mouth off needlessly? : :>-- End of excerpt from "Bruce Sterling Woodcock" : :-- :-Mark ... an Englishman in London ... :

1 0

Disk drive technology
by mds＠gbnet.net 23 Feb '00

23 Feb '00

Having just seen: http://www.eetimes.com/story/OEG20000223S0007 I'm curious to know if they'll be appearing in NetApp's soon. I'm also curious to know if anyone has any more information to share regarding the effects on filer performance of the number of spindles, the number of chains, the size of the disks, etc, etc, etc. Everyone went a little quiet last time this came up. -- -Mark ... an Englishman in London ...

2 1

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

23 Feb '00

On Mon 14 Feb, 2000, Lisa Paton <lcp(a)head-cfa.harvard.edu> wrote: Thanks for the review Lisa, word from teh front-line is far more valuable than marketing bumf. <snip> > 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 rationalise 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. I'd be happy to hear otherwise, but I wouldn't place too much value in that ISO standard tar formatting. I have to say that when I first heard, from Veritas Reps trying to sell their product to me, that the guys at CDC had nobbled gnu tar into an enterprise-class backup product (GPL notwithstanding) I just chuckled. Valid approach, but when you're backing up 100's of GB's or more, and spending through the nose for an enterprise-class backup product that manages every detail for you, the value of personally being able to grub through a tape using tar begins to pale a bit. > a proprietary format. I was impressed that Jim Ward (President of > Workstation Solutions) came out to meet with me personally, AND could > answer technical questions that the Veritas SE couldn't answer. WS impressed > me as a small, technically savvy company that was very responsive to me > during the evaluation period. I had a couple small glitches that were Now that sounds like NetApp - who still send out plenipotentiaries to find out what their customers are really doing, and really need. > Lisa Paton >-- End of excerpt from Lisa Paton -- -Mark ... an Englishman in London ...

4 4

How to Create ClearCase VOB on filer F720
by Amy Cheng (r46990) 23 Feb '00

23 Feb '00

Dear All, We've just purchased ClearCase and I want to create VOB on filer F720. But I met difficulties . When I run making vob command, there are some error showed. #cleartool mkvob -tag /proj/view -public /proj/test.vbs cleartool: Error: Unable to contact albd_server on host 'cptlfiler' >cleartool: Error: Unable to create view "/data/project/view/test1.vws". We have mounted a diretory of cptlfiler on /proj. Someone tell me that technical reason is that we can not do NFS mount over NFS. There is no way to created a view on filer without ClearCase. Have anyone met this qestion like me? How do you deal with it? if it not feasible to create vob on filer, we can't benefit from snapshot any more for vob. Sincere thank for you help. BR Amy

3 2

Re: level 2 oplocks and MS outlook
by Matt Day 22 Feb '00

22 Feb '00

Graham Knight wrote: > I think i am running into bug 20270: > > "Outlook users get access is denied (or similar) errors" > > The bug report states the cifs.lvl2_oplocks_cap should > be turned off in order to fix the problem. I have > about to 8000 CIFS users and only a handful have had > this kind of problem. What are the ramifications to > my other 7990 users if I turn off level 2 oplocks > to fix the 10 users that are having the problem? > > Should i just ship the 10 problem users to an NT server? Hi Graham, The ramifications of disabling level-2 oplocks depend on what your clients are doing. In a nutshell: if your clients share files frequently with each other then you should expect to see an increase in file reads when you disable level-2 oplocks because level-2 oplocks tell clients that it's OK to cache reads locally. Level-2 oplocks only come into play when there are multiple file openers, so disabling level-2 won't do much if you don't share files much. For example, if you had multiple NT clients doing compiles on a shared source tree, level-2 oplocks would allow the clients to cache the source files, speeding up subsequent compiles. Outlook is affected by level-2 oplocks because it sometimes opens the same file more than once. Level-2 oplocks aren't supported by Win9x, so those clients won't be affected at all. Here's Microsoft's KnowledgeBase article on NT oplocks: http://support.microsoft.com/support/kb/articles/Q129/2/02.asp Bug 20270 is fixed in 5.3.4R3P1 (available now) and 5.3.5 (coming soon). Matt

1 0

9GB disks
by Jason Lavoie 22 Feb '00

22 Feb '00

About a year ago, we bought a filer (720) with a single FCAL shelf, populated with five 9gig drives. This was about all the storage we needed at the time (for mail spool storage), but knew we could just add a couple of extra drives if we needed more storage. Now, we are looking at adding another large customer (another ISP) to our mail system, and needed a bit more storage. Adding another 9gigs or so would be fine. So, I figured we'd just fill the shelf with drives, and be happy. Netapp tells me that I can't buy 9GB drives anymore. They've proposed upgrading to a new shelf full of 18GB drives, and trading in the existing shelf. Needless to say, the price is exorbitant compared to just adding a couple 9GB drives as we had expected. I'm looking for alternatives. Is anyone selling old 9GB drives for Netapp? If so, please contact me directly so we can work something out. Does anyone have any information on how/where to source non-Netapp drives that will work in our system? Can I use 18GB drives in this shelf (and only use the first 9GB of each)? I've gotten conflicting answers about this from Netapp. Any other ideas? TIA -j -- "What is the sound of Perl? Is it not the sound of a | Jason Lavoie wall that people have stopped banging their heads against?" | jason(a)mint.net --Larry Wall in <1992Aug26.184221.29627(a)netlabs.com> |

3 2

Clustering and the 1.4 TB limit
by Derek Kelly 22 Feb '00

22 Feb '00

I'm sure this question has been posted in the past, but since I've only recently joined this list, I'm going to ask for my own greedy benefit... It is my understanding that to perform cluster failover between two NetApp boxes, the sum total of served data between the two boxes must not exceed a 1.4 TB. Since the two F760's we wish to cluster both have 1 TB each on them now, I can only conclude that we will not be able to take advantage of clustering. I have heard that NetApp plans to change this in the not-so-distant-future. If anyone has any "insider" <grin> info on this situation (i.e., an ETA date) it would be very much appreciated since we have a fairly immediate need to get these boxes clustered. Please feel free to correct any of the assumptions I'm operating under if i'm wrong. Best Regards, Derek Kelly Computer Systems & Support Group Genome Therapeutics Corporation www.genomecorp.com

1 0

RE: question about databases on NetApps
by Mohler, Jeff 22 Feb '00

22 Feb '00

Dont forget that you get to see your family again..no more annoying tuning of filesystems for performance. -----Original Message----- From: Bruce Sterling Woodcock [mailto:sirbruce@ix.netcom.com] Sent: Tuesday, February 22, 2000 12:01 PM To: toasters(a)mathworks.com; Mike Kazar Subject: Re: question about databases on NetApps ----- Original Message ----- From: Mike Kazar <kazar(a)icubed.com> To: <toasters(a)mathworks.com> Sent: Tuesday, February 22, 2000 11:22 AM Subject: question about databases on NetApps > Or are you just running one database host, and using the NetApp to manage > the database host's disk space. This is what most people do (I think). > If so, what are the advantages you get > from using the NetApp for disk space management instead of just using a > local disk? Well, the disk space is centrally managed, so you get your backup all in one place. You also get RAID for reliability, and snapshots, and often you get even better performance than you do with local disks (despite theory which might suggest otherwise). And your database host is easy to redesignate as needed; you don't have a directly attached disk array that you need to migrate with it. And of course, unique to the Netapp, adding additional disk space as needed is a quick and painless. Bruce

1 0

level 2 oplocks and MS outlook
by Graham C. Knight 22 Feb '00

22 Feb '00

I think i am running into bug 20270: "Outlook users get access is denied (or similar) errors" The bug report states the cifs.lvl2_oplocks_cap should be turned off in order to fix the problem. I have about to 8000 CIFS users and only a handful have had this kind of problem. What are the ramifications to my other 7990 users if I turn off level 2 oplocks to fix the 10 users that are having the problem? Should i just ship the 10 problem users to an NT server? Looking for answers from those in the know. :-) Thanks, Graham

1 0

toaster config for Cricket
by Ronan Mullally 22 Feb '00

22 Feb '00

I'm in the process of setting up cricket (http://www.munitions.com/~jra/cricket) to monitor some of our network equipment. I'd like to include our toaster in this. Before I sit down and try writing up the configs myself, has anybody done this? If so, care to share the config tree? -Ronan

1 0

Moving from one NT domain to another
by Dani Tal 22 Feb '00

22 Feb '00

Did any of you toaster users have any experience with this ? I tried it yesterday and got cold fit in the middle. As a result I answered “no” to the delete computer account question , The filer proceeded and restarted CIFS with the old setup. The filer is in “coming up” status (On the GUI ) ever since. The filer looks normal, we have active CIFS shares etc. I did not like the idea of bring the filer CIFS down again before it completed the “coming up” status. Any Suggestions ? Is it really still “coming up” or just a GUI bug ? We are on release 5.2.1. P.S. after using the GUI to bring CIFS down we where unable to change the NT domain on the GUI. Best Regards , Dani Tal MIS Carmiel Information Systems and Technologies, SEABRIDGE Carmiel Site Newton House Industrial Area 5 , P.O.Box 323 Karmiel 21613 Israel Tel. +972-4-9953200 X 0403 FAX. +972-4-9888097 mail: mailto:dani.tal@seabridge.co.il <mailto:avi.ashkenazi@seabridge.co.il> Web: http://www.seabridge.co.il <http://www.seabridge.co.il>

2 1

Part numbers/source needed for F630 RAM
by marcotte＠panix.com 21 Feb '00

21 Feb '00

I need to buy third party RAM and NVRAM for our F630. Does anyone have part numbers (or sources)? Thanks! -- - Brian

1 0

Bug # 18641
by Jason Middlebrooks 21 Feb '00

21 Feb '00

What is Bug # 18641? I was told that was an internal bug and no ifo could be found on the now site. Thanks Jason

1 0

RE: FTP uploads from the UK (fwd)
by Nguyen, Alan 21 Feb '00

21 Feb '00

After about a month and a half of testing with customers like yourself, Network Appliance has a new FTP site. The new FTP site will be available for all of our customer's use beginning tomorrow (2/2/2000) at 6PM PST. The transition from the current FTP site to the new will be transparent and the FTP site will not have any downtime. Please read below for more details regarding architecture. Again, thank you for your patience. If you have any questions, please reply to me at anguyen(a)netapp.com <mailto:anguyen@netapp.com> Alan. Mgr., IT Server Ops Network Appliance -----Original Message----- From: Nguyen, Alan Sent: Thursday, December 02, 1999 10:49 AM To: 'toasters(a)mathworks.com' Subject: FW: FTP uploads from the UK (fwd) To All, First, I must apologize for NetApp's poor FTP site performance. The responsibility for this in my group. The situation is our internet connection is highly-utilized and thus your access to our FTP site is affected by this. Actions have been taken to increase internet bandwidth in the next few weeks. However, despite this, it will be superseded by our new FTP implementation. We have designed a new FTP site to improve security, system management, increase internet bandwidth/presence (i.e. ISP hosted site), and system redundancy. Because our current infrastructure is very out-dated, we have taken the "big-bang" approach rather than making incremental improvements. In a little more detail, our new FTP site is at a web-hosted site with 100MB bandwidth capacity vs current T1, and is configured with two fail-over dual-processor Unix systems with cluster fail-over (F760) Filer pair for storage. In short, the new site is very robust and will scale to meet to our customers' needs. What has been done thus far? Contract has been signed with new web-hosting site. Networking infrastructure is in place. Programming is complete for account and directory management. The new systems are racked at the new web-hosted site. As I type this, we are plugging in the cables for the new systems. What's the schedule? In the next two days, we will perform internal/external FTP tests. On Monday (Dec 6th), we will start live tests with customers assuming everything goes well this week. After which, the new site will go live. I will announce to this list when we are live. If you have any questions, please direct them to me anguyen(a)netapp.com <mailto:anguyen@netapp.com> or reply to this list as I will be joining this list soon. Again, thank you for your patience. Alan Nguyen Network Appliance Mgr., IT Server Operations

3 2

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

Jump to page:

2026

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