iSCSI SAN experts, help needed.

[SnOop005]

Hello,

My work is venturing into the idea of implenting Citrix for server virtualization so naturally having a SAN storage fits the picture quite nicely. They do not have $10,000+ for an NetApp or Equallogic so my only option is to build one using SAN appliance software like OpenFiler or Nexentastor. I tested Nexentastor and got everything working under Citrix and phyiscal server environment. Through some initial testing I found that if mutiple computers/servers connect to the same LUN on the SAN it doesn't see the same drive, in other words when server A and server B both are connected to the same LUN if I put some data on server-A, I will not be able to see it on server-B. This raised the question for me of how I can reconnect to the "same" drive and see all the data if for instance server-A suffers from a hardware failure and is require to format/reinstall Windows how can I connect to that same session as before so I can get all my data back. I'm probably missing some fundamental logic on this so any help is greatly appericated!

 

[RebateMonger]

Unless you have cluster-aware software, it's not intended for multiple PCs to see the same SAN virtual disk. The SAN itself can't handle multiple computers accessing the same data at the same time.

As far as accessing the data with a different server, I don't remember all the details, but I've built brand-new Windows servers to replace an old one and have accessed a SAN virtual disk previously used by the old server just fine.

 

[Mark R]

An iSCSI target is basically just a virtual hard drive. You can't connect a single hard drive to multiple PCs, and have ut work (*). There is no mechanism for one computer to be notified of changes to the data, like there is with a file server CIFS or NFS share.

As a result, only one client (initiator) can connect to a LUN at a time, unless the LUN is read-only (no data sync issues). Some SANs may allow multiple connections in r/w mode, but the initiators will need to handle synchronization themselves, using some sort of clustering software like SANergy (which can be obtained, at huge expense, from the SAN vendor).

You are missing the point of iSCSI. It's not a shared data environment, it's an alternative way of hooking a server up to a bank of hard drives. You could do it using SCSI cables, or fiberchannel but ethernet goes a longer distance and is cheaper - and by using a 'virtual' drive which is part of a larger array, you make management easier - need more storage, just allocate more space to the virtual drive, etc.

(*) - Well, you can, sort of. I once connected an external SCSI hard drive to 2 computers. Just daisy chained them all together. Both computers would detect the hard drive at boot, and would boot from the same drive. It all went horribly wrong once the OS came up though, as one comp would change something on the drive (like the swap file) and the other comp would read it back, and crash.

It seemed to work fine after partitioning the drive into 2 partitions - and having each computer use its own partition. Never really tested it properly though, because it was a completely stupid idea.

 

[Emulex]

clustered storage is important for hypervisors - very near zero low end products handle lun sharing well. hell most $10K products - the rule is to always thick provision and keep 1 pc per lun. otherwise you end up having massive iscsi locks.

I assume you mean using multiple hyper-v/xen virtual/vsphere HOSTS to connect to multiple individual images for virtualized systems. (VDI?)

 

[SnOop005]

An iSCSI target is basically just a virtual hard drive. You can't connect a single hard drive to multiple PCs, and have ut work (*). There is no mechanism for one computer to be notified of changes to the data, like there is with a file server CIFS or NFS share.

As a result, only one client (initiator) can connect to a LUN at a time, unless the LUN is read-only (no data sync issues). Some SANs may allow multiple connections in r/w mode, but the initiators will need to handle synchronization themselves, using some sort of clustering software like SANergy (which can be obtained, at huge expense, from the SAN vendor).

You are missing the point of iSCSI. It's not a shared data environment, it's an alternative way of hooking a server up to a bank of hard drives. You could do it using SCSI cables, or fiberchannel but ethernet goes a longer distance and is cheaper - and by using a 'virtual' drive which is part of a larger array, you make management easier - need more storage, just allocate more space to the virtual drive, etc.

(*) - Well, you can, sort of. I once connected an external SCSI hard drive to 2 computers. Just daisy chained them all together. Both computers would detect the hard drive at boot, and would boot from the same drive. It all went horribly wrong once the OS came up though, as one comp would change something on the drive (like the swap file) and the other comp would read it back, and crash.

It seemed to work fine after partitioning the drive into 2 partitions - and having each computer use its own partition. Never really tested it properly though, because it was a completely stupid idea.

Thanks for the all the pointers! You guys are right, after spending some more time on it it works just like a locally attached drive and I'm getting the grasp of things. I was able to connect to the same LUN and have access to the same data from another server after detaching it from the original server, meaning in the event of server failure I can always hook the LUN to another server and be able to see all the data. This is all I want to be sure of. I don't plan on sharing the LUN but just needed to make sure I can recover my data incase one of my server goes down. This brings another issue, if the SAN Storage itself suffers from a hardware failure will I be able to move all the hard drives and RAID Controller to a replacement and expect it to boot up and retain all of its RAID and storage configuration? I plan on using OpenFiler as my appliance OS.

Emulex: I'm starting from server virtualization with Citrix XenServer first then eventually we will move on into doing VDIs using XenDesktop.

Thanks guys!