Scheduling Methods

The GEO LoadMaster load balances DNS requests – it does not load balance traffic. GEO offers many load balancing algorithms including round robin, weighted round robin, fixed weighting, real server load, location based, proximity, and all available.

The selection criterion chosen determines how GEO distributes the incoming requests across the IP address end-points for the FQDN.

The selection criterion can be altered in real-time; previously configured information is retained during a change. Only a single selection criterion is permitted per FQDN and each FQDN can have a unique selection criterion. The following sections outline the selection criteria that are available on the LoadMaster.

Each of these scheduling methods are described below.

Round Robin

With the Round Robin method, incoming requests are distributed sequentially across the IP address end-points.

If this method is selected, all the IP address end-points assigned to an FQDN should have similar resource capacity and host identical applications. Subject to this precondition, the round robin system is a simple and effective method of distribution.

However, if the IP address end-points have different capacities, the use of the round robin system can mean that a less powerful IP address end-points receives the next inquiry even though it has not yet been able to process the current one. This could cause a weaker IP address end-points to become overloaded.

This selection criterion is not dependent on the geographical IP database.

Round Robin load balancing can be used for all active data centers, which includes support for weights and a chained failover option for disaster recovery. Round robin scheduling in GEO LoadMasters works the same way as the normal LoadMaster with one exception; when using nslookup, by default it will check for both IPv4 (A) records and IPv6 (AAAA) records which actually sends out two requests.

For example, if you have two sites:

• Request 1 IPv4 A record hits Site 1,
• Request 2 IPv6 record AAAA hits Site 2,
• Request 3 IPv4 A record hits Site 1,
• Request 4 IPv6 AAAA record hits Site 2

When testing:

• Clients looking for IPv4 will always connect to Site 1.
• Clients looking for IPv6 will always connect to Site 2.

To help prevent this during testing – add an odd number of sites.

Weighted Round Robin

This method balances out the weakness of the simple round robin: incoming requests are distributed across the endpoints in a sequential manner, while taking account of a static “weighting” that can be pre-assigned per server.

The administrator simply defines the capacities of the endpoints available by weighting the endpoints. The most efficient endpoint, A for example, is given the weighting 100, whilst a much less powerful endpoint (B) is weighted at 50. This means that endpoint A would always receive two consecutive requests before endpoint B receives its first one, and so on.

This selection criterion is not dependent on the geographical IP database.

Fixed Weighted

Fixed weighted scheduling is usually used in Disaster Recovery (DR) sites. The highest weight endpoint is only used when other endpoint(s) are given lower weight values. However, if the highest weighted endpoint fails, the endpoint with the next highest priority number is available to serve clients. The weight for each endpoint should be assigned based on the priority among the remaining endpoints. When the failed endpoint becomes available, it automatically starts receiving requests. If multiple endpoints share the same highest weight, the system distributes traffic among them in a round‑robin manner until a endpoint with a higher weight becomes available.

This selection criterion is not dependent on the geographical IP database.

Real Server Load

GEO securely and seamlessly integrates with core LoadMaster functionality to offer Real Server Load balancing, for which GEO uses local data center metrics (provided by the LoadMaster) allowing clients to connect to the most available target. Each IP address end-point in the FQDN must have a Cluster assigned and the Checker drop-down menu must be set to Cluster Checks. The GEO LoadMaster polls the connection statistics of the LoadMaster and uses a portion (or all) of the available data to determine the overall level of busyness for the relevant Virtual Service. The site IP address with the lowest load value receives the requests.

This selection criterion is not dependent on the geographical IP database but does require a LoadMaster cluster.

Proximity and Location Based

Location Based load balancing allows GEO to direct a client to a data center based on the client's country, continent or IP address range as defined by the created policies. If there is more than one site with the same country code, requests are distributed in a round robin fashion to each of the sites. Location Based load balancing can be used for granularity, for example, if a site in Germany fails – send traffic to the next site in Europe (not the next closest proximity site).

Proximity takes Location Based one step further and allows for longitude and latitude granularity for definition of proximity. When using Proximity scheduling, new public sites are automatically mapped to geographic coordinates based on the GEO database. New private sites are mapped to 0º0'0" and function as expected. This coordinate should be overridden with accurate values to ensure correct balancing.

The client source IP address is geocoded in real-time by the LoadMaster then matched against the geocoded longitude and latitude of the cluster or FQDN endpoint definitions. The closest cluster or IP address end-points to the client is the IP address provided to the client. The longitude and latitude of a cluster or IP address end-point is auto-populated and can be manually overridden.

This selection criterion is dependent on the geographical IP database.

To use the Proximity selection criteria with private IP addresses, the IP Range Selection Criteria must be completed for all private subnets. In addition to this, both the coordinates and country must be configured. If they are not configured, requests from private IP addresses are rejected.

For more information on the IP Range Selection Criteria, refer to the IP Range Selection Criteria section.

In the example above, either proximity or location-based scheduling could be used. If proximity scheduling is used, the client is directed towards the German domain because it is geographically closer to it than the French domain. If location-based scheduling is used, the client is directed towards the French domain because it is in the same country. Using proximity scheduling here may result in a faster connection. However, if users need to be directed towards the French version of a website – it may be better to use location-based scheduling.

All Available

The All Available selection criteria returns all possible healthy targets for an A (IPv4) or AAAA (IPv6) query request. The GEO LoadMaster will still refuse other records, for example MX. The contents of the returned list is also controlled by the Public Requests and Private Requests settings:

• For Public Sites Only the list can only contain public addresses. Likewise, for Private Sites Only the list can only contain private addresses.
• For Prefer Public the list only contains public addresses, unless no public addresses are available – in which case the list contains private addresses (if any are available). Likewise, for Prefer Private the list only contains private addresses, unless no private addresses are available – in which case the list contains public addresses (if any are available).
• For All Sites the list contains all available addresses

The purpose of this is to provide a list of preferred addresses, if they are available. Otherwise, provide a list of non-preferred addresses as a failback measure for improved availability.