Global Parameters

In this panel you’ll be able to set the parameters to improve your farms performance and your virtual service custom features. The Edit Farm Action properties depend on the profile type that we’ve selected while the farm is created.

The Global Service Load Balancing, commonly called GSLB, allows to create a load balancing service based on the DNS service hierarchical architecture. This kind of farm provides an authoritative-only DNS with load balancing algorithms and service state detection at DNS application layer.

The GSLB farm profile provides a distribution panel with the following parameters:

  • Farm’s name. It’s the identification field and description for the virtual service. In order to change this item you need to modify the name field and press the Modify button. The load balancing service will be restarted automatically after applying this operation. Ensure that the new farm name is available, in another case an error message will appear.

  • Farm Virtual IP and Virtual Port. These are the virtual IP address and/or virtual port in which the virtual service for the farm will be bound and listening in the load balancer system. To make changes in these fields, ensure that the new virtual IP and virtual port are not in use. In order to apply the changes the farm service will be restarted automatically.
  • Add service and algorithm. A GSLB service represents a group of real servers and associated algorithm to be used for them. In order to create a new service, you’ve to set a valid identification name and the desired algorithm to use. Click on “Add” button in order to create the service.

GSLB Services

To create a new Service you need to provide a unique name and select the Algorithm that best suites your needs.

The GSLB algorithm:

  • Round Robin: equal sharing. An equal balance of traffic to all active real servers. For every incoming connection the balancer assigns the next round robin real server to deliver the request.
  • Priority: connections always to the most prio available. Balance all connections to the same highest priority server. If this server is down, the connections switch to the next highest server. With this algorithm you can build an Active-Pasive cluster service with several real servers.

 

The GSLB Round Robin service will allow the following simple options.

Default TCP port health check. This is the health check TCP port that the service is going to check in order to determine that the backend service is alive. An empty value is disabled.

A GSLB service represents a group of real servers and associated algorithm to be used for them. In order to create a new service, you have to set a valid identification name and the desired algorithm to use. Click on “Add” button in order to create the service, after what the next sceen will appear.

The service needs a backend list in order to deliver the clients requests:

  • ID. It’s the backend identification number within the service. With the round robin service is possible to add so many backends as needed.
  • IP Address. It’s the real backend IP address.
     

Backend Servers Health Check

By default, Zevenet runs simple health checks to the backends or real servers, but sometimes this check is not enough to determine that the backends are working appropiately. For this reason, Zevenet implements a service that executes and manages advanced health checks via a daemon.

zevenet lslb http backends

The fields of Health Checks are:

  • Enable or Disable button: May be ON or OFF.
  • Time Between Checks: Seconds from one check to the next.
  • Check Timeout: Period of time in seconds that the daemon wait for a backend response before considering it is not responding.
  • Search for String in Response: Daemon will search and parse the string in this field on the HTTP response body.

In the previous screenshot the checker send a GET to  /index.html for each of the backends. Later it search the string "keywords" in the body of the response. If that string is found the check is consider successfull.

GSLB Zones

The GSLB zone section will describe the DNS domain name, subdomains, aliases, etc., which will be needed to generate a complete DNS zone with additionally load balancing records using the services defined as described above.

Default Name Server. This will be the entry point root name server that will be available as the Start of Authority (SOA) DNS record.

The zone requires DNS records list in order to create DNS entries to serve real applications:

  • Resource Name. The resource name of the DNS entry.
  • TTL. The Time to Live (optional) value for the current record which it’s needed to determine the length of time that the current name will be cached.
  • Type. DNS record type. The options are:
  • NS. Name Server type record, it delegates a DNS zone to use the given authoritative name servers.
  • A. Address type record, it returns an IPv4 address of a host.
  • CNAME. Canonical name type record, it represents an alias of a given name.
  • DYNA. Dynamic address type record, it returns a dynamic address specified by a GSLB service already created within the farm configuration according to the algorithm selected for such service.
  • AAAA. Address type record, it returns an IPv6 address of a host.
  • MX. Mail exchange type record, maps a domain name to a list of message transfer agents for that domain.
  • SRV. Service locator type record, Generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX.
  • TXT. Text type record, it is used to store any text-based information that can be grabbed when necessary. We most commonly see TXT records used to hold SPF data and verify domain ownership.
  • PTR. Pointer record, pointer to a canonical name. Unlike a CNAME, DNS processing stops and just the name is returned. The most common use is for implementing reverse DNS lookups.
  • NAPTR. Naming Authority Pointer, Allows regular-expression-based rewriting of domain names which can then be used as URIs, further domain names to lookups, etc.
  • RData. It’s the real data needed by the record type, input value depends of the kind of Resource Name, the following example shows the different kind of Resurce Names and the allowed RData values for each one.

 

 

 


Comments