Why the DAS? *LONG*
I'm sure this is a real noob question, by why use the DAS front end server? Why not just connect the SAN to the Gigabit network and access it directly?
It seems like if the DAS is connected to the network by Gigabit, then that is going to be the bottleneck, and the fact that you can get the data from the SAN to the DAS front end faster than it can be pushed over the network is kind of irrelevant and overkill.
Not sure what the question here is, why not run the Old Shuck as a NAS? or Why not run iSCSI to each node instead of FC? or What is compelling about a SAN?
I think I deal with these in the article, but let me try to address them for you here, first rephrase the two possible questions you might have.
Question One, Why not run as a NAS, why go to the trouble of running a SAN?
Question Two, Why not run as a shared SAN using iSCSI instead of as fiber with a DAS?
If what you are asking is why not run it as a gigabit NAS - it wouldn't be a SAN, it would share the filesystems and not the block devices. The primary reason is that I can get better performance by running a < SAN to DAS > as a logical NAS, versus running it as a physical NAS. There are several reasons why this is, one is the simple reason that I have more asymmetric processor oomph behind the storage ( take a look at the benchmark of just a hitachi drive), the other has to do with reducing the layers between the storage and its delivery. The third is how ultimately my SAN is going to be used.
Generally NASes run Linux, in most homes they serve data to Windows boxes. This means that your wire requests have to be translated to the native filesystem ( using Samba ), there is cost in doing that, and you need processor cycles to both serve the storage and serve the requests. A SAN doesn't do that - A SAN is like a Wankel engine, it doesn't need to translate the up & down into rotational energy, a SAN deals with SCSI requests on the sparse wire, which don't need translation. The DAS server maintains the filesystem, the SAN just serves up storage - the labor is nicely divided.
Depending on how you use your SAN this can be a big deal, you have a 4Gb pipe with little overhead (unlike TCP/IP), if I connect my SAN to my HTPC ( use my HTPC as my DAS server ) I can easily get over three plus times the performance of a NAS, when serving large video files ( rip & read ). This is how I'll be using my SAN.
The extra processor muscle of the DAS server, beyond that of fewer layers, means that it can serve the NAS requests about 10-20% faster than just the machine, Ol'Shuck, as a NAS.
This is the question about owning a Porsche versus a Ford Focus. Both provide transportation, and reliably get me to work and back. One does it with both performance and style, the other doesn't. My article shows how you can have a Porsche on the cheap. How compelling is a Porsche to you?
Now if the question is the second one, why not just share the SAN using gigabit networking via iSCSI to each node, that is a different question entirely. The reason why is that you can't... not easily anyway.
I'm using NTFS as the filesystem on my LUNs, which are served by the SAN. NTFS is not a shared filesystem, this means that if I want to share the block storage I need a different FS. With NTFS I can only provide the storage to one server, I can't share the storage throughout the network. To do that I need a shared block filesystem.
Right now, as far as I can tell, there is only one way to share storage with Windows from a SAN running free software ( there are a bunch of pay for solutions, HP and Oracle have two of the largest ). And that, as mentioned in another post, is via ESXi which provides a shared block filesystem ( single instance under the OS shared by each VM). I need to virtualize an Openfiler install for each client I want to share the storage with. For me that would be four VMs. (with the corresponding overhead). I plan on looking at that in another article/series, on multipathing (fc and iscsi) and shared iscsi.
Even in this scenario I probably wouldn't serve storage much faster than with my logical NAS, I'd incur the VM overhead, and the reduced payload of tcp/ip ( versus FC ), and it would be a pain to admin, new node? new VM - but it would be interesting to see.
Beyond all of these reasons, writing an article about building a NAS has been done, over and over. I'd really have nothing new to say. The new thing here is to show you can do high performance fibre channel on the cheap (which was not a sure thing when I started this series).
As to overkill, a question I anticipated, ever see The Exorcist in an altered state?
