GSLB using cisco GSS explained
With the growth of the Internet and of Internet-based commerce, there is an increasing demand for high-end networking solutions that can handle sophisticated customer transactions and high traffic loads. Improved content routing is the core technology behind such networking solutions.
Based on a set of metrics such as network topology, server load, delay time, or established request routing “rules,” global load-balancing devices such as the Cisco Content Services Switch (CSS) and Content Switching Module (CSM) can balance content requests among two or more hosts containing the same content that are connected to a corporate LAN or the Internet.
SLBs ensure that the content consumer is directed to the host that is best suited to handle that consumer’s request. Increasingly, organizations with a global reach or businesses that provide web and application hosting services require network devices that can perform such complex request routing to two or more redundant, geographically dispersed data centers, improving response times while also providing disaster recovery and failover protection through so-called “Global Server Load Balancing,” or GSLB.
The Cisco Global Site Selector (GSS) is a next-generation networking product that provides these services, allowing customers to leverage global content deployment across multiple distributed and mirrored data locations, optimizing site selection, improving the Domain Name System (DNS) responsiveness, and ensuring data center availability.
The Cisco Application Control Engine Global Site Selector (ACE GSS) is a network service that provides global server load balancing for geographically dispersed servers. It relies on Domain Name System (DNS) requests from application clients to direct them to the IP address from a host or to a server load balancer´s virtual IP (VIP) address.
Inserted into the traditional DNS routing hierarchy and closely integrated with your Cisco or third-party server load balancers (SLBs), the GSS monitors the health and load of the SLBs in each of your data centers and then uses that information along with customer-controlled routing algorithms to select the best-suited and least-loaded data center in real-time.
Just as important, the GSS is capable of detecting site outages, thus ensuring that web-based applications are always online and that customer requests to data centers that suddenly go offline are quickly rerouted to available resources. Finally, the GSS off-loads tasks from traditional DNS servers by taking control of the domain resolution process for parts of your domain namespace. Because it can transmit requests at a rate of thousands of requests per second, the GSS greatly improves DNS responsiveness to those subdomains.
The GSS offers the following key capabilities:
•Disaster recovery—The GSS can detect and instantaneously route requests around site outages. •Improved site performance—In multiple data center deployments, the GSS speeds up the selection process through the application of state-of-the-art load-balancing algorithms that take the load and health of Cisco and third-party SLBs into account when routing requests.
•Scalability—The GSS is capable of scaling to support hundreds of separate data centers and SLBs, while working seamlessly with a heterogeneous mixture of SLBs, including Cisco and third-party devices.
•Improved DNS performance—Inserted into the traditional DNS hierarchy, the GSS off-loads traffic from DNS servers, becoming the authoritative DNS server for some (or all) of your domain namespace.
•Centralized domain management—Through an easy-to-use graphical user interface (GUI) on the Global Site Selector Manager (GSSM), administrators can manage quickly configure their GSS network as well as monitor the health and performance of request routing across their entire GSS network.
ACE GSS integrates to a company network through the use of Name Server (NS) records inserted into its DNS. Adversely from Address (A) records, which provides a destination server IP address in a DNS lookup, a NS entry informs the IP address of an ACE GSS appliance where another request should be forwarded. In this way, a DNS request for a URL such as www.company.com ends up being resolved by an appliance that can apply intelligence to its response.
Figure 1 represents the main components of an ACE GSS implementation.
In the figure, you can notice:
- Two dispersed sites (Site 1 and 2) with separate infrastructure (data center networks are not depicted).
- An ACE virtual context at each site representing a “local” server load balance (ACE1 and ACE2). Each virtual context has a VIP (VIP1 and VIP2, respectively) that can receive user sessions that will be load balanced to the application servers.
- Each ACE virtual context test the application availability in each server through health probes.
- GSS1 also sends probes to verify the state of VIP1 and VIP2. If at least one server is available, its virtual context will receive sessions on its VIP.
- GSS1 resides on Site 1 but it is part of a cluster with GSS2, which is located at Site 2.
When a customer device wants to establish a session with the geographically dispersed application, it sends a DNS request to a server that is inserted in its TCP/IP stack (statically or through DHCP). Generically speaking, this server usually is a D-proxy that issues iterative DNS queries on behalf of the client.
Looking for www.company.com , the D-proxy queries the DNS server responsible (“authoritative”) for the .com domain. It contains a NS record that points to the server that is responsible for company.com. Such a server is usually present at a customer premises, for instance Site 1.
Luckily, this server was prepared with a NS record that characterizes GSS1 as the responsible for domain www.company.com . Now, GSS1 can forward VIP1 or VIP2 as a response to the D-proxy depending on multiple factors, such as:
- Application state
- Number of active servers per site
- Server load
- D-proxy IP address
- … and many others