What is Direct Server Return (DSR)? It is a asymmetric network load distribution in load balancing system. Once implemented, the load balancing request and response are using the different network path.
The benefits to use DSR is that:
1. Reduce the extra network hop between requester and responder in the load balancing system to speed up the response time;
2. Only the destination MAC address will be replaced during load balancing. It is super fast, to achieve multi-gigabit throughput while using 1G load balancer;
3. Reduce the load of the load balancer because the actual traffic is not passing through the load balancer. Hence also reduce the bandwidth license cost of loader balancer;
4. Full transparency between the client and actual backend server. The backend server can see the direct connection from the client, and reply to the client bypassing the load balancer;
5. Does not require infrastructure. It is simple enough that it just requires the load balancer and backend servers are in the same subnet;
6. More broad compatibility. Some of the applications, such as soft VoIP, requires direct connection to the backend servers. This will resolve such issue.
The typical DSR example is Azure Load Balancer. When the Azure Load Balancer (standard) is configured with HA port mode, which is for a large number of ports must be load-balanced, such as NVA, or floating IP address is enable, which is recommended for SQL AlwaysOn Availability Group Listener and SQL Failover Clustered Instance (FCI) IP Address, the connection will show it is coming from the client directly on the backend servers when run the netstat command on the backend server, even the client is actually connecting to the frontend ip address of Azure load balancer.
Back to on-premises deployment, these load balancer vendors, such as Netscaler, F5 and KEMP, also have the capability to deliver the Direct Server Return. In a nutshell, it will involve:
1. Install the loopback interface on the backend servers;
2. Configure the loopback interface IP addresses to be the same as the virtual server IP address on the load balancer, which will be used by clients;
3. Configure the virtual server to be sessionless (Netsclaer) or Loose Close (F5), to ensure TCP/IP 3-way handshake is not required, but return mac address of the backend server instead.
However, additional steps are also needed. Since windows 2008 or later, the loopback interface will not allow sending/receiving traffic for both IPv4/IPv6 traffic.
"Windows XP and Windows Server® 2003 use the weak host model for sends and receives for all IPv4 interfaces and the strong host model for sends and receives for all IPv6 interfaces. You cannot configure this behavior. The Next Generation TCP/IP stack in Windows Vista and Windows Server 2008+ supports strong host sends and receives for both IPv4 and IPv6 by default."
To be able to allow this, the following commands need execute on the backend windows servers. For example, "net" is the name of default network interface of the windows server and "loopback" is the loopback interface name.
netsh interface ipv4 set interface "net" weakhostreceive=enabled
netsh interface ipv4 set interface "loopback" weakhostreceive=enabled
netsh interface ipv4 set interface "loopback" weakhostsend=enabled
And it is not required any more to stop the ARP response of loopback interface by setting route metric to 254, which only applies to the windows server prior to windows 2008.
Linux servers do not require this kind of configuration for loopback interface, because by default, it is using weak host sending/receiving.
Also, some of the load balancer vendors does not learn the backend server mac address if using custom user monitor. So additional monitor need be added, such as PING monitor, to ensure the backend server mac address can return to client when using DSR.
With all the benifits, however, there are drawbacks always:
1. Load balancing method is limited to source IP or destination IP;
2. SSL offloading will not work because it requires both inbound and outbound traffic;
3. Other advanced features of load balancer are not available, such as cache and optimization;
4. If the load balancer and backend servers are not in the same subnet, IPoverIP tunnel has to be configured between load balancer and backend servers.
Reference:
Nescaler
https://docs.citrix.com/en-us/netscaler/12/load-balancing/load-balancing-dsrmode.html
https://docs.citrix.com/en-us/citrix-adc/13/load-balancing/load-balancing-dsrmode-tos-ipoverip.html
F5
https://support.f5.com/csp/article/K11116
Windows and Linux Operating System
https://www.loadbalancer.org/blog/direct-server-return-on-windows-2008-using-loopback-adpter/
https://support.kemptechnologies.com/hc/en-us/articles/203861685-Configuring-DSR#_Ref399930626
https://support.kemptechnologies.com/hc/en-us/articles/203861685-Configuring-DSR#_Ref399930623
Subscribe to:
Post Comments (Atom)
Labels
15.2
(1)
Active Directory
(1)
agents
(1)
ai
(8)
AlwaysOn Group
(1)
Attributes
(1)
automation
(1)
Azure
(3)
Azure Log Analytics
(1)
Azure Logical App
(1)
Azure WVD
(1)
business-integration
(1)
Cisco
(3)
Citrix
(2)
database
(1)
developer-experience
(1)
Direct Server Return
(1)
enterprise
(1)
enterprise-agents
(6)
future-of-work
(1)
governance
(2)
Hybrid Cloud
(1)
integration
(1)
Junos Space
(2)
Kubernetes
(1)
Load Balancer
(2)
Microsoft
(1)
Migration
(2)
MS CRM
(2)
MS Exchange
(5)
MS Office
(2)
MS SQL
(2)
MTV
(1)
NetApp
(1)
Network
(1)
NPS
(1)
observability
(1)
OpenShift
(2)
operating-model
(1)
orchestration
(1)
Others
(6)
Polymorphic
(1)
PostgreSQL
(1)
product-management
(1)
Project Management
(3)
RADIUS
(1)
RedHat
(1)
reliability
(1)
Rollback
(1)
RSA
(1)
security
(1)
Sharepoint
(8)
software-business
(1)
SQL
(1)
strategy
(1)
talent-strategy
(1)
TechTips
(1)
Troubleshooting
(1)
trust
(1)
UCS
(1)
Virtualization
(2)
VMWARE
(14)

No comments:
Post a Comment