loopback vs. private IP performance

[mwo]

Hi.

Whenn configuring the initiators, do you see a significant difference in performance when you use the private IPs instead of the loopback interface?

Let's say, I have two servers with two 10G NICs each.

Server 1:
NIC1: 192.168.1.1/24
NIC2: 192.168.2.1/24

Server2:
NIC1: 192.168.1.2/24
NIC2: 192.168.2.2/24

I can use NIC1 of each server to connect to NIC1 of both servers. Same for NIC2. MPIO is activated.

I'm asking, because I tried loopback first and ran into the problem, that the targets did not reconnect after a reboot. Instead I got an error message, saying that the target is in use and cannot be connected. Using private IPs, this never happened.

Thank you.

Martin

[yaroslav (staff)]

Greetings,

Thanks for your post and welcome to StarWind Forum! Several questions from my end.
1. Which build are you using?
2. What is the Server OS?
3. How many iSCSI connections do you have? In other words, how many concurrent sessions do you use?
4. How do you measure the performance?

that the targets did not reconnect after a reboot. Instead I got an error message, saying that the target is in use and cannot be connected. Using private IPs, this never happened.

After the restart, the devices are not connected as the HA devices are not synchronized. This is expected until synchronization is over. Please make sure that
1. the restart procedure is followed (https://knowledgebase.starwindsoftware. ... installed/)
2. iSCSI targets are connected as described in our technical documentation https://www.starwindsoftware.com/resour ... rver-2016/ (i.e., favorite targets are added)
If 1 and 2 are OK, there is something on the OS side, not the target side as the changes you made do not relate to the target but are related to the initiator (i.e., OS settings).

[mwo]

Dear Yaroslav.

Thank you for the reply.

1. I'm using the current build now (14869), but this also happend in 14120. I didn't test the builds in between.
2. I'm using Windows Server 2019.
3. There are 15 iSCSI sessions for every HAdevice. 11 have a starwindsoftware name and 4 are MS initiators. I can explain the 4 MS sessions (two from each node) , but I never configured the number of starwind sessions. This sort of happened on its own or is predefined. I cannot explain why the number is odd.
4. Storage is a Raid 10 of 4 SSDs. Copying files locally results in ~920MB/s which is more than 7 Gb/s. Copying files inside the HAdevice results in less than 4Gb/s in sum over both channels.

I followed the recommanded reboot procedure. Also, the targets are in the favorite list. The servers automatically try to reconnect but fail with the above mentioned error.

[yaroslav (staff)]

Each heartbeat link is 2 iSCSI sessions (heartbeat+command), and each StarWind synchronization link is 3 sessions (data+heartbeat+command).
Copying is not a reliable test as it involves OS buffers. Is the file system NTFS or is it already CSVFS (Cluster Shared volume)? See more on slow transfers https://learn.microsoft.com/en-us/windo ... e-transfer. From my experience enabling write back cache and aligning FirstBurstLenght with MaxBurstLength in registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\000X\Parameters) help to improve performance for copying.

Try testing as described here https://www.starwindsoftware.com/best-p ... practices/.

Even if local-to-local (e.g.192.168.1.1 to 192.168.1.1) delivers better performance, you still need 127.0.0.1 to be connected in Standby mode.

Actually, this case looks quite interesting. Please log a call with us at support@starwind.com use this link and 880202 as your references.