3

I am using Windows Server 2008 Enterprise with SQL Server 2008 Enterprise. I am considering whether using SAN or using NAS is better to store database data files. Are there any industry readings to compare whether NAS or SAN is better for database storage scenario?

Besides my database storage scenario, any industry readings to compare SAN with NAS to see which technology is better suitable for which scenario?

thanks in advance, George

George2
  • 1,137
  • 6
  • 22
  • 41
  • 2
    SMB does not support locking semantics required by database management systems. Database volumes on SMB shares do not work at all. SMB based NAS is a non starter for this application. – ConcernedOfTunbridgeWells Jul 01 '10 at 14:12
  • 1
    By contrast, note that NFS does support the appropriate locking semantics and Oracle on NFS shared volumes does work. You can even find white papers about it on Oracle's web site. – ConcernedOfTunbridgeWells Jul 01 '10 at 14:13

2 Answers2

8

We had your previous question on this subject yesterday and it's pretty conclusive that even IF you can get SQL to store it's data via NAS protocols such as SMB/CIFS or NFS it's a really bad idea!

So that should discount using SMB/CIFS and NFS from the equation, let's look at the other options.

If there's no need for clustering then most people would agree that suitably well spec'ed local (Direct Attached Storage - DAS) with the right RAID level is the best both interms of performance and value.

If you are clustering then you need a block-level SAN/NAS system (you may also just want the snapshotting features some of these arrays offer too of course) - these are typically Fibre-Channel (which uses a dedicated storage-tuned network, is very fast and performance-consistent - but expensive), iSCSI (which uses standard ethernet networks, is generally slower than FC but is often 'fast enough') and the kinda-hybrid Fibre-Channel-over-Ethernet (which is a nice, but very new, compromise between FC and iSCSI).

Generally large organisations who rely on their DBs use FC and would only use iSCSI for less important work; for small organisations iSCSI can ofen provide perfectly-adequate performance for much better value (and less complexity) than FC - 5-10 years from now FC will be dead once FCoE has matured.

Hope this helps.

Chopper3
  • 101,299
  • 9
  • 108
  • 239
  • 1
    +1 - SQL server volumes on SMB shares are known not to work. – ConcernedOfTunbridgeWells Jul 01 '10 at 14:11
  • 1
    @CoTW - apparently they can *just* about be fooled into working but it's a super bad idea and is almost certain to fail pretty soon. This user asked a similar question yesterday - I have a horrible feeling he's bought a NAS for the job *gulp* – Chopper3 Jul 01 '10 at 14:14
  • 1
    Just to be a bit more precise, a SAN always export a block device, instead a NAS export alwasy a file level storage (a file system - think about NFS, SMB). – PiL Jul 01 '10 at 14:16
  • 1
    @Pier - If that's true, what about NAS devices that can present LUNs via iSCSI? Where do those fit in? – EEAA Jul 01 '10 at 14:25
  • 2
    Maybe 'Known Anti-Pattern' would be a better description. Some years ago I saw a white paper from Oracle on the subject - NFS locking semantics will support database volumes correctly but SMB will not. Maybe you can get SQL Server to do this, but Oracle (at least) flat out state that SMB is not up to the job. – ConcernedOfTunbridgeWells Jul 01 '10 at 14:25
  • @ErikA - it's simply a mixed device that can act as NAS or SAN, as wikipedia call them hybrid devices. I was using them for example making a box with opensolaris and export iscsi and nfs shares. – PiL Jul 01 '10 at 14:33
  • @ConcernedOfTunbridgeWells - actually oracle is pushing storage via NFS. Look at some paper on google that describe how to obtain many hundreds of thousands IOPS via NFS (http://blogs.sun.com/brendan/entry/a_quarter_million_nfs_iops) – PiL Jul 01 '10 at 14:35
  • @Pier - I fully agree that Oracle can work fine on NFS, MSSQL doesn't support it though - not sure how it'd deal with load or clustering however. It's a value-proposition for them, they're not suggesting people move from FC to NFS. – Chopper3 Jul 01 '10 at 14:39
  • @Chopper3 - my comment was about a general idea that a DB cannot work with a NAS. MSSQL probably won't work well with it – PiL Jul 01 '10 at 15:29
  • I don't think anyone stated that *A* database couldn't work with a NAS, just that MSSQL doesn't (not with stability or support anyway) – Chopper3 Jul 01 '10 at 15:31
  • @Chopper3, could you provide some document to suppor your points please? – George2 Jul 01 '10 at 17:00
  • @Pier, what are the differences between a block level storage and a file level storage? Could you provide some document to support please? – George2 Jul 01 '10 at 17:02
  • @George2 - is google/wikipedia broken today? This is all common knowledge. – Chopper3 Jul 01 '10 at 17:20
  • @George2 - wikipedia is enough. I had some pretty good book from emc2 (unfortunately i lost it..grrr) that explained them pretty well. If you want the name is: The Information Storage and Management – PiL Jul 01 '10 at 18:03
1

I wouldn't expect so - they are very different products aimed at different markets. SAN at the top end, NAS at the bottom end.

Although recently it has become feasible to use NAS for database storage (but probably only with iSCSI over 10Gb ethernet) I'd recommend staying away from it and using fibre or SCSI attached storage.

C.

symcbean
  • 21,009
  • 1
  • 31
  • 52
  • 4
    Whether a storage device is a SAN or NAS does *not* put it into the "top" or "bottom" end. There are very good and very poor devices of each class. The only definitive difference between a NAS and SAN is that (typically) NAS devices serve at the file level, while SAN devices serve up block level. That said, there are many devices out there now that do both, so the line between NAS and SAN is getting blurred. – EEAA Jul 01 '10 at 14:04
  • 1
    Agreed, NAS topologies aren't best suited for DB type stuff. iSCSI falls under the SAN category though, doesn't it? – churnd Jul 01 '10 at 14:06
  • 1
    @churnd - typically yes, though I'd argue against the notion that the OP would *need* 10GB Ethernet in order to run iSCSI. It completely depends on the workload. There are *many* companies I know of that are running their SQL DBs very happily over iSCSI/1GB. – EEAA Jul 01 '10 at 14:08
  • 1
    Erik - I'd contend that a NAS is more about usage over a shared network, although your block/file argument is also an important one - I guess we have a little boundary-blurring right now :) – Chopper3 Jul 01 '10 at 14:10
  • 1
    @Chopper3 - yes, that's an important distinction as well, though as you mentioned, iSCSI throws a wrench into that... – EEAA Jul 01 '10 at 14:17
  • 1
    Generally it's helpful to view SAN as a block protocol (FC, FCOE, iSCSI) and NAS as a file oriented protocol (CIFS, NFS) for the purposes of this type of discussion (Clariion==>SAN, Celerra==>NAS). This is normally the distinction that I use to differentiate them. – ConcernedOfTunbridgeWells Jul 01 '10 at 14:27
  • 1
    @ErikA you wouldn't run iSCSI over your shared network though – JamesRyan Jul 01 '10 at 15:17
  • @symcbean, could you provide some document please? – George2 Jul 01 '10 at 17:00
  • @ConcernedOfTunbridgeWells, what are the differences between a block level storage and a file level storage? Could you provide some document please? – George2 Jul 01 '10 at 17:03
  • @EK, could you provide some document to support your points please? – George2 Jul 01 '10 at 17:04
  • @ErikA, could you provide some document to support your points please? – George2 Jul 01 '10 at 17:04
  • @churnd, could you provide some document to support your points please? – George2 Jul 01 '10 at 17:04
  • 1
    look here for storage information and strategies http://www.snia.org/education/ on the left is the "snia tutorials" – tony roth Jul 01 '10 at 17:08
  • 1
    Take a look at the wikipedia pages for 'Storage Area Network' and 'CIFS' This should explain the basics. – ConcernedOfTunbridgeWells Jul 02 '10 at 06:55