Client-side vs server-side GSLBPosted by Ashley Cobb on May 24th, 2021 Traditional server-side Global Server Load Balancing (GSLB), as explained in the previous blog, uses only server-side information for load balancing, failover and optimal server selection. Since the GSLB infrastructure collects server information such as server status (available/unavailable), current server load (CPU and/or memory load) and/or server’s service response time, GSLB has a complete overview of the current server status in all data centers. By using Client-side global server load balancer -time status parameters, and not using legacy server load balancing algorithms such as round-robin, weighted round-robin, least connections and random, GSLB can accurately manage load balancing across multiple distributed sites by dynamically adapting DNS responses to clients’ queries. The main problem with the server-side GSLB approach is that server-side GSLB makes the final decision only on the server side, usually approximating two fundamental GSLB functions: Failover: Some data center (server) may be available to the GSLB but may not be available to the client (because the server is permanently or temporarily unavailable after information is sent to the client from the GSLB, or because the network path between client and server is unavailable) and that server IP address is sent to the client as available Optimal server selection: The network distance between client and server is usually approximated on the server side by using geographical proximity with static proximity or geotargeting. Worst case, in server-side GSLB the network distance is usually approximated based on the IP address of the client’s recursive DNS server, not by the IP address of the client itself In contrast, the client-side GSLB makes the final decision on the client side, in which case server-side GSLB components only provide the client server status information, such as current server load and/or service response time, along with information for network distance measurements and composite DNS metric calculation. Client-side GSLB collecting server information Client-side GSLB composite DNS metric calculation and optimal server selection The client calculates the composite DNS metric for the public IP address of each server based on the measured and delivered server parameters and decides for himself which server is optimal for him. During the measurements, the availability of the servers is checked by the client and the network distance is precisely determined. Therefore, the client can always select the server that is available and optimal for him, that is the server that offers the lowest service response time. To provide client-side GSLB functionality, the client (laptop PC, desktop PC, smartphone, …) requires a client-side GSLB library (DNS client) to perform DNS queries, process received data, measure network distances, and make a final decision. DynConD_DSS_method Client-side GSLB composite DNS metric calculation and optimal server selection Key advantages of modern client-side vs server-side GSLB: No need for apps to perform additional DNS lookup Server real-time availability checking Measured network distances between client and servers, not approximated with geolocation Better optimal server selection process, can be server or client oriented Layer 7 protocol independent Better DDoS protection Improved security and user privacy Easier transition from active-passive to active-active functionality Lower TCO, reduced need for server load balancers Better client/customer satisfaction DynConD ltd., 17. May 2021.Like it? Share it! More by this author |