Global load balancing basics
The global load balancing (GLB) feature is a DNS-based solution that enables you to deploy redundant resources around the globe that you can leverage to keep your business online when a local area deployment experiences unexpected spikes or downtime. The FortiADC system implements a hardened BIND 9 DNS server that can be deployed as the authoritative name server for the DNS zones that you configure. Zone resource records are generated dynamically based on the global load balancing framework. The DNS response to a client request is an ordered lists of answers that includes all available virtual servers. A client that receives DNS response with a list of answers tries the first and only proceeds to the next answers if the first answer is unreachable. The response list is based on the following priorities:
- Virtual server health—Availability is determined by real-time connectivity checking. When the DNS server receives a client request, it checks connectivity for all possible matches and excludes unavailable servers from the response list.
- Persistence—You can enable persistence for applications that have transactions across multiple hosts. A match to the persistence table has priority over proximity algorithms.
- Geographic proximity—Proximity is determined by matching the source IP address to either the FortiGuard Geo IP database or the FortiADC predefined ISP address book.
- Dynamic proximity—Proximity is determined by application response time (RTT probes), least connections, or byte-per-second.
- Weighted round robin—If proximity algorithms are not configured or not applicable, available virtual servers are listed in order based on a simple load balancing algorithm.
Global load balancing deployment shows an example global load balancing deployment with redundant resources at data centers in China and the United States.
FortiADC-1 is the local SLB for the data center in China. FortiADC-2 is the local SLB for the data center in the United States. FortiADC-1 and FortiADC-2 are also the GSLB. They host the DNS servers that are authoritative for www.example.com. When a client clicks a link to www.example.com, the local host DNS resolver commences a DNS query that is ultimately resolved by the authoritative DNS server on them. The set of possible answers includes the virtual servers on FortiADC-1 or FortiADC-2. The global load balancing framework uses health status and proximity algorithms to determine the set of answers that are returned, and the order of the answer list. For example, you can use the global SLB framework geoproximity feature to direct clients located in China to the virtual server in China, or if the virtual server in China is unavailable, then to the redundant resources in the United States.
You configure the global load balancing framework and DNS settings only on the global FortiADC (in the example above, both FortiADC-1 and FortiADC-2 are GSLBs). The virtual server IP addresses and ports can be discovered by the FortiADC global SLB from the FortiADC local SLBs. The GLB DNS server uses the discovered IP addresses in the DNS response. The framework also supports third-party IP addresses and health checks for them.
The DNS server supports the following security features:
- DNSSEC—Domain Name System Security Extensions. DNSSEC provides authentication by associating cryptographically generated digital signatures with DNS resource record (RR) sets. The FortiADC system makes it easy to manage the keys that must be provided to DNS parent domains and the keys that must be imported from DNS child domains.
- Response rate limit—Helps mitigate DNS denial-of-service attacks by reducing the rate at which the authoritative name servers respond to high volumes of malicious queries.
- DNS forwarding—In a typical enterprise local area network, the client configuration has the IP address of an internal authoritative DNS server so that requests for internal resources can be answered directly from its zone data. Requests for remote resources are sent to another DNS server known as a forwarder. The internal server caches the results it learns from the forwarder, which optimizes subsequent lookups. Using forwarders reduces the number of DNS servers that must be able to communicate with Internet DNS servers.
BIND 9 reference manuals: http://www.bind9.net/manuals
RFC 1035 (DNS): http://tools.ietf.org/html/rfc1035
RFC 4033 (DNSSEC): http://tools.ietf.org/html/rfc4033