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
|
