1) The Windows 2008 sever introduces a method to auto tune the TCP stack. If a server on the LAN or a network device in the datazone such as a router or switch does not support TCP Windows scaling, backups can fail. To avoid failed backups, and ensure optimal NetWorker operations, apply the Microsoft Hotfix KB958015 to the Windows 2008 Server, and set the auto tuning level value to highlyrestricted:
1. Check the current TCP settings:
C:\> netsh interface tcp show global
2. If required, restrict the Windows TCP receive side scaling auto tuning level:
C:\> netsh interface tcp set global
autotuninglevel=highlyrestricted
Note: If the hotfix KB958015 is not applied, the autotuning level must be set to disabled rather than highlyrestricted, and that is the reason of the difference of NPG and the Powerlink article
2) For the Direct Cache Access (DCA), Windows 7 and 2008 Server add NETDMA 2.0 Direct cache access support. Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.
The recommended state is enabled (provided the CPU/Chipset/NIC support it)
3)NSR_SOCK_BUF_SIZE is a new environment variable to adjust TCP window size and has been introduced in NetWorker 7.6.1, which allow you to scale the TCP window size on NetWorker level to comply with the TCP window size on OS level, which will result in a better backup performance
The continuously increasing speed of NIC’s (1GB & 10GB), makes TCP scaling more applyable on operating systems. It gives also the capability of handeling bigger TCP packets. which result in carring more Data per TCP packet. As a result More data is transmitted, less blocks fragmentation & reduced I/O overhead. but bear in mind that those settings consumes more RAM.
By default, most operating systems do not use large buffer sizes to reduce memory usage, but for large NetWorker servers it is required that the buffer size is increased.
To force the use of a larger TCP send/receive window from NetWorker, include these in the NetWorker start script:
NSR_SOCK_BUF_SIZE=65536
export NSR_SOCK_BUF_SIZE
- The optimal TCP socket buffer for a 1 GB network is 64 KB.
- The optimal TCP socket buffer for a 10 GB network is 256KB. Include this in the NetWorker start script:
NSR_SOCK_BUF_SIZE=262144
If required, override the defaults by setting NSR_SOCK_BUF_SIZE to the appropriate number of bytes before to starting the NetWorker daemons:
NSR_SOCK_BUF_SIZE = <# bytes>
Note: This setting must be changed on all systems in the environment for the desired size to be used. If there are mismatched systems, NetWorker will throttle to the lowest value. For example, if the NetWorker server is 128 KB but one client in the datazone is 32 KB, NetWorker will throttle to 32 KB.
Please check the following Powerlink KB articles regarding this variable:
4) For Data Execution Prevention, The second option which is Turn on DEP for all programs and services except those I select is just to give you option to exclude or turn off DEP for some programs which are not compatible with DEP, but if your list is empty so there is no difference between first option and second one , so you can use the option that has been specified in the NPG or keep you configurations like that.
5) I dont know if there is a command line to list the data domain devices from the networker cli , i dont believe so , i know that you can query the deduplicated savesets using the mminfo which can show you the volume of the deduplication, but to direct list the data domain devices, i am not sure of that.
Hope that this information answers your questions.
Thank you very much Ahmed for detailed explanation..definitely makes things clear now..just one question about the socket buffer size...if you increase, does it affect during restore for older backups using default size or it will throttle that to the lowest during restore? does throttling delays backup/restore?
The TCP communication buffer size is negotiated on the fly based on capabilities of both ends. There is a limit on the range of the save or recover which has probably around 32K typically window size setting.
For that you have to configure that settings on all the systems in your environment as the negotiation between the two sides whether in backing up or recovering will be the same, in that negotiation process, NetWorker will throttle down to the lowest common denominator of both sides.
Bebo2k
544 Posts
0
May 1st, 2012 02:00
Hi Thierry,
1) The Windows 2008 sever introduces a method to auto tune the TCP stack. If a server on the LAN or a network device in the datazone such as a router or switch does not support TCP Windows scaling, backups can fail. To avoid failed backups, and ensure optimal NetWorker operations, apply the Microsoft Hotfix KB958015 to the Windows 2008 Server, and set the auto tuning level value to highlyrestricted:
1. Check the current TCP settings:
C:\> netsh interface tcp show global
2. If required, restrict the Windows TCP receive side scaling auto tuning level:
C:\> netsh interface tcp set global
autotuninglevel=highlyrestricted
Note: If the hotfix KB958015 is not applied, the autotuning level must be set to disabled rather than highlyrestricted, and that is the reason of the difference of NPG and the Powerlink article
2) For the Direct Cache Access (DCA), Windows 7 and 2008 Server add NETDMA 2.0 Direct cache access support. Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to deliver data directly into a CPU cache. The objective of DCA is to reduce memory latency and the memory bandwidth requirement in high bandwidth (Gigabit) environments. DCA requires support from the I/O device, system chipset, and CPUs.
The recommended state is enabled (provided the CPU/Chipset/NIC support it)
To enable DCA:
netsh int tcp set global dca=enabled
Thanks,
Ahmed Bahaa
Bebo2k
544 Posts
1
May 1st, 2012 03:00
Answer Continues:
3) NSR_SOCK_BUF_SIZE is a new environment variable to adjust TCP window size and has been introduced in NetWorker 7.6.1, which allow you to scale the TCP window size on NetWorker level to comply with the TCP window size on OS level, which will result in a better backup performance
The continuously increasing speed of NIC’s (1GB & 10GB), makes TCP scaling more applyable on operating systems. It gives also the capability of handeling bigger TCP packets. which result in carring more Data per TCP packet. As a result More data is transmitted, less blocks fragmentation & reduced I/O overhead. but bear in mind that those settings consumes more RAM.
By default, most operating systems do not use large buffer sizes to reduce memory usage, but for large NetWorker servers it is required that the buffer size is increased.
To force the use of a larger TCP send/receive window from NetWorker, include these in the NetWorker start script:
NSR_SOCK_BUF_SIZE=65536
export NSR_SOCK_BUF_SIZE
- The optimal TCP socket buffer for a 1 GB network is 64 KB.
- The optimal TCP socket buffer for a 10 GB network is 256KB. Include this in the NetWorker start script:
NSR_SOCK_BUF_SIZE=262144
If required, override the defaults by setting NSR_SOCK_BUF_SIZE to the appropriate number of bytes before to starting the NetWorker daemons:
NSR_SOCK_BUF_SIZE = <# bytes>
Note: This setting must be changed on all systems in the environment for the desired size to be used. If there are mismatched systems, NetWorker will throttle to the lowest value. For example, if the NetWorker server is 128 KB but one client in the datazone is 32 KB, NetWorker will throttle to 32 KB.
Please check the following Powerlink KB articles regarding this variable:
https://solutions.emc.com/emcsolutionview.asp?id=esg123483
https://solutions.emc.com/emcsolutionview.asp?id=esg96983
4) For Data Execution Prevention, The second option which is Turn on DEP for all programs and services except those I select is just to give you option to exclude or turn off DEP for some programs which are not compatible with DEP, but if your list is empty so there is no difference between first option and second one , so you can use the option that has been specified in the NPG or keep you configurations like that.
5) I dont know if there is a command line to list the data domain devices from the networker cli , i dont believe so , i know that you can query the deduplicated savesets using the mminfo which can show you the volume of the deduplication, but to direct list the data domain devices, i am not sure of that.
Hope that this information answers your questions.
Thanks,
Ahmed Bahaa
Thierry101
2 Intern
•
326 Posts
0
May 1st, 2012 13:00
Thank you very much Ahmed for detailed explanation..definitely makes things clear now..just one question about the socket buffer size...if you increase, does it affect during restore for older backups using default size or it will throttle that to the lowest during restore? does throttling delays backup/restore?
Thanks again...
Bebo2k
544 Posts
1
May 1st, 2012 16:00
Hi Thierry,
The TCP communication buffer size is negotiated on the fly based on capabilities of both ends. There is a limit on the range of the save or recover which has probably around 32K typically window size setting.
For that you have to configure that settings on all the systems in your environment as the negotiation between the two sides whether in backing up or recovering will be the same, in that negotiation process, NetWorker will throttle down to the lowest common denominator of both sides.
Hope that this information helps you.
Thanks,
Ahmed Bahaa