1

Hello,

Firstly let me say that I don’t know anything about SAN or iSCSI, but I intend to start testing.

Say I get an iSCSI storage box and link it to a server by 1 gigabit ethernet, then I initiate it by connecting to the required target LUN and it shows up as a local disk on the server. Say this server is a DC and has local hard disk(s) just for hosting the OS and then stored on the SAN iSCSI LUN are peoples home drives/my documents folders. A user on a workstation wants to copy a 1GB video file from his home drive to his (local) desktop. When this copy takes place, does the data move from the SAN, down the cable to the Servers NIC, the OS then tells it that the destination is the workstation, so it goes back out to the switch, then to the workstation, or does it go straight from the SAN to the workstation? This might be a silly question, I don’t know. If the data were to move straight from SAN to workstation, would not all devices have to be aware of this config including the workstation? Or perhaps iSCSI and FC devices have some kind of routing table so it knows where to send data straight without having to go via the server (once all the file system processing, permissions etc, has been completed by the server)?

Does any of this change if the server OS software is on the SAN also, ie. if the location where the OS receives the request for a data copy is the same as the location of the stored data, why would it have to go back into the servers NIC?

Thanks.

5 Spice ups
2

The client talks to the server, the server talks to the storage.

I don’t quite understand your second question about “if the server OS software is on the SAN also”?

3

To my understanding, iScsi replace your disks link to your host server. So everything will go through the nic if any read-write operation is called.
Local disk connected with the motherboard via their own card which could be sata, sas, or whatever. iScsi replace these link.
But keep in mind is not share-able protocol like cifs or nfs, it is just local disk that connected with network cables, so sharing is different and even dangerous at some point.
For files, you better discard iScsi and use file sharing protocol.

4

But could it not go straight from the SAN to the workstation?

5

iSCSI is just a transport method- you define your targets on your storage box, and use your initiator to connect to it. the initiator presents it to your os as just another scsi disk, and the os treats it as such. of course you can make this as complex or as simple as you want, but ultimately you’ve just replaced a cable with a tcp/ip connection.

Yes, but you have to install and configure the initiator on the workstation. Remember, the storage you provision on the SAN is just a bunch of blocks- it looks like a regular stand-alone disk to whatever connects to it. You want shared storage like a NAS? connect that disk to your filesever, let the file server treat it like a disk and share out the contents.

Concurrent access to a single target is a bad idea unless you are using a clustered filesystem. If the filesystem and the system’s involved can’t understand shared access to a single volume, don’t let more than one machine access that volume.

If all you are after is shared file access, don’t use a SAN. use a NAS, that’s what it’s for.

http://www.smbitjournal.com/2012/08/choosing-a-storage-type/

and

http://community.spiceworks.com/topic/245832-what-is-a-san-nas-das-and-dasan

2 Spice ups
6

Yeah, what Magnus said^^, backed up with my experience connecting two servers to the same iSCSI target during testing and causing data loss.

7

I also agree with Magnus. NAS is cheaper and much easier to configure. Also think about VPN if you do go NAS.

8

NAS and SAN aren’t better or worse, faster or slower, cheaper or more expensive - they are just two competing protocol families. Normally they come on the same devices (ergo, same price) and if you really want to get technical, SAN gets cheaper (like $20) compared to NAS (cheapest is $279.) But it is just a matter of block device vs. file device.

It’s like JPEG and GIF, which is cheaper? Any software that makes one likely makes the other.

1 Spice up
9

Here is a video from SpiceWorld that might help to explain SAN:

http://www.spiceworks.com/tv/?cat=spiceworld&video=SW-10-open

1 Spice up
10

Sure if you deploy a redundant parallel network to you existing LAN to do so with. Running iSCSI over the LAN is considered a bad idea. Also ONLY that workstation would be able to talk to that LUN on the SAN or else you’ll corrupt the data.

11

Thanks for your replies. Going to watch that video now.

I guess what I’m saying is, is there (or possibly will there be) a way that the SAN can talk to all the networked devices without going back down the wire to the OS server. I understand now that this isn’t done as it causes problems and only one device should be attached to a LUN. But as far as I can tell it would reduce a lot of network traffic if there were perhaps a protcol in place on SAN devices, servers and maybe switches that could direct the required data directly from the SAN to the workstation with passing through the server first, this all being done while the LUN would only be attached to the server so as to avoid the problems described above.

12

After watching the video, perhaps what I meant is could multiple devices read and write at block level (think the answer at present is no). I guess the solution to that is NAS but then I’ve had problems getting them to work with domain permissions so mainly use them as backup devices or public shares.

13

Great way to test on the cheap is to run iSCSI Initiator on a desktop and FreeNAS or Nas4free on another workstation. That was my first foray many years back.

14

PPC, what NAS are you trying to use that it will not work with AD? There are a number of NAS’s that will and a lot that will not. Most higher end ones licensed the SMB spec back in the day to make it work. Some new ones running samba can handle it.

Also for NAS why not just run Windows 2012?

15

To simplified the sharing confusion, would you share local drives with another computer as a local drive too? It will be absurd. You share on file level not block level.

16

Please consider what a previous user posted about seperating the iSCSI traffic off of your LAN…

This might give you a better understanding of how it actually works. If your AD server does not already have a second NIC, add one. Connect that NIC to the SAN directly instead of going through the LAN switch. Then your iSCS triffic will be isolated.

For the network guys: I know that direct connect is not the best means to do this but the correct way would involve another switch or at least creating a VLAN on the current switch if that was possible. This is for reasons of buffering for one, but out of scope for this article.

So yes, now the server is the only thing with access to the iSCSI SAN and requests are made from the server and the server handles the SAN like a local disk from this point on.

17

Dirrect connection iSCSI actually performs better than through a switch. our office/lab QNAP has a direct connection to one of office VMhost. True if you have a non-blocking switch it about the same, but in theory direct can be better if your not MPIO.

18

Direct is actually recommended.

VLANs are not recommended. Those are the bane of networking. They fool people into thinking that they’ve gotten the performance of a new switch but they haven’t.

19

iSCSI is a way of sharing something that looks like a raw disk drive over a network. It actually can be just a disk drive, by the way. If multiple computers have peer read/write access to a disk drive as block storage simultaneously, you get corruption.

I think the best way to think about it is having the SAN connected to a completely different network, that only the server and the SAN are on. That’s actually the best way to physically configure it too.

Then the question becomes superfluous. The SAN and workstation aren’t connected to the same network, so it’s not possible to consider. If they were connected, it’s actually a problem, as you have to ensure that only the server in question accesses the LUN in question (or else, corruption).

2 Spice ups
20

The question becomes, why are you trying to implement a SAN? What you want is called a file server and/or NAS. SAN isn’t the technology that does this. SAN isn’t something that you ever want, it is something that you get stuck with. Never approach storage from a “let’s use a SAN and see were it fits” standpoint.