A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Storage & Hardrives
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

nav vs san



 
 
Thread Tools Display Modes
  #11  
Old February 8th 07, 05:14 PM posted to comp.arch.storage
Faeandar
external usenet poster
 
Posts: 191
Default nav vs san

On Thu, 08 Feb 2007 11:17:03 -0500, Andrew Gideon
wrote:

On Sat, 03 Feb 2007 16:26:47 -0600, Moojit wrote:

Please remember most NAS devices have SAN's on their backend running fibre
channel. If you want an appliance that serves up filesystems, then the
NAS is the way to go. If performance and block data are top on your
priority list, a 4G fibre channel front end is the way to go.


Are there NAS devices which support NFSv3 using ACLs (compatible with
Linux and Solaris)? Or even NFSv4 with its "optional" but more standard
ACLs?

- Andrew


NFSv4 does not yet support POSIX ACL's, that is slated for 4.1.

For v3:
I'm not aware of any NAS *devices* that support ACL's over NFS but if
you are a nearly homogeneous shop (say mostly Solairs or mostly Linux)
using them as NFS servers will allow for ACL's.

I know it works for Solaris to Solaris and I'm almost certain Linux
works with itself as well. However you cannot mix Solaris and Linux
and have ACL's work.

In case that wasn't clear, Solaris clients accessing a Solaris NFS
server can use ACL's over NFS. Linux clients accessing that sam
Solaris NFS server cannot.

~F
  #12  
Old February 9th 07, 05:31 PM posted to comp.arch.storage
Andrew Gideon
external usenet poster
 
Posts: 3
Default nav vs san

On Thu, 08 Feb 2007 17:14:27 +0000, Faeandar wrote:


For v3:
I'm not aware of any NAS *devices* that support ACL's over NFS but if you
are a nearly homogeneous shop (say mostly Solairs or mostly Linux) using
them as NFS servers will allow for ACL's.


That's the approach we've been taking: a SAN behind a Redhat GFS cluster.
But a single "box" solution would be convenient.

I know it works for Solaris to Solaris and I'm almost certain Linux
works with itself as well. However you cannot mix Solaris and Linux and
have ACL's work.


We do that in both directions, and it works.

- Andrew

  #13  
Old February 9th 07, 07:47 PM posted to comp.arch.storage
Faeandar
external usenet poster
 
Posts: 191
Default nav vs san

On Fri, 09 Feb 2007 12:31:38 -0500, Andrew Gideon
wrote:

On Thu, 08 Feb 2007 17:14:27 +0000, Faeandar wrote:


For v3:
I'm not aware of any NAS *devices* that support ACL's over NFS but if you
are a nearly homogeneous shop (say mostly Solairs or mostly Linux) using
them as NFS servers will allow for ACL's.


That's the approach we've been taking: a SAN behind a Redhat GFS cluster.
But a single "box" solution would be convenient.


What are your thoughts/opinions/experiences with GFS? I did some
research on them and found them tobe trailing other products so left
them out of evals.


I know it works for Solaris to Solaris and I'm almost certain Linux
works with itself as well. However you cannot mix Solaris and Linux and
have ACL's work.


We do that in both directions, and it works.


So you're saying Linux clients to Solaris NFS server can still use
ACL's?

~F
  #14  
Old February 11th 07, 03:28 PM posted to comp.arch.storage
SANweaver
external usenet poster
 
Posts: 1
Default nav vs san

To reply to the original question, the answer really needs to be
derived from what you want the storage for?

Some folks believe that NAS is a ton easier to manage than SAN, but
that is not always the case anymore.
In a nutshell, NAS is more flexible and easier to manage than
SAN...mostly because all shops have an IP savvy guy or dept. already
and cutting over to FC would make some waves...it is in fact what
scares most people up and above the excess costs to engage. On that
note, there is also protocols like iSCSI that might address the best
of both worlds for plenty of shops. Used to be considered an SMB
play, but we are seeing plenty of enterprise opportunities where iSCSI
is a better fit than NAS.

I disagree with some of the statements, as I can do MUCH BETTER
consistency at the block level than you can achieve with file level,
although it is true that some features do require file level access to
properly manage/manipulate...IE: CAS, ILM
I can recover an Oracle DB or even your entire exchange environment
back to the last snapshot in minutes...with no replaying journal logs,
etc.

Although many h/w vendors do not have the right tools bundled to take
care of things the way most folks would want, the software/middleware/
appliances can certainly fix that problem.

You need to understand your performance requirements, the application
purpose and its availability requirements to properly justify which
you need.

If performance is not an issue and you want easy management and
flexibility, then buy a SATA-to-FC storage array with built-in RAID,
direct connect it to your application box(s) in FC point-to-point
manner with HBA(s) installed in the box(s) and run from this model.
If your purpose is to have a file server, then enable your NFS/CIFS
NAS Head capability from the server itself. If you outgrow this and
keep moving forward, you can always cut the architecture over to a
fabric model, but no need to build a "SAN" if you only have a single
starting purpose.

Many of the vendors arrays can do multiple snapshots per LUN and run
RAID6 with dual-parity and hot-spare and with the size of the drives
available and perpendicular performance, I think you will find what
you need with SATA...in fact the right box can run oracle DB's with a
SATAII/perp drive config with multi-spindle SAS backplaned 4Gb FC
output configs...IE: Any SATA-to-FC storage array that has a switched
non-shared backplane, which most use SAS to interconnect.

My 2 Cent$

Cheers, Bill














On Feb 2, 5:32 pm, wrote:
I know this is a broad question, but here goes...

If performance were not an issue, what is better to stick to in an
enterprise.... NAS or SAN?

What is generally more flexible and easier to manage?

Dvy



  #15  
Old February 21st 07, 07:20 AM posted to comp.arch.storage
[email protected]
external usenet poster
 
Posts: 1
Default nav vs san

On Feb 3, 3:32 am, wrote:
I know this is a broad question, but here goes...

If performance were not an issue, what is better to stick to in an
enterprise.... NAS or SAN?

What is generally more flexible and easier to manage?

Dvy


...Hi Dvy,

Its better to have a NAS than SAN, if performance is not so important.
Infact, SAN costs much than a NAS.
I think its better to have a NAS with fault tolerance configured and
with regular data back up, would do..

Thanks,
Edwin..

  #16  
Old March 22nd 07, 02:06 AM posted to comp.arch.storage
Rick
external usenet poster
 
Posts: 3
Default nav vs san

The question is not only a performance one, it is also the type of data that
is being accessed as well. You will usually find databases on DAS or SAN
unless it has fairly low transactions. NAS is usually more for file/print
type data. iSCSI is an alternative to SANs and the cost is somewhere in
between.

This is a broad question and you really need to look at the applications
that are running the business. Once you know the applications and understand
their requirements, you can then design a SAN that is best suited for the
business

Regards,

Rick
wrote in message
oups.com...
On Feb 3, 3:32 am, wrote:
I know this is a broad question, but here goes...

If performance were not an issue, what is better to stick to in an
enterprise.... NAS or SAN?

What is generally more flexible and easier to manage?

Dvy


..Hi Dvy,

Its better to have a NAS than SAN, if performance is not so important.
Infact, SAN costs much than a NAS.
I think its better to have a NAS with fault tolerance configured and
with regular data back up, would do..

Thanks,
Edwin..



 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:09 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.