asked on
User Session on Windows NLB.
Hello Experts.
By configuring windows NLB (Network load balancing) can we see the user session that on which server user is routed.
Your valuable feedback is required.
Regards
Naveed
By configuring windows NLB (Network load balancing) can we see the user session that on which server user is routed.
Your valuable feedback is required.
Regards
Naveed
Microsoft Legacy OSMicrosoft Server OSWindows Server 2008
Last Comment
imtiaza
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
You are better off looking at whatever logs or reporting from whatever service(s) your user is using in the WNLB cluster. Which service(s) are you load balancing? Are your connections sticky, or do they bounce around?
Dear Naveed,
NLB supports limited forms of session stickiness:
• Single Affinity. When Single affinity is enabled, the clients port number isn’t used and the mapping algorithm uses the clients full IP address to determine load distribution. As a result, all requests from the same client always map to the same host within the cluster. Because there is no time-out value (typical of dispatcher-based implementations), this condition persists until cluster membership changes. However, session stickiness may not be preserved if the cluster membership changes, in particular when a new host is added to the cluster, or a host is re-added after being temporarily out of service.
• Class C Affinity. As in the case of Single affinity, client port numbers are not used to calculate load distribution. When Class C affinity is enabled, the mapping algorithm bases load distribution on the Class C portion (the upper 24 bits) of the clients IP address. As with Single affinity, sessions may not be preserved if the cluster membership changes.
• IPSec and VPN Sessions. On Windows Server 2003, NLB has specialized support for sticky IPSec and VPN sessions. NLB preserves these sessions even if the cluster membership changes.
• Load balancing will not be as precise as in No Affinity mode.
• Sessions can break when hosts are either added to or removed from a cluster. Note that an SSL session will be transparently renegotiated by the protocol.
• If all of the sessions come through a client-side proxy, you will not see any load balancing since all of the TCP connections will have the same IP Address and they will all be handled by the same computer in the cluster.
Thanks
imtiaza
NLB supports limited forms of session stickiness:
• Single Affinity. When Single affinity is enabled, the clients port number isn’t used and the mapping algorithm uses the clients full IP address to determine load distribution. As a result, all requests from the same client always map to the same host within the cluster. Because there is no time-out value (typical of dispatcher-based implementations), this condition persists until cluster membership changes. However, session stickiness may not be preserved if the cluster membership changes, in particular when a new host is added to the cluster, or a host is re-added after being temporarily out of service.
• Class C Affinity. As in the case of Single affinity, client port numbers are not used to calculate load distribution. When Class C affinity is enabled, the mapping algorithm bases load distribution on the Class C portion (the upper 24 bits) of the clients IP address. As with Single affinity, sessions may not be preserved if the cluster membership changes.
• IPSec and VPN Sessions. On Windows Server 2003, NLB has specialized support for sticky IPSec and VPN sessions. NLB preserves these sessions even if the cluster membership changes.
• Load balancing will not be as precise as in No Affinity mode.
• Sessions can break when hosts are either added to or removed from a cluster. Note that an SSL session will be transparently renegotiated by the protocol.
• If all of the sessions come through a client-side proxy, you will not see any load balancing since all of the TCP connections will have the same IP Address and they will all be handled by the same computer in the cluster.
Thanks
imtiaza
Dear Naveed,
I am not satisfy with Mr. acbrown2010
WE CAN ENSURE THAT WHICH USER IS FROM WHICH NODE.
SECONDLY WE CAN ENSURE THAT ALL TCP CONNECTIONS ORIGINATING FROM THE SAME CLIENT (IP ADDRESS) ARE SEND TO THE SAME HOME IN THE THE CLUSTER.
AND SECONDLY IT IS NOT DIFFICULT TO CHECK IF USER DISCONNECTED ALWAYS RECONNECTS TO THE SAME TERMINAL SERVER NODE.
WE CAN TRACK THE USERS FOR EXAMPLE.
IF 10 USERS ARE CONNECTED TO THE SERVER AND THEN DISCONNECTED THEN WE CAN PROVIDE LIST WHICH 10 USERS ARE CONNECTED TO WHICH SERVERS OF CLUSTER.
Thanks
Imtiaza
I am not satisfy with Mr. acbrown2010
WE CAN ENSURE THAT WHICH USER IS FROM WHICH NODE.
SECONDLY WE CAN ENSURE THAT ALL TCP CONNECTIONS ORIGINATING FROM THE SAME CLIENT (IP ADDRESS) ARE SEND TO THE SAME HOME IN THE THE CLUSTER.
AND SECONDLY IT IS NOT DIFFICULT TO CHECK IF USER DISCONNECTED ALWAYS RECONNECTS TO THE SAME TERMINAL SERVER NODE.
WE CAN TRACK THE USERS FOR EXAMPLE.
IF 10 USERS ARE CONNECTED TO THE SERVER AND THEN DISCONNECTED THEN WE CAN PROVIDE LIST WHICH 10 USERS ARE CONNECTED TO WHICH SERVERS OF CLUSTER.
Thanks
Imtiaza