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. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|