StarWind Software

Does the ImageFile method incur a performance hit compared to a more "direct" method such as DiskBridge or SPTI?

Yes. B/c it allows caching. DiskBridge does not. SPTI is serialized by MS design so is definite performace killer (that's why we've DISABLED it for hard disks).

tulsaconnect wrote:Does the ImageFile method incur a performance hit compared to a more "direct" method such as DiskBridge or SPTI?

Ok, so you are saying that ImageFile is the best performing method for StarWind iSCSI target, correct?

When I did some informal benchmarks using an ImageFile "looped back" to the same machine (Win2008 using the MS iSCSI initiator) via HD Tach, I was seeing much slower performance (120MB/s) out of the ImageFile device than "direct I/O" (around 630M/s) against the same RAID array that the ImageFile was sitting on (RAID is an Areca ARC-1160 w/1GB cache RAM).

Don't test anything in a loopback. Ever.

Well, we tested it in looped back mode since we wanted to *use* it that way in production. I'm guessing based on your response that doing it that way in production is not recommended either?

You'll have double buffering for I/O (waste of system memory), lots of CPU cycles lost b/c both target and initiator will work in the same machine, bad latency and so on.

And from what you've told it's absolutely not clear what you really want to do. I mean - what task are you going to solve.

Well, we have (2) Dell 2900 servers running Hyper-V with lots of direct attach storage in each (4TB per box). Essentially I want to use StarWind for the block-level replication features -- create a large ImageFile iSCSI target on the "D:" drive (4TB direct attach storage) and place my Hyper-V .VHD files in that. Then, I use StarWind to replicate that ImageFile the 2nd server (at another Data Center connected via a Gigabit link). If the 1st server ever goes down, I just fire up the VMs on the 2nd server.

Is there a better way to do what I want given the above information?

Yes. Use dedicated machine providing shared iSCSI storage for both physical nodes. Hyper-V is basically a cluster.

anton (staff) wrote:You'll have double buffering for I/O (waste of system memory), lots of CPU cycles lost b/c both target and initiator will work in the same machine, bad latency and so on.

And from what you've told it's absolutely not clear what you really want to do. I mean - what task are you going to solve.

I read with interest your new "StarWind Native SAN for Hyper-V" two-node cluster offering, which is in essence exactly what I was proposing to do way back when. So, I'm curious -- what exactly did you do with this new version that eliminated the technical reasons why you said NOT to do this in the past?

I was an idiot.

tulsaconnect wrote:

anton (staff) wrote:You'll have double buffering for I/O (waste of system memory), lots of CPU cycles lost b/c both target and initiator will work in the same machine, bad latency and so on.

And from what you've told it's absolutely not clear what you really want to do. I mean - what task are you going to solve.

I read with interest your new "StarWind Native SAN for Hyper-V" two-node cluster offering, which is in essence exactly what I was proposing to do way back when. So, I'm curious -- what exactly did you do with this new version that eliminated the technical reasons why you said NOT to do this in the past?

Love your answer, we all got a good laugh here at the office

But in all seriousness, regarding the new version due out next month -- are there any technical changes that optimize for this scenario (2 node, iSCSI target on the same box as the iSCSI initiator), or is it more of a licensing-only type change?

Obviously it's not only license change. Both StarWind and Microsoft (or Microsoft and StarWind if you wish) did quite a lot to make your dream come true.

tulsaconnect wrote:Love your answer, we all got a good laugh here at the office

But in all seriousness, regarding the new version due out next month -- are there any technical changes that optimize for this scenario (2 node, iSCSI target on the same box as the iSCSI initiator), or is it more of a licensing-only type change?