EMC CLARiiON iSCSI arrays

[Gostev]

If you have one of the devices mentioned below, and are getting slow backup speed, please check out the following support KB article from EMC PowerLink knowledge base.
Article ID: emc150702

Applies To
CLARiiON CX3-40c
CLARiiON CX3-20c
CLARiiON CX3-10c
CLARiiON CX500i
CLARiiON AX100i
CLARiiON CX300i
EMC SW: PowerPath

Symptom
Slow performance occurs during network congestion when attempting to perform high bandwidth read operations from a CLARiiON iSCSI array using the Microsoft iSCSI initiator.

[silverfoxs]

I am sorry. I couldn't find this doc. Is that possible you can provide link for me?
Thanks

[Gostev]

Hello, unfortunately I do not have access to EMC KB. Someone else has posted this resolution, and I've just copied and stickied it here.

[silverfoxs]

Knowledgebase Solution

Question:
Recommended TCP/IP settings for Microsoft iSCSI configurations to fix slow performance
Question:
Mandatory TCP/IP settings for Microsoft iSCSI clusters to fix slow performance and unreliable failover
Environment:
Product: CLARiiON CX3-40c
Environment:
Product: CLARiiON CX3-20c
Environment:
Product: CLARiiON CX3-10c
Environment:
Product: CLARiiON CX500i
Environment:
Product: CLARiiON AX100i
Environment:
Product: CLARiiON CX300i
Environment:
EMC SW: PowerPath
Problem:
Slow performance occurs during network congestion when attempting to perform high bandwidth read operations from a CLARiiON iSCSI array using the Microsoft iSCSI initiator.
Problem:
Unreliable Microsoft iSCSI cluster failover during period of network congestion
Problem:
Slow performance.
Change:
Run a program that performs high bandwidth read operations from an iSCSI CLARiiON using the Microsoft iSCSI initiator during network congestion
Root Cause:
Slow performance may occur during network congestion when RFC 1122-delayed acknowledgements extend the error recovery process. In these situations, the default 200 millisecond delay on the acknowledgement cansignificantly impact read bandwidth. PowerPath, by load balancing read requests across multiple array ports, increases the likelihood that simultaneous read completions from multiple ports will result in network congestion. This increases the likelihood of experiencing the problem.
As specified in RFC 1122, Microsoft TCP uses delayed acknowledgments to reduce the number of packets that are sent on the media. Instead of sending an acknowledgment for each TCP segment received, TCP in Windows 2000 and later takes a common approach to implementing delayed acknowledgments. As data is received by TCP on a particular connection, it sends an acknowledgment back only if one of the following conditions is true:
• No acknowledgment was sent for the previous segment received.

• A segment is received, but no other segment arrives within 200 milliseconds for that connection.
Typically, an acknowledgment is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires. You can adjust the delayed ACK timer by editing the registry as outlined in the workaround below.
Fix:
Modify the TCP/IP settings for the network interfaces carrying iSCSI traffic to immediately acknowledge incoming TCP segments. This workaround solves the read performance issue. The procedure to modify the TCP/IP settings is different for Windows 2000 servers and Windows 2003 servers. Follow directions appropriate for the version you are running on your servers.
These setting are MANDATORY for all Microsoft iSCSI clusters and are RECOMMENDED for all Microsoft iSCSI configurations.

Microsoft iSCSI clusters also require array software revision 3.22.xxx.5.511 or 3.24.xxx.5.007 or later.
Note: These TCP/IP settings should not be modified for network interfaces not carrying iSCSI traffic as the increased acknowledgement traffic may negatively affect other applications.
Caution! This workaround contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following link to view the following article in the Microsoft Knowledge Base: http://support.microsoft.com/kb/256986/.
On a server that runs Windows 2000 SP3 or later, follow these steps:
1. Start Registry Editor (Regedit.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

the interfaces will be listed underneath by automatically generated GUIDs like {064A622F-850B-4C97-96B3-0F0E99162E56}

3. Click each of the interface GUIDs and perform the following steps:

a. Check the IPAddress or DhcpIPAddress parameters to determine whether the interface is used for iSCSI traffic. If not, skip to the next interface.

b. On the Edit menu, point to New and then click DWORD value.

c. Name the new value TcpDelAckTicks and assign it a value of 0.

4. Exit the Registry Editor.

5. Restart Windows for this change to take effect.
On a server that runs Windows Server 2003 SP1 or later, follow these steps:
1. Start Registry Editor (Regedit.exe).

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

the interfaces will be listed underneath by automatically generated GUIDs like {064A622F-850B-4C97-96B3-0F0E99162E56}

3. Click each of the interface GUIDs and perform the following steps:

a. Check the IPAddress or DhcpIPAddress parameters to determine whether the interface is used for iSCSI traffic. If not, skip to the next interface.

b. On the Edit menu, point to New, and then click DWORD value.

c. Name the new value TcpAckFrequency, and assign it a value of 1.

4. Exit the Registry Editor.

5. Restart Windows for this change to take effect.
Note: A more user-friendly method of changing the registry setting is now included in the Server Utility for Release 24 patch (6.24.1.4.0) as an option to "Optimize the Network." See the linked screen capture. This may be an easier fix for some customers than manipulating the registry directly and the registry change is set for the correct iSCSI network.
Notes:
This solution currently (April, 2007) does not apply to CX300i, CX500i, or AX100i arrays. It could apply to AX150i arrays. However, PowerPath for iSCSI does not support load-balancing so the issues described in this solution are much less likely to be a problem. In addition, AX-series customers are not expected to be able to edit the registry in the fashion described so this solution is not appropriate for them.

[Gostev]

Thank you