Veritas-bu

[Veritas-bu] /usr/openv placement

2001-10-09 13:58:58
Subject: [Veritas-bu] /usr/openv placement
From: Bob Bakh" <bob.bakh AT home DOT com (Bob Bakh)
Date: Tue, 9 Oct 2001 10:58:58 -0700
All of this is well and good, but my recollection is that VERITAS does not
support this config last time I checked.

Bob
----- Original Message -----
From: "Steve Dvorak" <sdvorak AT veritas DOT com>
To: "'David A. Chapa'" <david AT xbpadm-commands DOT com>; "Jeff Kennedy"
<jlkennedy AT amcc DOT com>
Cc: "Veritas-bu List" <veritas-bu AT mailman.eng.auburn DOT edu>
Sent: Monday, October 08, 2001 10:07 AM
Subject: RE: [Veritas-bu] /usr/openv placement


> I am not sure the NFS timeout thing is relevant.  There is typically a
> timeout of 10 minutes on an NFS mount (which I believe is tunable).  The
> reasons I would see for not using this approach:
> 1)  Performance.  I have a customer that NFS mounted their entire catalog
to
> a NetApp.  For backups it was fine.  The catalog searches were murder
> (because it has to traverse the catalog file structures).  Also, if
logging
> was turned on (and using the NFS mount as you propose) performance for
> everything suffered.  Don't forget you now have TCP/IP overhead and NFS
> overhead with a relatively small packet size.
> 2)  Reliability.  There are significant SPOFs in this design.  Many of
these
> can be eliminated if you design right.  I.e. multiple NICs (on different
IO
> boards), fast ether trunking (for high bandwidth), clustered NetApp
> (alright, so this may be extreme).  You will need extra CPU and RAM to
> handle the added NICs.
> 3)  Backups of Filer.  You will have to plan a separate file system for
NBU
> in order to ensure that backups of the filer don't conflict with the
catalog
> (similar issues with direct attached).
>
> Steve Dvorak
>
> -----Original Message-----
> From: David A. Chapa [mailto:david AT xbpadm-commands DOT com]
> Sent: Monday, October 08, 2001 9:27 AM
> To: Jeff Kennedy
> Cc: David A. Chapa; Veritas-bu List
> Subject: Re: [Veritas-bu] /usr/openv placement
>
>
> I may be wrong here, but NFS was designed originally as
> a connectionless protocol, meaning it was great for
> client applications because if there was a delay in
> response due to network traffic it wouldn't cut you off
> but merely wait and wait and wait.  That's great.
>
> In a NBU environment if that should happen, it
> potentially hang and hang until failure occurs and a
> blocking of your backup window.  Ultimately you will
> pay the price of incomplete backups.
>
> Alternatively, one may use hard mounts (as I know them
> to be called) which will NOT wait when a NFS filesyetem
> should become unavailable, but will terminate the
> connection.  This will potentially result in data being
> written to the mount point and not the NFS filer you
> want it to.  I have had to work through this with one
> of my clients about four years ago, it wasn't pretty
> and much of the data they were trying to recover wasn't
> recoverable for one reason or another.
>
> That's why I'm not a fan of NFS and NBU sharing space
> but would rather see it direct (or nearly direct)
> attached.
>
> Just my opinion...and yes, I have thought this through
> and still don't feel comfortable with it.  Thanks for
> asking. ;-)
>
> David
>
>
> Quoting Jeff Kennedy <jlkennedy AT amcc DOT com>:
>
> > Ok, so why?  We run numerous EDA applications from a
> filer and have no
> > issues with that, why would NBU be any different?
> And when you add the
> > management and functionality bonuses I mentioned I
> would think it would
> > be a prefered method.  I'm not slamming, I just want
> your reasons (to
> > make sure you've thought this through...;-])
> >
> > ~JK
> >
> > "David A. Chapa" wrote:
> > >
> > > I like NetApps for certain applications, NBU is not
> one of them.
> > >
> > > My opinion is that I prefer direct attached storage
> (or nearly direct)
> > for
> > > NBU, NFS doesn't qualify in either camp.
> > >
> > > I'm sure its been done and done successfully, I'm
> just not a fan of it.
> > >
> > > My two cents.
> > >
> > > David
> >
> > > -----Original Message-----
> > > From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> > > [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On
> Behalf Of Jeff
> > > Kennedy
> > > Sent: Friday, October 05, 2001 1:58 PM
> > > To: Veritas-bu List
> > > Subject: [Veritas-bu] /usr/openv placement
> > >
> > > I am contemplating putting the entire /usr/openv
> partition on a NetApp
> > > filer.  My reason is that currently my images
> directory is 68gb's, and
> > > this is not yet including the new filer I am adding
> nor the 5 Novell
> > > servers that will be added in the next week or so.
> Once that happens I
> > > will be looking at much more then 68gb's for
> images.  I do not want to
> > > have to waste time backing up this data every time
> a scheduled backup
> > > finishes, plus it wastes tape when I'm sending them
> offsite every week.
> > >
> > > What I'm planning is to have all the NBU stuff on
> the filer and
> > > snapmirror that data to a remote site.  This way I
> can recover
> > > completely to another site in case of total
> disaster, or I can
> > > snapmirror the entire structure back here if
> needed, or I can just copy
> > > back the images I need.  My WAN pipe between these
> sites is big enough
> > > that the difference in recovering from an offsite
> db backup and
> > > snapmirroring the entire structure back is
> negligable.
> > >
> > > Any thoughts, opinions, experiences?
> > --
> > =====================
> > Jeff Kennedy
> > Unix Administrator
> > AMCC
> > jlkennedy AT amcc DOT com
> >
>
>
>
> <><><><><><><><><><><><><><><><><><><><>
> David A. Chapa
> Consulting Manager
> DataStaff, Inc.
> 847 413 1144
> http://www.consulting.datastaff.com
> ---------------------------------------
> http://www.xbpadm-commands.com
> NBU-LSERV AT datastaff DOT com - Adv. Scripting
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>


<Prev in Thread] Current Thread [Next in Thread>