The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
Is the MS iSCSI service still used for other functions, as the installer checks for it and won't proceed until it's running.MS iSCSI transport for sync channel has been substituted by new transport implementation.
Aitor_Ibarra wrote:Is the MS iSCSI service still used for other functions, as the installer checks for it and won't proceed until it's running.MS iSCSI transport for sync channel has been substituted by new transport implementation.
cheers,
Aitor
Aitor_Ibarra wrote:With HA targets, I know you say you need to optimise performance. I'm consistently getting lower write speed than read speed - is WB cache disabled, so if you set cache as WB currently, you actually get WT cache? I think WT cache MUST be working as I still get better speeds in an ATTO test than the underlying storage is capable of.
The only way I've managed to kill 5.8 so far is by making the classic mistake of leaving Widows Update on automatic, ending up with several instances rebooting at similar times. Even then, I was able to recover with no data loss because nothing was using the storage at the time. I've noticed that SW5.8 (perhaps earlier versions too, I never tried this before) can cope with the underlying storage disappearing on one node. E.g. when using another iSCSI target for the underlying storage of a 5.8 HA node, if you take the underlyind storage away, 5.8 will auto resync when it comes back. I wonder if this will work with a disappearing RAID set? Useful for anyone unfortunate enough to have WD Velociraptors with the 45 day bug!
As for MS iSCSI initiator, I've not really had a problem with performance over 10G. Perhaps at faster speeds it doesn't work well. I have had occasional BSODs on hyper-v nodes if both SW nodes become unavailable at the same time, which shouldn't happen, of course, only in the VMs using the storage.
Aitor_Ibarra wrote:I was just looking for a reason for the lower write performance... I can see how the ack from 2nd server's cache would cause a delay - and I will look to see if I have a bottleneck in the sync channel as well.
I have yet to unleash my storage-killer tests, but I think that my immediate impression is correct - of all the Starwind betas I've looked at, this is the closest to release quality I've seen. I haven't yet come across a functionality issue that would require a new build. It seems very reliable, and performance is very good considering the resources I'm using for testing it. So far, it seems that the main task before release is filling in the gaps in the help file.
I would have liked to have seen dedupe come out of "experimental" and also HA dedupe - but then I'm sure both of them are coming soon!
MS iSCSI and BSODs - are you finding BSODs definitely caused by MS iSCSI drivers, TCP/IP stack etc, and not by dodgy NIC drivers? I had a lot of problems with Hyper-V & early Intel drivers (later ones are much better) and as far as I know there are still problems with Broadcom teaming. I'm glad that Microsoft is finally going to support teaming in the OS with Windows 8.
kmax wrote:Just curious if you read up on the next SMB versions in regards to clustering/fault tolerance and how Starwind fits in with it all.
Is this just on the server or on the initiators?We're getting rid of Microsoft iSCSI stack as it's slow
robnicholson wrote:Is this just on the server or on the initiators?We're getting rid of Microsoft iSCSI stack as it's slow
Cheers, Rob.
robnicholson wrote:So the installation on servers using the Microsoft iSCSI initiator is unchanged?
Cheers, Rob.