cc/td/doc/product/webscale/gss/gss_1_0
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Introducing the Global Site Selector

GSS Overview

Key Features

Customer Profiles

Traditional DNS Routing

Determining Load and Availability When Routing

Architecture

Global Site Selectors and Global Site Selector Managers

Domain Lists

Source Address and Source Address Lists

Answers and Answer Groups

Keepalive Objects

Balance Methods

Regions and Locations

Owners

Network Deployment

Overview

Locating GSS Devices

Communication Between Nodes

Deployment Within Data Centers

GSS Network Management

CLI-Based GSS Management

GUI-Based GSS Management

Understanding the GSSM GUI


Introducing the Global Site Selector


This chapter describes the Cisco Global Site Selector (GSS) and introduces the user to the terms and concepts necessary to properly understand and operate the GSS product.

This chapter contains the following sections:

GSS Overview

Architecture

Network Deployment

GSS Network Management

GSS Overview

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 Domain Name system (DNS) responsiveness, and ensuring data center availability.

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 on line and that customer requests to data centers that suddenly go off line 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 name space. Because it can transmit requests at a rate of thousands of requests per second, the GSS greatly improves DNS responsiveness to those subdomains.

Key Features

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 name space.

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.

Customer Profiles

Because of its critical role in providing global server load balancing and disaster recovery capabilities for distributed data center deployments, the GSS is appropriate for organizations with a variety of network configurations and business needs. The following sections describe the types of organizations that benefit the most from the deployment of a GSS.

Enterprise Customers with Externally Facing Websites and Web Applications

Enterprises that are deploying e-commerce solutions or other premium services using the public Internet are among the organizations most likely to benefit from the deployment of two or more GSSs.

Increasingly for such customers, data redundancy and disaster recovery through the deployment of multiple, mirrored data centers have become vital components in the continued success of their business; such websites must stay on line and continue to serve customer requests even in the unlikely event that one or more entire data centers suddenly go off line because of a natural or man-made disaster.

For such customers, the GSS offers a robust and flexible request routing infrastructure. Up to eight GSSs can be deployed on a network, each working independently to process requests. Using load and device health statistics to monitor the performance of SLBs under its control, the GSS is quickly able to select the best data center from among many such centers on a request-by-request basis. This way, the loss of any GSS on the network does not affect the functioning of the other devices.

Enterprises with Internally Facing Websites and Web Applications

Increasingly, enterprises with a global reach are turning to the web to deploy mission-critical and business-critical internal applications. From human resources to sales to support, business applications that were traditionally managed within isolated departments are being moved to websites on corporate intranets, thus making them accessible to offices worldwide, as well as to employees connecting from remote locations.

Employee access to such sites is imperative for the smooth functioning of the organization. Site performance and optimization as well as disaster recovery are critical. However, the job of monitoring and maintaining one or more such internal sites across two or more data centers can put a strain on internal information technology (IT) resources.

With an easy-to-use GUI, the GSSM provides a convenient solution to such problems. The GSSM interface makes centralized management of all GSS network resources easy, enabling administrators to assess the health of their GSS devices, create request routing rules that respond to request traffic from within the organization, and ensure that employee access to business-critical data and applications is not hindered.

Application Service Providers Offering Hosting and Colocation Services

Application service providers (ASPs) manage and distribute software-based services and solutions from centralized data centers on behalf of their subscribers.

Purchasing and maintaining their own network and application infrastructure, ASPs enable their subscribers to outsource their information technology needs such as web-based application management or corporate website hosting.

For such organizations, the GSS offers scalability and simplified network management in addition to disaster recovery and site optimization.

An easy-to-understand command-line interface (CLI) provides fast and efficient control of network connectivity, device configuration, and access control. An intuitive GUI is used to configure request routing rules and manage request routing activity across all GSS devices on the network.

And with its support of more than 250 separate SLBs and over 4000 separate VIPs, the GSS makes it easy for ASPs to scale their operations, adding capacity to suit customer needs.

Traditional DNS Routing

Before you can begin using the GSS product, you must first understand content routing as it currently exists, including DNS and how the introduction of GSS devices on your network will affect content routing and delivery to your customers.

This section explains some of the key concepts behind the GSS product.

Since the early 1980s, content routing on the Internet has been handled using the Domain Name System (DNS), a distributed database of host information that maps domain names to IP addresses. A radical departure from the largely manual system of maintaining lists of domain names that preceded it, DNS vastly improved the ability of those responsible for maintaining the Internet to manage network traffic and load, as well as maintain a consistent and unique list of valid Internet hosts.

Almost all transactions that occur across the Internet rely on DNS, including electronic mail, remote terminal access such as Telnet, file transfers using FTP, and web surfing. DNS makes possible the use of easy-to-remember alphanumeric host names instead of numeric IP addresses that bear no relationship to the content on the host.

DNS is a robust and flexible system for managing a nearly infinite number of host names, called the domain name space. (See Figure 1-1.) DNS is particularly effective in that it allows local administration of segments (individual domains) of the overall database, yet makes it possible for data in any segment to be available across the entire network, a process known as delegation.

Figure 1-1 Domain Name Space

Name Servers

Information about the domain name space is stored on name servers that are distributed throughout the Internet, each server storing the complete information about its small part of the total domain name space, called a zone. End users requiring data from a particular domain or machine generate a recursive DNS request on their client that is sent first to the local name server (NS), sometimes called the D-proxy. The job of the D-proxy is to return the IP address of the requested domain to the end user.

Request Resolution

If the D-proxy does not have the information requested by the end user, it sends out iterative requests to the name servers that it knows are authoritative for domains close to the requested domain.

For example, a request for tac.support.cisco.com (see Figure 1-2) causes the D-proxy to check first for another name server that is authoritative for tac.support.cisco.com. If it fails to find that, it checks for name servers farther up the tree: support.cisco.com, then the cisco.com domain, the name server responsible for the com top-level domain, and finally the root server ('''' in Figure 1-2), the address of which every name server is required to have.

Figure 1-2 DNS Request Resolution

Each authoritative name server queried tries to answer the request directly from its own cache of known addresses. Failing that, it directs the D-proxy to name servers farther down the tree toward the requested domain. For example, if queried, the com name server would point the D-proxy to the name server for cisco.com, which would point it to support.cisco.com. Eventually, the D-proxy queries the authoritative name server for the requested domain, which returns the IP address of the requested host.

Determining Load and Availability When Routing

Although traditional DNS provides an efficient and scalable system for users to be matched with the address of servers that contain the data they seek, the end user may not always be directed to the best site. For example, traditional DNS has no way of knowing whether the host whose address it receives is on line, in which case the data returned may be an error message stating that the server is down or "page not found."

Also, if the requested content is mirrored on multiple servers with different addresses, DNS provides no way of determining which server out of all possible choices is the "best match" for the end user to serve that content.

Server Load Balancing

Because of the DNS limitations in routing decisions, more sophisticated kinds of content routing hardware and software have been developed that can interpret information on load, availability, and even requested content type. These devices (often referred to as server load balancers, or SLBs) are designed to process this more specific Layer 4 (L4) and Layer 7 (L7) information from both hosts and requesting clients. SLBs can be deployed either singly or in concert with one another, and they help to connect clients to the best possible content server based on such factors as:

Network topology

Server load

Content availability

Examples of such devices include the Cisco Content Services Switch (CSS) and Cisco Content Switching Module (CSM). Figure 1-3 shows how server load balancing is accomplished using the Content Services Module.

Figure 1-3 Server Load Balancing Using Cisco Content Switching Module

SLBs are usually placed between content servers on your network and the users requesting content. Requests for information, instead of being directed to the actual IP addresses of content servers, are directed to virtual IP addresses (VIPs) represented by the SLB device. The SLB constantly monitors the status of the resources under its control, polling those resources for online status, load, and availability. Once it receives a request, the SLB applies one of various sophisticated algorithms to select the best response to the request, based on the most up-to-date load and availability information it has. It then passes the location of that device back to the requesting client as an answer.

For example in Figure 1-3, a user request for content is directed to a Cisco Content Router 4430-B (Content Router). That device then redirects the client's request to two redundant content sites that are both represented by Cisco SLBs (for example, Content Service Switches) acting as content routing agents (CRAs). Using a resolution process called the DNS race, these devices then send identical and simultaneous requests back to the user's D-proxy, which responds to the first request that reaches it through the network.

For details on the Cisco Content Router software and the DNS race, refer to the Cisco Content Routing Software Configuration Guide and Command Reference.

Global Server Load Balancing

Content Services Switches and Content Switching Modules greatly expand the ability of an organization to serve user requests for content in a quick, efficient, and reliable manner. What happens, however, when SLB devices must balance requests not just between a set number of host servers, but also between one or more geographically dispersed and redundant content sites? The effort to perform server load balancing between multiple, dispersed hosting sites is referred to as global server load balancing, or GSLB.

GSLB offers some key advantages to large organizations or web hosting services that need to manage content requests across a global network, including:

Redundancy—Using real-time load and availability statistics, SLBs like the Content Services Switch and Content Switching Module deployed in a GSLB setting can quickly shift traffic to standby devices should first-line devices suddenly go off line or be overwhelmed with traffic.

Load optimization—Using a variety of load-balancing methods, SLBs acting as part of a GSLB solution can pass on requests to host servers in one or more redundant host sites under their control so that all host servers are carrying an appropriate request load and no one host is underused in serving requests.

Fast response time—Using balancing features such as the DNS race and static proximity, SLBs in a GSLB solution can improve network performance by ensuring that the host responding to a request is the one closest to the requesting client.

Scalability—By quickly integrating new virtual IP addresses (VIPs) or even entire redundant data centers into the routing scheme, SLBs in a GSLB enable you to scale your entire Content Delivery Network (CDN) quickly to meet increased demand.

GSLB Using the Content Services Switch

On its own, the Cisco Content Services Switch offers a number of options for configuring GSLB.

Content Rule-Based GSLB

In versions of the Content Services Switch earlier than Version 5.0, GSLB is supported through what is referred to as a rule-based method. Using this configuration, one or more Content Services Switches are configured as DNS servers using the dns-server CLI command, forming a highly available, distributed, and load-sensitive website.

When groups of Content Services Switches are configured together for DNS, these devices form a content domain within which Content Services Switches—known as peers—can exchange content rules, load-balancing information, and data on service availability.

Each Content Services Switch becomes aware of all the locations for the content associated with a domain name and the operational state and load of the location. The Content Services Switch can then intelligently direct clients to a site where they can best obtain the desired content.

Access lists can be used on the Content Services Switch to filter incoming DNS requests, and Content Services Switch content rules are applied to incoming requests to match requests with the best available VIP based on server availability and load.

Zone-Based GSLB

Beginning with Version 5.0 of the Content Services Switch, zone-based GSLB is supported in addition to content rule-based GSLB. As part of the new proximity features in the Cisco CSS 11000 Series Switch, zone-based GSLB ensures the best site and server selection for all content requests by dividing users and content into zones and determining an optimum content zone based on a user's location. Both the dns-server zone and dns-record CLI commands are used to configure the Content Services Switch to use zone-based GSLB, with internal keepalives (KALs) used to track the status of local VIPs, and external keepalives configured to monitor the status of VIPs associated with external Content Services Switches or Content Switching Modules.

Appliance-Based GSLB Using the GSS

The GSS is designed to coordinate the efforts of Content Services Switches, Content Switching Modules, and other geographically dispersed SLBs in a global network deployment. Running on a Cisco Global Site Selector 4480, the GSS is capable of supporting up to 256 unique SLBs and over 4000 separate VIPs. The GSS coordinates the activities of SLBs by acting as the authoritative DNS server for those devices (SLBs as well as caches) under its control.

As the authoritative name server for a domain or subdomain, the GSS is able to consider additional information about the resources under its control when it receives requests from name servers farther upstream.

Among the additional factors that the GSS is capable of considering when responding to a request are:

Availability—Which servers are on line and available to respond to the query?

Proximity—Which server responded the fastest to a query?

Load—What type of traffic load is each server handling in the domain?

Source of the request—From which D-proxy did the content request originate?

Preference—What is the first, second, or third choice of algorithm to use in responding to a query?

This type of load balancing helps to ensure not only that end users are always directed to resources that are online, but also that requests are forwarded to the most suitable device, resulting in reduced response time for users.

Request Resolution Using the GSS

In resolving DNS requests, the GSS performs a series of distinct operations to take account of the resources under its control and return the best possible answer to the requesting client's D-proxy.

Figure 1-4 illustrates the steps that the GSS takes to resolve requests to the fictional domain tac.support.cisco.com by a GSS that is managing the entire cisco.com corporate domain.

Figure 1-4 Global Site Selector Deployed in Front of a Corporate Website

The GSS takes the following steps to return the IP address of the requested content site:

1. The requesting web client sends a query for tac.support.cisco.com to its local D-proxy.

2. The local D-proxy sends a query to the root name server ('''' in Figure 1-4), which refers the D-proxy to the com name server.

3. The local D-proxy sends a query to the com name server, which refers the D-proxy to the GSS that is acting as the cisco name server.

4. The local D-proxy sends a query to the GSS name server, which determines which local SLB (in this case a Content Services Switch or a Content Switching Module) is the best one (based on availability and load) to fulfill the request for tac.support.cisco.com. The GSS name server sends the IP address of that SLB back to the local D-proxy.

5. The GSS returns the VIP address of the SLB to the requesting client's D-proxy.

6. The client's D-proxy returns that IP address back to the client.

7. The client's browser uses the IP address provided by the D-proxy to connect to the SLB.

8. The SLB locally load balances the request to the best-suited origin server, which responds to the client request.

DNS Rule

The GSS uses DNS rules, as configured by the administrator through the GSSM GUI, to balance incoming DNS requests among the resources under its control.

DNS rules determine how the GSS responds to each query it receives by creating protocols for matching requests received from a known source, or D-proxy, to the most suitable member of a collection of name servers or virtual IP addresses (VIPs).

Each DNS rule takes into account four variables:

The source IP address of the requesting D-proxy.

The requested hosted domain.

An answer group—A group of resources considered for the response, together with balance methods, makes up a clause (described in the paragraphs that follow).

A balance method—An algorithm for selecting the best server, together with an answer group, makes up a clause.

In short, a DNS rule defines how a request is handled by the GSS by answering the following question:

When traffic arrives from a DNS proxy, querying a specific domain name, what resources should be considered for the response, and how should they be balanced?

In addition, for each DNS rule, up to three possible response "clauses" are possible. Each clause specifies that a particular answer group serve the request and a specific balance method be used to select the best resource from that answer group. These clauses are evaluated in order, with parameters established to determine when one clause should be skipped and the next answer used.

The sections that follow explain the architecture of the GSS product as well as key GSS concepts that you need to understand before deploying the GSS on your network.

Architecture

The following sections describe the key components of a GSS deployment, including hardware and software, as well as GSS networking concepts.

Global Site Selectors and Global Site Selector Managers

The Global Site Selector solution relies on three distinct but closely related devices:

Primary GSSM

Standby GSSM

GSS

Primary GSSM

The primary GSSM is a Cisco Global Site Selector 4480 running Cisco GSS software and performing content routing as well as centralized management functions for the GSS network.

The primary GSSM serves as the organizing point of the GSS network, hosting the embedded GSS PostgreSQL database that contains configuration information for all your GSS resources, such as individual GSSs, and DNS rules. Other GSS devices report their status to the primary GSSM. Configuration changes initiated on the primary GSSM using the GSSM GUI are communicated to the devices that the GSSM manages.

Any GSS device can serve as a GSSM, and any GSS device can act as both a GSS and a GSSM simultaneously.

In addition to content routing configuration, a subset of device-monitoring and logging features is accessible from the GSSM GUI, though more extensive inquiries may require access to the GSS CLI for an individual device.

Communication between administrators and the GSSM GUI uses HTTPS, and access to the GSSM GUI is password-protected.

Standby GSSM

The standby GSSM is a Cisco Global Site Selector 4480 running Cisco GSS software and performing GSLB functions for the GSS network. In addition, the standby GSSM is configured to act as the GSSM should the primary GSSM suddenly go off line or become unavailable to communicate with other GSS devices.

As with the primary GSSM, the standby GSSM is configured to run the GSSM GUI and contains a duplicate copy of the embedded PostgreSQL GSS database that is currently installed on the primary GSSM. Any configuration or network changes affecting the GSS network are synchronized between the primary and the standby GSSM so that the two devices are never out of step.

Before it is enabled as the primary GSSM, the GSSM GUI is inaccessible on the standby GSSM.

The standby GSSM can be quickly enabled as the primary GSSM using the gss CLI command, though you must make sure that your previous primary GSSM is off line before attempting to enable your standby as the new primary GSSM. Having two primary GSSMs active at the same time may result in the inadvertent loss of configuration changes for your GSS network.

GSS

The GSS is a Cisco Global Site Selector 4480 running Cisco GSS software and performing routing of DNS queries based on DNS rules and conditions configured using the GSSM.

Each GSS is known to and synchronized with the GSSM, but individual GSSs do not report their presence or status to one another.

Each GSS on your network must be configured on your upstream DNS server and can be managed separately using the Cisco CLI.

A device that is acting as a GSS may also be serving as the GSSM for a GSS network.

Hosted Domains

A hosted domain (HD) is any domain or subdomain that has been delegated to the GSS and configured (using the GSSM GUI) for DNS query responses.

All DNS queries must match a domain belonging to a configured domain list, or else they are denied by the GSS. Queries that do not match domains on any GSS domain lists can also be forwarded by the GSS to an external DNS name server for resolution.

Hosted domains may or may not correspond to standard third-level domain names but cannot exceed 128 characters in length. Domain names that use wildcards are supported by the GSS.

The following might be domain names configured on the GSS:

cisco.com
www.cisco.com
www.support.cisco.com
.*\.cisco\.com

See the "Configuring and Modifying Domain Lists" section on page 2-28 for more information on configuring domains.

Domain Lists

Domain lists are groupings of domains that have been delegated to the GSS. A domain list can contain between 1 and 1024 individual domains.

Using the DNS rules feature of the GSSM GUI, requests for any member of a domain list are matched to an answer—a resource hosting the content being requested—using one of a number of balance methods.

See the "Configuring and Modifying Domain Lists" section on page 2-28 for more information on configuring domain lists.

Source Address and Source Address Lists

The term source address refers to the source of DNS queries received by the GSS. Source addresses might point to an IP address or block of addresses representing client D-proxies from which queries will originate.

Using DNS rules, the GSS matches source addresses to domains hosted by the GSS using one of a number of different balance methods.

Source addresses are taken from the D-proxy (the local name server) to which a requesting client issued a recursive request. The D-proxy iterates the client queries to multiple devices, eventually querying the GSS, which matches the D-proxy address against its list of configured source addresses.

DNS queries received by the GSS do not have to match a specific D-proxy in order to be routed; default routing can be performed on requests that do not emanate from a known source address. A failsafe "Anywhere" source address list is provided by default. Incoming queries that do not match your configured source address lists are matched to this list.

In addition to specific IP addresses, source addresses can also be set up to represent address blocks using variable-prefix-length classless interdomain routing (CIDR) block masking. For example, the following would all be acceptable GSS source addresses:

192.168.1.110
192.168.1.110/32
192.168.1.0/24
192.168.0.0/16

Source addresses are grouped into lists, referred to as source address lists, for the purposes of routing requests. Source address lists can contain between 1 and 30 source addresses, or unique address blocks.

Answers and Answer Groups

In a GSS network, the term answers refers to resources to which the GSS resolves DNS requests that it receives.

The three types of possible answers on a GSS network are:

Virtual IPs (VIPs)—IP addresses associated with an SLB like the Cisco Content Services Switch, Content Switching Module, or other Cisco IOS software-compliant SLB

Name server—Configured DNS name server on your network to which queries that the GSS cannot resolve are forwarded

CRA—Content routing agents associated with the GSS DNS race server

As with domains and source addresses, answers are configured using the GSSM GUI by identifying the IP address to which queries can be directed.

Once created, answers are grouped together as resource pools called answer groups, from which the GSS, using one of a number of available balance methods, can choose the most appropriate resource to serve each user request.

Depending on the type of answer, further intelligence can be applied to DNS queries to choose the best host. For example, a request that is routed to a VIP associated with a Content Services Switch will be routed to the best resource based on load and availability, as determined by the Content Services Switch. A request that is routed to a content routing agent is routed to the best resource based on proximity, as determined in a DNS race conducted by the GSS.

The following sections describe the various GSS answer types.

VIP

Virtual IP addresses (VIPs) are used by SLBs such as the Cisco Content Services Switch and Content Switching Module to represent content hosted on one or more servers under their control. The use of VIPs allows for traffic to be balanced among multiple origin servers, application servers, or transaction servers in a way that results in faster response times for users and less network congestion for the host.

When queried by a client's D-proxy for a domain associated with a VIP answer type, the GSS responds with the VIP address of the SLB best suited to handle that request. The requesting client then contacts the SLB, which load balances the request to the server best suited to respond.

Name Server

A name server (NS) answer type specifies the IP address of a DNS name server to which DNS queries will be forwarded from the GSS.

Using the name server forwarding feature, queries are forwarded to an external (non-GSS) name server for resolution, with the answer passed back to the GSS name server and from there to the requesting D-proxy. As such, the name server answer type can act as a guaranteed fallback resource—a way to resolve requests that the GSS cannot resolve itself—either because the requested content is unknown to the GSS, or because the resources that typically handle such requests are unavailable.

CRA

The CRA answer type relies on content routing agents and the GSS to choose a suitable answer for a given query based on the proximity of two or more possible hosts to the requesting D-proxy.

With the CRA answer type, requests received from a particular D-proxy are served by the content server that responds first to the request. Response time is measured using a DNS race, coordinated by the GSS and content routing agents running on each content server. In the race, multiple hosts respond simultaneously to a request. The server with the fastest response time (the shortest network delay between itself and the client's D-proxy) is chosen to serve the content.

The boomerang balance method uses the DNS race to determine the best site. See the "Boomerang" section for more information on this balance method.

Keepalive Objects

In addition to specifying a resource, each answer also provides you with the option of specifying a keepalive for that resource, a method by which the GSS can periodically check to see if the resource is still active. All answers are validated by configured keepalives and are not returned if the keepalive indicates that the answer is not viable.

The GSS uses keepalives to collect and track information on everything from the simple online status of VIPs to services and applications running on a server. Depending on the type of answer being tracked, the GSS also monitors load and connection information on SLBs that can be used to perform load-based redirection.

Depending on the type of resource that you are configuring as a GSS answer (for example, a VIP associated with a Content Services Switch or Content Switching Module), you have the option of configuring a keepalive for that answer that will be used to monitor its liveness continually and report that information to the GSSM. Routing decisions involving that answer consider that liveness information.

The sections that follow explain the various keepalive object types.

ICMP

Used when the GSS answer that you are testing is a VIP or IP address, the Internet Control Message Protocol (ICMP) keepalive type monitors the health of resources by issuing queries containing ICMP packets to the configured VIP address (or a shared keepalive address) for the answer. Liveness is determined by a response from the targeted address, indicating simple connectivity to the network.

KAL-AP

Used when the GSS answer that you are testing is a VIP associated with a Cisco Content Services Switch or Content Switching Module, the KAL-AP keepalive type sends a detailed query to both a primary (master) and a secondary (backup) circuit address that you specify, returning the liveness status of each interface as well as information on load for whichever address is acting as the master VIP.

Depending on your GSS network configuration, the KAL-AP keepalive can be used to either query a VIP address directly or query an address by way of an alphanumeric tag (KAL-AP By Tag), which can be particularly useful when you are attempting to determine the liveness status of a device that is located behind a firewall that is performing Network Address Translation (NAT).

HTTP-Head

Used when the GSS answer that you are testing is an HTTP web server acting as a standalone device or managed by an SLB device such as a Content Services Switch, Content Switching Module, Cisco IOS software SLB, or Cisco LocalDirector, the HTTP-Head keepalive type sends a TCP format HTTP HEAD request to a web server at an address that you specify, returning the liveness status of the device (in the form of a 200 response).

CRA

Used when the GSS answer that you are testing is a content routing agent (CRA) answer type that will be performing DNS races, the CRA keepalive type tracks the time required (in milliseconds) for a packet of information to reach the CRA and return to the GSS.

Name Server

Used when the GSS answer that you are testing is a name server answer type, the name server keepalive sends a query to the IP address of the name server or to a query domain that you specify (for example, www.cisco.com). Liveness for the name server answer is determined by the ability of the name server or D-proxy for the query domain to respond to the query and resolve the domain to an address.

None

With the keepalive set to None, the GSS assumes that the named answer is always on line. Setting the keepalive type to None prevents your GSS from taking online status or load into account when routing. However, it is useful under certain conditions when adding devices to your GSS network that are not suited to other keepalive types. In general, ICMP is a simple and flexible keepalive type that works with most devices. Using ICMP is preferable to using the None option.

Balance Methods

The GSS supports six unique balance methods that allow you to specify how a GSS answer should be selected to respond to a given DNS query.

Ordered list

Round-robin

Weighted round-robin

Least loaded (ACA load WebNS, connection count on the Content Switching Module)

Hash based on source address or hosted domain

Boomerang (DNS race)

See the following sections for more information on each of these balance options.

Ordered List

Using the ordered list balance method, each resource within an answer group (for example, an SLB VIP or a name server) is assigned a number that corresponds to the rank of that answer within the group. Devices with lower numbers rank above those with higher numbers.

Using the rankings, the GSS tries each resource in the order that has been prescribed, selecting the first available ("live") answer to serve a user request. List members are given precedence and tried in order, and a member will not be used unless all previous members fail to provide a suitable result.

The ordered list method is typically useful in managing resources across multiple content sites in which a deterministic method for selecting answers is required.

See the "Order" section as well as the "Load Threshold" section for information on how the GSS determines which answer to select when using the ordered list balance method.

Round-Robin

Using the round-robin balance method, each resource within an answer group is tried in turn, with the GSS cycling through the list of answers, selecting the next answer in line for each request. In this way, the GSS is able to resolve requests by evenly distributing the load among possible answers.

The round-robin balance method is useful when balancing requests among multiple, active data centers that are hosting identical content, for example between SLBs at a primary and at an "active standby" site that serves requests.

See the "Load Threshold" section for information on how the GSS determines which answer to select when using the round-robin balance method.

Weighted Round-Robin

As with the round-robin balance method, the weighted round-robin (WRR) method cycles through a list of defined answers, choosing each available answer in turn. However, with WRR, an additional "weight" factor is assigned to each answer, biasing the GSS toward certain servers, so that they are used more often.

See the "Weight" section and the "Load Threshold" section for information on how the GSS determines which answer to select when using the weighted round-robin balance method.

Least Loaded

Using the least loaded balance method, the GSS resolves requests to the least-loaded of all resources, as reported by the KAL-AP keepalive process, which provides the GSS with detailed information on the SLB load and availability.

See the "Load Threshold" section for information on how the GSS determines which answer to select when using the least loaded balance method.

Source Address and Domain Hash

Using the source address and domain hash balance method, elements of the client's DNS proxy IP address and the requesting client's domain are extracted and used to create a unique value, referred to as a "hash value." The unique hash value is attached to and used to identify a VIP that is chosen to serve the DNS query.

The use of hash values makes it possible to "stick" traffic from a particular requesting client to a specific VIP, ensuring that future requests from that client are routed to the same VIP. This type of continuity can be used to facilitate features such as online "shopping baskets" in which client-specific data is expected to persist even when client connectivity to a site is terminated or interrupted.

Boomerang

The GSS supports the boomerang (DNS race) method of proximity routing, a type of DNS resolution that is initiated by the GSS and is designed to load balance between 2 and 20 sites.

Based on the concept that instantaneous proximity can be found if a content routing agent (CRA) within each data center sends an A-record (IP address) at the exact same time to the client's D-proxy, the DNS race method of DNS resolution gives all possible CRAs (which can be either Cisco Content Engines or Content Services Switches) a fair chance at resolving a client request and allows for proximity to be determined without probing the client's D-proxy. Whatever A-record is received first is by default the most proximate.

In order for the GSS to initiate a DNS race, it needs to establish two pieces of information per CRA:

The delay between the GSS and each of the CRAs in each data center. With this data, the GSS computes how long to delay the race from each data center, so that in each CRA starts the race simultaneously.

The "aliveness" of the CRAs. With this data, the GSS knows not to forward requests to any CRAs that are not responding.

The boomerang server gathers this information by sending keepalive messages at predetermined intervals. This data, along with the IP addresses of the CRAs, is used to request the exact start time of the DNS race.

Finally, in order for the CRA response to be accepted by the D-proxy, the CRAs must spoof the IP address of the GSS to which the DNS request was sent when responding.

Balance Method Options

For most balance methods supported by the GSS, there are additional configuration options that you must consider to make sure that your GSS is properly applying the balance method for your network resources, and to ensure that you are getting the best possible results from your GSS device. Table 1-1 describes the available options.

Table 1-1 Balance Method Options for Answer Types

Answer Type
Balance Methods Used
Balance Method Options

VIP

Hashed

Least loaded

Ordered list

Round-robin

Weighted round-robin

Weight, order, load thresholds

Name server

Hashed

Ordered list

Round-robin

Weighted round-robin

Order, weight

CRA

Boomerang (DNS race)


The following sections explain each of the balance method options available.

Order

The order option is used when the balance method for the answer group is ordered list. Answers on the list are given precedence in responding to requests based upon their position in the list.

Weight

The weight option is used when the balance method for the answer group is round-robin or least loaded. Weights are specified by a number between 1 and 10 and indicate the capacity of the answer to respond to requests.

When used with the round-robin balance method, the number listed is used by the GSS to create a ratio of the number of times the answer is used to respond before the next answer on the list is tried.

When used with the least loaded balance method, the number listed is used by the GSS as the divisor in calculating the load number associated with the answer, which is used to create a bias in favor of answers with greater capacity.

Load Threshold

When the answer type is VIP and the keepalive method is KAL-AP, the load threshold is used regardless of the balance method used.

The load threshold specifies a number between 2 and 254 that is compared to the load being reported by the answer device. If the answer's load is above the specified threshold, the answer is deemed to be off line and unavailable to serve further requests.

The load threshold value can also be used in conjunction with the weight assigned to an answer, with the weight acting as a divisor for the load threshold in calculating capacity.

Regions and Locations

As your GSS network grows, the job of organizing and administering your GSS resources—answers and answer groups, domain lists, and DNS rules—becomes more and more of a challenge. For that reason, the GSS makes features available to you that help you make sense of and organize your resources. Among these resources are:

Locations—Logical groupings for GSS resources that correspond to geographical entities such as a city, data center, or content site

Regions—Higher-level geographical groupings that contain one or more locations

In addition to allowing you to easily sort and navigate long lists of answers, DNS rules, and so on, the use of logical groupings such as locations and regions makes it easier to perform bulk administration of GSS resources. Using the location feature in the GSS GUI, for example, you can suspend or activate all answers linked to a particular GSS data center, shutting down a site for scheduled maintenance and then bringing it back on line with only a few mouse clicks.

Owners

Owners serve a purpose similar to that of locations and regions in the GSS, providing a simple way to organize and identify groups of related GSS resources. However, whereas regions and locations are used to make geographical sense of your GSS network, owners are used to group resources according to other organizational schemes.

For example, a service provider using the GSS to manage multiple hosting sites might create an owner for each web or application hosting customer. With this organizational scheme, domain lists containing that customer's hosted content as well as DNS rules, answer groups, and source address lists that specify how traffic to those domains should be processed, can all be associated with and managed through the owner.

Deployed on a corporate intranet, owners can be used to segregate GSS resources on a department-by-department basis, or to allocate specific resources to IT personnel. For example, you could create an owner for the finance, human resources, and sales departments so that resources corresponding to each can be viewed and managed together.

Note that designating an "owner" for a resource does not imply the existence of special permissions to access the GSSM GUI or manage that resource. Access to the GSSM GUI and all its features is limited to those individuals with valid GSSM logins and passwords. Owners can be created to correspond to IT personnel who also have GSSM logins, but there is no necessary connection between the two.

Network Deployment

The following sections detail a typical network deployment of the GSS.

Overview

A typical GSS deployment contains at least one and may contain up to eight GSS devices deployed on a corporate intranet or the Internet. At least one GSS—and no more than two GSSs—must be configured as GSSMs, which monitor other GSS devices on the network and offer features for managing and monitoring request routing services using a GUI accessible through secure HTTP. Only one GSSM can be "active" at any time, with the second GSSM serving as a "standby," or backup device.

See the "GUI-Based GSS Management" section for a list of the functions that can be controlled from the GSSM GUI.

The GSSM functionality is embedded on each GSS, and any GSS device can be configured to act as a GSSM or a standby GSSM. See the "Configuring a GSSM" section on page 2-3 for details.

Additional GSSs beyond the primary and standby GSSM that are configured on the GSS network route requests but do not perform GSS network management tasks.

Locating GSS Devices

Although it is your organization that determines where your GSS devices will be deployed in your network, some general guidelines must be observed. The following sections discuss issues related to GSS network deployment.

Because they serve as the authoritative name server for one or more domains, GSSs must be publicly or privately addressable on your enterprise network. That way, the D-proxy clients that are requesting content can find the GSSs that have been charged with handling requests for that content.

Numerous options are available for delegating responsibility for your domain to your GSS devices, depending on traffic patterns to and from your domain. For example, given a network containing five GSS devices, you might choose to modify your upstream name servers so that all traffic of all types that is sent to your domain is directed to each of your GSS devices. Or you might choose to have a subset of your traffic (for example, all web traffic) delegated to one or more of your GSSs, with other devices handling other segments of your traffic.

See the "Upstream DNS Configuration" section on page 2-76 for information on modifying your network's DNS configuration to accommodate the addition of GSSs to your network.

Locating GSS Devices Behind Firewalls

Deploying a firewall can be of immense benefit in preventing unauthorized access to your GSS network, as well as thwarting common denial of service (DoS) attacks on your GSS devices. In addition to the ability to be deployed behind your corporate firewall, the GSS comes with robust packet-filtering features that enable GSS administrators to permit and disallow traffic to any GSS device.

When positioning your GSS behind a firewall or enabling packet filtering on the GSS itself, you must properly configure each device (the firewall and the GSS) to allow valid network traffic to reach the GSS device on specific ports. In addition to requiring HTTPS traffic in order to access the GSS GUI, for example, you may want to configure your GSSs to allow FTP, Telnet, and SSH access through certain ports. In addition, GSSs must be able to communicate their status to and receive configuration information from the GSSM. Finally, primary and standby GSSMs must be able to communicate and synchronize with one another.

See the discussion of the access-list and access-group commands in the "Filtering GSS Traffic Using Access Lists" section on page 3-20 for instructions on limiting incoming traffic.

See the "Deploying GSS Devices Behind Firewalls" section on page 3-25 for information on which ports must be enabled and left open in order for the GSS to function properly.

Refer to the Cisco Global Site Selector Command Reference for detailed descriptions of the CLI commands required to create a firewall that blocks all non-GSS traffic to your GSS devices.

Communication Between Nodes

GSS devices communicate their status to the GSSM using the TCP protocol.

In addition, GSSs monitor the status, including the load and availability, of SLBs under their control using one of a series of keepalives discussed in the "Keepalive Objects" section.

GSS devices do not communicate directly with one another, however, nor do they share keepalive statistics. Should a GSS unexpectedly go off line, therefore, other GSSs on the network responsible for the same resources are not affected.

Redundancy

With both a primary and a standby GSSM deployed on your GSS network, device configuration information and DNS rules are automatically synchronized between the primary GSSM and a data store maintained on the standby GSSM.

Synchronization occurs automatically between the two devices whenever the GSS network configuration changes. Updates are packaged and sent to the standby GSSM using a secure connection between the two devices.

Should the primary GSSM suddenly become unavailable, the standby GSSM assumes the role of primary GSSM, and the GSS network continues to function. However, the standby GSSM must be manually enabled as the primary device using the CLI before its GUI can be accessed and configuration changes made. See the "Configuring a GSSM" section on page 2-3 for instructions on enabling the primary GSSM.

Deployment Within Data Centers

A typical GSS network consists of multiple content sites, such as data centers and server farms, access to which is managed by one or more SLBs, such as the Content Services Switch.

Each SLB is represented by one or more virtual IP addresses, or VIPs. These VIPs act as the publicly addressable front-end of the data center.

Behind each SLB are transaction servers, database servers, and mirrored origin servers offering a wide variety of content, from websites to applications.

The GSS communicates directly with the SLBs that are representing each data center, collecting statistics on availability and load for each of the SLBs and VIPs and using that data to direct requests to the best-suited data centers and the most available resources within each data center.

In addition to SLBs, a typical data center deployment may also contain additional DNS name servers that are not being managed by the GSS. These can be used to resolve requests, through name server forwarding, that the GSS cannot resolve itself.

GSS Network Management

Management of your GSS network is divided into two types:

CLI-based management

GUI-based management

CLI-Based GSS Management

The CLI is used to configure installation and management of your Cisco GSS software, including:

Initial configuration of GSS and GSSM devices

Software upgrades, downgrades, and restore operations on GSSs and GSSMs

Configuration backups and restore operations

In addition, the CLI is used for network configuration of your GSS devices, including:

Network address and host name configuration

Network interface configuration

Access control for your GSS devices, including IP filtering and traffic segmentation

Database and configuration backups and restore operations

The CLI can also be used for status monitoring and logging on an individual GSS device.

GUI-Based GSS Management

The GSSM offers a single, centralized GUI for monitoring and administering your entire GSS network.

The GSSM GUI is used for:

Configuring request routing and server load balancing through the creation of DNS rules

Monitoring GSS network resources

Monitoring request routing and GSS statistics

See the "Understanding the GSSM GUI" section that follows for more information on using the GSSM GUI.

Understanding the GSSM GUI

The GSSM GUI is a web-based tool that can be viewed using any standard web browser such as Microsoft Internet Explorer Version 5.0 and later and Netscape Navigator Version 4.7 or later.

The GSSM GUI serves as a centralized management point for your entire GSS network. Using the GSSM interface, you can add GSS devices to your network and build DNS rules that match groups of source addresses to hosted domains using one of a number of possible load-balancing methods. In addition, using the GSSM monitoring feature, you can obtain real-time statistics on the performance of your GSS network or of individual devices on that network.

When you first log on to the GSSM GUI, you see a Welcome window. (See Figure 1-5.) Additional information appears in the footer area of the GUI, including the current login account information (centered) in the following format:

login (first name, last name)

The current GSS network time in Coordinated Universal Time (UTC) is displayed in the lower right corner of the GUI.

The sections that follow describe the organization and workings of the GSSM GUI. Review them before attempting to use the GUI to create your GSS network.

Figure 1-5 GSSM Welcome Window

The GSSM GUI is organized into five main functional areas that can be accessed by clicking the appropriate button:

DNS RULES—Contains features for creating and modifying DNS rules, including the creation of source address lists, (hosted) domain lists, answers, answer groups, and shared keepalives.

RESOURCES—Contains features for creating and modifying GSS network resources such as GSSs, locations, owners, and so on.

MONITORING—Contains features for monitoring the performance of content routing on your GSS network, such as displays of hit counts organized by source address, domain, answer method, or DNS rule.

TOOLS—Contains administrative features for the GSS network, such as creating login accounts, managing account passwords, and viewing system logs.

HELP—Launches the GSSM online help system, which contains information on using the many features of the GSSM GUI. In addition to the help menu, topic-specific help can also be obtained by clicking the question mark (?) icons that appear in many GSSM windows.

Within each of these major feature areas, users can access particular features by choosing them from a drop-down list that appears in the upper left-hand corner of the GSSM GUI. The options on this list change to reflect the feature area.

Once you have selected a feature, information on your GSS related to that feature is further organized into two areas: list windows and details windows, which are described in the sections that follow.

List Windows

List windows appear throughout the GSSM GUI and provide the user with a feature-specific overview, listing all resources of a certain type that are configured on the GSS network. For example, clicking the DNS RULES button displays the DNS Rules list window, with all the rules currently configured on the GSS network listed.

List windows are also the location from which new resources (for example, DNS rules or domain lists) are added to the GSS network, or existing resources are removed from the network.

In addition to providing a bird's-eye look at resources on your GSS network, list windows also enable you to sort those resources by any one of a number of properties that are listed on the screen, quickly locating a particular resource by an identifying characteristic such as name, owner, or type.

To sort information that is listed on the GSSM, click the column header for the column containing the information by which you wish to sort the list. For example, to sort your DNS rules balance method, you would click the words Balance Methods at the top of that column. The screen refreshes, listing the DNS rules sorted alphabetically by balance method type.

Figure 1-6 shows an example of a GSSM list window.

Figure 1-6 GSSM List Window

Details Windows

Details windows appear throughout the GSS GUI and provide specific configuration information for a single resource, while also enabling administrators to modify those properties, create new resources, remove resources, and so on.

For example, in Figure 1-6, choosing Domain Lists from the drop-down menu displays the Domain Lists list window. Adjacent to each domain list is an icon depicting a pad and pencil, called the Edit icon. Clicking the Edit icon for the domain in the list window displays the details window for that domain list (see Figure 1-7), allowing the GSS administrator to modify the domain list by adding or removing domains.

Figure 1-7 GSSM Details Window

Navigation

Although the GSSM GUI is viewed as a series of web pages using a standard browser, navigating within the GUI is not the same as moving around between different websites, or even within a single site. The standard browser navigation button, with Forward and Back buttons is disabled, as is the browser address field that displays the URL of the page you are viewing.

Instead, you navigate from one content area of the GSSM GUI using the buttons for each of the major content areas: DNS RULES, RESOURCES, MONITORING, TOOLS, and HELP.

Once within a major content area, you can access a particular feature or move between features using the drop-down list. Choosing a feature from the drop-down list immediately transfers you to that window on the GUI.

To move back from a details window for a resource to the corresponding list window, use the Save or Cancel buttons.


Note Using your web browser's Back button cancels any unsaved changes in the GSSM GUI.


For example, to return to the Global Site Selectors list window after viewing the details for one of your GSSs, you would click the Cancel button. Or, if you have made configuration changes to that GSS that you wish to retain, click Save. Either action returns you to the Global Site Selectors list window.

GSSM Icons and Symbols

Table 1-2 lists and explains some common icons and graphical symbols in the GSSM interface. These icons are referenced throughout this guide in explaining how to use the features of the GSSM.

Table 1-2 GSSM GUI Icons and Symbols 

Icon or Symbol
Purpose
Location

Edit icon. Opens the associated item for editing, displaying configuration settings in the details window.

List windows

Wizard icon. Opens the associated DNS rule for editing using the DNS Rule Wizard.

DNS Rule list window

Sort icon. Indicates that the items listed are sorted in ascending order according to the property listed in this column.

List windows

*

Asterisk. Required field. Indicates that a value is required in the adjacent field before the item can be successfully saved.

Details windows

Save button. Saves configuration information. When you edit specific GSS system or device configuration information, clicking Save returns you to the associated list window.

Details windows

Cancel button. When you edit specific GSS system or device configuration information, clicking Cancel returns you from the details window to the associated list window, much like the Back button on your web browser. Any configuration changes that have been entered but not saved are discarded.

Details windows

Reset button. When you edit global properties such as global keepalive properties, clicking Reset restores any unsaved settings changes.

Global KeepAlive Properties window

Refresh button. When you view GSS resources or monitor GSS network activity, clicking Refresh forces the GSSM window to update its content.

List windows

Export button. When you view GSS resources or monitor GSS network activity, clicking Export allows you to save data displayed in the window to a flat file for use in other applications.

List windows

Print button. When you view GSS resources or monitor GSS network activity, clicking Print allows you to print data displayed in the window using your local or network printer.

List windows

Delete button. When you view configuration information for GSS resources, clicking Delete allows you to delete the resource from the GSS network.

Details windows

Question mark. Launches the GSS online help system, displaying topic-specific help information.

Details windows and list windows



hometocprevnextglossaryfeedbacksearchhelp

Posted: Mon Mar 21 11:16:47 PST 2005
All contents are Copyright © 1992--2005 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.