banner-r2_2-744204

Source: Microsoft Clustering and High Availability blog

What is Extended Affinity?

 To understand how NLB does load balancing, please refer to this TechNet article about various forms of affinity and their impact on load balancing decisions.

 Extended Affinity is an extension to the Single and Network affinity.  NLB does not rely on any network protocol’s state to make its load balancing decisions.  As a result, NLB will work with a wide variety of protocols, documented and undocumented, stateless (HTTP/UDP etc.) and stateful (RDP/SSL etc).  This makes NLB more flexible in deployment and easier to manage since we don’t have to configure the load balancer to work with every protocol that it needs to handle.  However, some applications would benefit from being able to explicitly associate a connection to a server.

 An example would be using IIS by online retailer using shopping carts.  When a customer shops at their store, they save the intended purchases in a shopping cart which is stored on one of the nodes in the cluster.  To keep the products in the shopping cart, the customer must stay connected to that same node.  However configuration changes to the cluster (such as adding a new VIP or node) which cause cluster convergence may then directed customers to another cluster node, and they have lost the purchases saved in that shopping cart.  Now the customer may become frustrated and the retailer may lose money.

 Another instance could be with SSL where the SSL session can consist of multiple TCP Connections.  In normal operations, if single affinity is used, NLB will guarantee that all connections coming from the same source IP will hit the same server.  This would include multiple TCP connections of the same SSL session.  However, configuration changes might cause NLB to accept different connections of the same SSL session by different servers during the convergence.  As a result, the SSL session is broken.

Read more at the source.