Beruflich Dokumente
Kultur Dokumente
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.
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.
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
That explanation summarizes the most usual design for ACE GSS. In the next post, I will show
you how to perform a basic configuration on an appliance. Stay tuned!
As promised in my last post, I will proceed with a very simple configuration of an ACE GSS
device to explore its core concepts. Therefore, Figure 1 shows how a single ACE GSS 4492R
appliance can be inserted in an ACE topology.
As Figure 1 depicts, CLIENT can reach the same application that is installed on real servers on
two sites: A and B. Each site has an ACE virtual context that load balances requests from
customers if they are directed to VIP1 (192.168.25.100) and VIP2 (192.168.25.200),
respectively.
Figure 1: ACE GSS Topology
Before accessing the application, the client host will send a request for one of the DNS servers to
find the IP address it will forward its application connection (an HTTP session, in our scenario).
As explained in the post “ACE GSS Basics – Part I”, both DNS servers must have NS records
that can direct the customer to the GSS IP address (192.168.25.60).
Note As you can see, in this simple scenario, CLIENT does not employ a D-proxy, sending its
requests directly to the DNS servers.
The ACE GSS 4492R appliance has two interfaces, which can be used for different purposes. In
this example, interface eth0 will be used for management and eth1 will receive the DNS
requests.
Example 1 shows the setup configuration of an ACE GSS 4492R that has been turned on for the
first time (or had its configuration erased through the restore-factory-defaults command). This
CLI access was performed on the ACE GSS appliance console.
Password: default
##############################
##############################
This setup utility will help guide you through the basic configuration
necessary to get a GSS up and running. The script will not make any
review and edit the new configuration and before applying it to the
running system.
The values in brackets ‘[]‘ are the defaults, and can be selected
This setup script will help with only the basic GSS and GSSM configuration.
To configure DNS rules, it will be necessary to log into the Primary GSSM
Admin Webpage.
* Remote Access
interface ethernet 0
ip address 10.97.39.22 255.255.255.0
interface ethernet 1
hostname ACE-GSS01.labsp.com
ip default-gateway 10.97.39.1
ip name-server 192.168.25.24
ip name-server 192.168.25.25
ssh enable
no ssh keys
telnet enable
ftp enable
no cnr enable
drp
no enable
Choice: 1
Note: GSSM database is required only on the primary GSSM and the
standby GSSM.
Generating certificates
Done.
done.
To complete configuration you should now log into the administrative Webpage
https://ACE-GSS01.labsp.com
Note In a future post, I will show examine how an GSS cluster brings high availability on a
GSLB scenario. For now, I will focus on a single device to explain its basic concepts.
As expected, ACE GSS employs an IOS-like command-line interface.
As a natural next step, the appliance must be configured to process DNS requests that are
forwarded to it accordingly. In this configuration, you should define the following parameters:
Keepalives: these are synthetic sessions that GSS sends to test if a VIP or a real server is
capable to respond to application requests. The current GSS software version permits the
creation of the following types: ICMP, TCP, HTTP HEAD (which is identical to HTTP
GET except that the server must not return a message-body in the response), HTTPS
HEAD, KAL-AP (KeepAlive-Appliance Protocol, which is a proprietary communication
protocol between ACE GSS and other Cisco local server load balancers such as ACE
4710 and ACE module), SNMP, and CRA (Content Routing Agents that use a resolution
process called DNS race to send identical and simultaneous responses back to a user´s D-
proxy).
Owner: configuration entity that permits that a single GSS appliance is portioned among
multiple administrative domains. Consequently, it contains all global server load-
balancing settings that belong to a single domain.
Source Address List: specifies the source IP addresses from DNS queries that are
received by the GSS (client or D-proxy).
Domain List: contains the domains (or subdomains) that are under the responsibility of
the GSS.
Answer VIPs: correspond to the virtual IP addresses that are configured on the local
server load balancers that are installed on each site. For GSS, these are the IP addresses
that will be included in the DNS responses.
Answer Group: contains multiple Answer VIPs to where the clients will be load
balanced.
DNS Rule: defines how the GSS will respond to each DNS query. It uses all the
parameters above for this decision and others such as load-balancing method (round-
robin, least-loaded, ordered, weighted-round-robin, fair-weighted-round-robin, hashed
[domain name and/or source-address], among others).
Proceeding with the configuration, Example 2 changes the TCP keepalive global behavior (for
the appliance) so we can have a faster reaction to a VIP failure (which can represent that an
entire site is unavailable or all of the application servers are).
ACE-GSS01.labsp.com#conf t
ACE-GSS01.labsp.com(config)#gslb
Different clients can receive different DNS responses from an appliance if they are classified in
different source address lists. In this way, ACE GSS can perform different GSLB actions for
clients in distinct networks. Nonetheless, for the sake of simplicity, Example 3 exhibits a list that
treats every client equally.
ACE-GSS01.labsp.com(config-gslb)#owner LABSP
ACE-GSS01.labsp.com(config-gslb-sal)#exit
Next, Example 4 configures a list of a single domain that the ACE GSS is authoritative.
ACE-GSS01.labsp.com(config-gslb-dl)#domain http://www.labsp.com
ACE-GSS01.labsp.com(config-gslb-dl)#exit
Per definition, an ACE GSS appliance must identify the state of the locally load-balanced VIPs
on each site. As a result, the appliance will only send DNS responses containing the IP addresses
of active VIPs. Example 5 shows the definition of both VIPs.
! Here you define the IP address that will be inside the DNS responses
! In this command you can use the IP address that will actually receive the probe
ACE-GSS01.labsp.com(config-gslb-ansvip)#exit
ACE-GSS01.labsp.com(config-gslb-ansvip)#exit
As you can notice on Example 5, ACE GSS can also send DNS responses for different IP
addresses if the VIPs are, for instance, hidden behind a device performing Network Address
Translation (NAT).
After creating the answer vips, Example 6 aggregates them in the same answer group so they can
receive a similar treatment by ACE GSS.
ACE-GSS01.labsp.com(config-gslb-agvip)#exit
Please observe that in the answer group GRP-WEB, each answer vip received a weight, an
order, and a load-threshold. Depending on the configured GSLB load balance algorithm, ACE
GSS will use a different parameter to define where the next client will be forwarded.
Finally, Example 7 creates a dns rule. In it, you can notice how all other parameters are linked in
this configuration entity.
Example 7:
ACE-GSS01.labsp.com(config-gslb-rule)#exit
Unfortunately, some browsers cache DNS responses anyway. Consequently, I advise you to
install add-ons in your browser to verify if ACE GSS is sending DNS responses accordingly to
its configuration.
Figure 2 exhibits some Firefox add-ons that might help this task.
Example 8 depicts some useful show commands that can assist you in the verification of a dns
rule.
IP: 192.168.25.100
Status: ONLINE
No of Keepalives Configured: 1
Status: ONLINE
Destination Port: 80
Transitions: 5
IP: 192.168.25.200
Status: ONLINE
No of Keepalives Configured: 1
Status: ONLINE
Destination Port: 80
Transitions: 5
—————————————————————–
192.168.25.100 VIP 33 0 0 0 0
192.168.25.200 VIP 47 0 0 0 0
ACE-GSS01.labsp.com#
In the case of a VIP failure, GSS will simply forward the IP addresses defined on the remaining
answer VIPs to the clients guaranteeing application continuity for them (VIP 192.168.25.200
was sent more times than 192.168.25.100 because I´ve put the latter offline to test such
behavior).
In summation, this relatively old solution remains a crucial piece on active-active data center
designs that employ geoclusters and long distance virtual machine online migrations (as
explained in Chapter 16 from the Data Center Virtualization Fundamentals book). I hope this
has helped you to better understand ACE GSS mechanics and evaluate if it is a useful solution
for your environment.