DynConD – DNS-based Client-side Global Server Load Balancer
What is DynConD - DNS-based Client-side Global Server Load Balancer?
DynConD – Dynamic Content Delivery Network Service is:
- Client-side Global Server Load Balancer
- DNS-based Client-Server service for optimal server selection and server load management
- The ultimate choice for the fastest delivery of network services to clients
DynConD cloud load balancer is used by replicated and distributed network services for better user experience and global server load balancing. The client selects the optimal server independently, based on a measured network distance between client and servers (in contrast to commonly used imprecise geographic proximity) and the current server load or service response time.
DynConD introduces a composite DNS metric that allows the client himself, rather than a remote server, to make the final decision as to which server, represented by IP address in a DNS response, is best for him. The server parameters are supplied to the client via the standard DNS infrastructure and provide the client with information about the current status of the server load and/or the service response time of a particular network service.
When can DynConD be used?
- DynConD can be used when more than one server is available to provide a network service
- DynConD can be used when a client uses Android, Linux, iOS or Windows OS apps
What is the basic idea behind DynConD?
If a client can access some network service located on two or more servers he can select:
- The server with the shortest network distance (RTT)
- The server with the fastest service response time
- The server with the least load
What kind of server selection process does DynConD use?
DynConD uses Dynamic Server Selection (DSS) process because:
- Each client has a unique network distance to each particular server
- The response time of the server service changes over time
- Server load and/or service response time is not constant
What are the parameters for server selection?
Dynamic Server Selection parameters are:
- Network distance between client and server – measured by a client (RTT), not approximated by (geo)location and geographic distance
- (Optional) Server service response time – measured by DynConD.Net’s unique agentless method
- (Optional) Server load (CPU, RAM) – measured by DynConD’s Linux/Windows agent
How does the client decide which server is optimal?
As a Client-side Global Server Load Balancer, the DynConD client calculates the composite DNS metric for the public IP address of each server based on the measured and delivered server parameters:
How are the parameters for a metric calculation delivered to the client?
- The DSS parameters for a metric calculation are delivered to the client via the standard DNS infrastructure, using DNS as the database that the client accesses before establishing communication with the server (DNS is hosted on DynConD.Net domain)
- During the name-to-address resolution process, standard TXT DNS resource records RRs containing IPv4 / IPv6 addresses and DSS parameters are used
How are parameters for a metric calculation collected and calculated?
- All DSS parameters, except RTT, which is measured independently by each client, are collected, calculated and transmitted to the clients by DynConD authoritative DNS servers ADNS, in collaboration with DynConD Load server / Agent services or using DynConD’s proprietary Agentless technology
- The server owner can manage server selection parameters and their influence on the server selection process
- If server load parameter (CPU, RAM) is used, this is collected by DynConD Linux / Windows Agent installed on servers and delivered to the DynConD ADNS server by using DynConD Load Server. Optionally, the load parameter collected in % can be converted and made available to the client as service response time value in msec
- When the service response time is used, it is measured by the DynConD Agentless Server by using the proprietary DynConD’s Agentless technology to commonly measure the HTTP get/post response time on the predefined server URL
DynConD’s DNS infrastructure
- DynConD’s DNS servers’ infrastructure consist of four name servers (ns1.dyncond.net, ns2.dyncond.net, ns3.dyncond.net and ns4.dyncond.net) which are located in Europe, North America and Asia and are centrally managed by DynConD’s user portal
- DynConD uses completely its own server’s software, including DNS server software, optimized for DynConD’s project goal: finding the optimal server for each client
Why is DNS used for project implementation?
- The first step before establishing communication between client and server is DNS resolution. DynConD uses this step not only to collect information about server IPv4 / IPv6 addresses for specific FQDN, but also to collect information about server loads and/or service response times, as well as information about how to measure network distance between them. Rules for DNS metric calculation are also included
- The most common IP address resolution process uses A / AAAA RRs, which use some of the standard, normally server-side IP address sorting mechanisms based on (geo)location to direct the client to the preferred IP address. DynConD introduces DNS metric in DNS, similar to network metric in the routing process, and allows the client himself to determine the optimal server represented by the public IP address of the server to ensure the fastest delivery of network services
- DNS is a sophisticated and standardized naming system and DynConD uses well-known TXT RRs defined by RFC 1035 for data transmission but also supports A and AAAA RRs for compatibility with standard A / AAAA DNS queries
What IS DynConD?
- DynConD is a Client-side Global Server Load Balancer
- DynConD is a DNS-based client-server network service for optimal server selection on the client-side, which takes into account the network distance between client and servers and the parameters of the server: service response time and/or server load
- DynConD is a network service for server load management and load balancing
- DynConD is a software infrastructure consisting of an ADNS Server (with DynConD.net domain serving as a database), a Load Server (for the load management of a server, load agent for the acquisition and delivering load parameters to the Load Server), Agentless server for the measurement of service response time and a DNS client library for the optimal server selection on the client-side. The software is completely written in C / C++ to ensure optimal performance and portability
What IS DynConD NOT?
- Recursive private or public DNS service
- Authoritative DNS server for other domain except DynConD.Net domain
- Content Delivery Network (CND) which multiplies and stores files (digital content) on distributed servers