All other brand or product names used in this document are trademarks or registered trademarks of
their respective companies or organizations.
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS
MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE
ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF
ANY PRODUCTS.
This document was revised for Equalizer Software Version 8.6.0b.
Contents
Preface 15
In This Guide .................................................................................................................15
This version of the Equalizer Installation and Administration Guide tells you how to install, configure, and maintain
Equalizer™ load balancers running Release 8.6 of the Equalizer software.
In This Guide
This guide contains the following chapters and appendices:
•Chapter 1, “Equalizer Overview”, contains detailed descriptions of Equalizer concepts and terminology.
This chapter includes information to help you plan your Equalizer configuration. If you are setting up
Equalizer for the first time, be sure to read the Overview chapter before attempting to install and configure
your system.
•Chapter 2, “Installing and Configuring Equalizer Hardware”, provides comprehensive instructions for
installing Equalizer hardware and setting up Equalizer to work with your networks and servers.
•Chapter 3, “Using the Administration Interface”, discusses how to use Equalizer’s HTML-based
administration interface, including adding administrative logins with distinct permissions.
•Chapter 4, “Equalizer Network Configuration”, covers VLAN and switch port configuration, as well as
how to define static routes on Equalizer.
•Chapter 5, “Configuring Equalizer Operation”, tells you how to configure system and global resources
through the Equalizer Administration Interface, including setting up a failover configuration.
•Chapter 6, “Administering Virtual Clusters”, tells you how to add and remove virtual clusters and servers,
changing load balancing options, and shutting down servers.
•Chapter 7, “Monitoring Equalizer Operation”, describes how to view information, statistics, and graphical
displays about Equalizer’s operation.
•Chapter 8, “Using Match Rules”, shows you to create match rules that distribute requests based on a
request’s attributes.
•Chapter 9, “Administering GeoClusters”, shows you how to use the optional Envoy product to add and
remove geographic clusters and sites and change geographic load balancing and targeting options.
•Appendix A, Server Agent Probes, describes how to develop custom server agents.
•Appendix B, Timeout Configuration, provides detailed desccriptions of all the timeout parameters used by
Equalizer and the effect that each has on client/server connections and server probes.
•Appendix C, Using Reserved IP Addresses, describes how to configure Equalizer to distribute requests to
servers assigned IP addresses on reserved, non-routable networks.
•Appendix D, Regular Expression Format, discusses Equalizer’s regular expressions, components, formats,
and usage.
•Appendix E, Using Certificates in HTTPS Clusters, shows you how to obtain and install certificates for
HTTPS clusters.
Equalizer Installation and Administration Guide 15
Chapter : Preface
•Appendix F, Equalizer VLB, describes the optional Equalizer VLB product, which supports integration of
Equalizer with VMware Infrastucture and ESX Server virtual machine configurations.
•Appendix G, Troubleshooting, helps you to diagnose problems with Equalizer.
•Appendix H, License and Warranty, contains the complete License and Warranty information.
•Appendix I, Additional Requirements and Specifications, lists additional hardware related requirements for
Equalizer installations.
•The Glossary defines the technology-specific terms used throughout this book.
•Use the Index to help find specific information in this guide.
Typographical Conventions
The following typographical conventions appear throughout this guide:
Italics indicates the introduction of new terms, is used to emphasize text, and indicates variables and file names.
Boldface text highlights command names in instructions and text entered by the user.
Boldface text highlights
graphical administrative interface screen elements: labels, buttons, tabs, icons, etc.
Courier text is used to denote computer output: messages, commands, file names, directory names, keywords, and
syntax exactly as displayed by the system.
Sequences such as “
Equalizer > Status > Event Log” are used to indicate the Administrative Interface click-path
the user should follow to display the information or form relevant to the task at hand. In this example, the user
would click on the Equalizer system name displayed on the left side of the Administrative Interface, then click on
the
Status tab on the right side of the screen, and then click on the Event Log sub-tab. Similarly, “Cluster > Probes”
starts by selecting a cluster name in the left frame tree, and “Server > Reporting” starts with a server name.
1.Numbered lists show steps that you must complete in the numbered order.
•Bulleted lists identify items that you can address in any order.
Note – Highlights important information and special considerations.
Caution – Warns when an action could result in loss of data or damage to your equipment.
Emphasizes safety information or information critical to Equalizer operation.
16Equalizer Installation and Administration Guide
Chapter : Preface
Where to Go for More Help
This Equalizer Installation and Administration Guide is part of the product documentation delivered with
Equalizer’s browser-based Administrative Interface. You can display the appropriate manual section for any
interface screen by selecting
contains links to the Release Notes for the currently running software version, and other documentation.
Hardcopy documentation provided with every Equalizer includes the Getting Started Guide and the basic Configuration Guide. These two documents are designed to help you get Equalizer out of the box and working with
your first virtual clusters. The Basic Configuration Guide also contains a
documentation, including support documents that help you configure Equalizer for a variety of environments. The
latest Resource CD content is available on the web at:
http://docs.coyotepoint.com
Customer Support contact information is available from http://www.coyotepoint.com/support.php.
Register today to get access to the
provides you with a login so you can access these benefits:
•
Support FAQs: answers to our customer's most common questions.
•
Moderated Customer Support Forum: ask questions and get answers from our support staff and other
Equalizer users.
Help > Context help from the menu at the top of the interface. The Help menu also
Resource CD with copies of all product
Coyote Point Support Portal (http://support.coyotepoint.com). Registration
•
Software upgrades and security patches: access to the latest software updates to keep your Equalizer
current and secure.
•
Online device manuals, supplements, and release notes: the latest Equalizer documentation and
Using Equalizer E350/450/650GX in a Single VLAN Environment ........................................... 33
Using Equalizer E350/450/650GX in a Dual VLAN Environment .............................................. 34
Using Equalizer E350/450/650GX in a Complex VLAN Environment ....................................... 35
Link Aggregation ...............................................................................................................................36
Using a Second Equalizer as a Backup Unit .....................................................................................36
Where Do I Go Next? ...............................................................................................................................37
Equalizer Installation and Administration Guide 19
Chapter 1: Equalizer Overview
Introducing Equalizer
Equalizer® is a high-performance content switch that features:
•Intelligent load balancing based on multiple, user-configurable criteria
•Non-stop availability with no single point of failure, through the use of redundant servers in a cluster and
the optional addition of a failover (or backup) Equalizer
•Layer 7 content-sensitive routing
•Connection persistence using cookies or IP addresses
•Real-time server and cluster performance monitoring
•Server and cluster administration from a single interface
•SSL acceleration (on Equalizer models with Xcel SSL Hardware Acceleration)
•Data compression (on Equalizer models with Express Hardware GZIP Compression)
•Geographic load balancing (with the optional Envoy software add-on)
This chapter is an introduction to Equalizer’s basic load balancing and application acceleration capabilities, for those
who have some networking experience but may not have previously used an appliance like Equalizer.
Intelligent Load Balancing
Equalizer functions as a gateway to one or more sets of servers organized into virtual clusters. When a client
submits a request to a site that Equalizer manages, Equalizer identifies the virtual cluster for which the request is
intended, determines the server in the cluster that will be best able to handle the request, and forwards the request to
that server for processing.
To route the request, Equalizer modifies the header of the request packet with the appropriate server information and
forwards the modified packet to the selected server. Depending on the cluster options chosen, Equalizer may also
modify the headers in server responses on the way back to the client.
Equalizer support clusters that route requests based on either Layer 4 (TCP or UDP) or Layer 7 (HTTP or HTTPS)
protocols. Layer 4 is also referred to as the Transport Layer, while Layer 7 is referred to as the Application Layer.
These terms come from the OSI and TCP/IP Reference Models, abstract models for network protocol design.
In general, Layer 4 clusters are intended for configurations where routing by the destination IP address of the request
is sufficient and no examination of the request headers is required. Layer 7 clusters are intended for configurations
where routing decisions need to be made based on the content of the request headers. Equalizer evaluates and can
modify the content of request headers as it routes packets to servers; in some cases, it can also modify headers in
server responses on their way back to the client.
20Equalizer Installation and Administration Guide
The table below summarizes the basic capabilities of the cluster types supported by Equalizer.
Cluster Type
Introducing Equalizer
Feature
Load balancing
policies
Server failure
detection (probes)
PersistenceBased on IPUsing Cookies
Server selection by
request content
(i.e., Match Rules)
Load balanced
protocols
NAT and spoofingYes
a. Note that some LDAP/LDAPS implementations are UDP-based.
Regardless of cluster type, Equalizer uses intelligent load balancingalgorithms to determine the best server to
receive a request. These algorithms take into account the configuration options set for the cluster and servers, realtime server status information, and information from the request itself. For Layer 7 clusters, user-defined match
rules can also be used to determine the route a packet should take.
Load Balancing Configuration
When you configure a virtual cluster, you can select one of the following load-balancing algorithms to control how
Equalizer balances the load across your servers:
connections
, server agent, or custom.
round robin, static weight, adaptive, fastest response, least
When you configure the servers in a virtual cluster, you assign an initial weight between 0 and 200 for each server.
When you select one of the adaptive load-balancing algorithms (i.e., any algorithm other than round robin),
Equalizer uses the servers’ initial weights as a starting point to determine the percentage of requests to route to each
server. Each server handles a percentage of the total load based on its fraction of the total weights in the server
cluster. Equalizer dynamically adjusts server weights according to real-time conditions to ensure that Equalizer
routes requests to the server that is best able to respond. A server with a weight of zero (0) is considered down or
unavailable, and Equalizer does not route requests to servers in this state.
Real-Time Server Status Information
Equalizer gathers real-time information about a server’s status using ICMP Probes, TCP Probes, Active Content
Verification (ACV), and Server Agents. ICMP and TCP Probes are the default probing methods.
Equalizer Installation and Administration Guide21
Chapter 1: Equalizer Overview
ICMP Probes uses the Internet Control Message Protocol to send an "Echo request" to the server, and then wait for
the server to respond with an ICMP "Echo reply" message (like the Unix ping command). ICMP is a Layer 3
protocol. ICMP probes can be disabled via a global flag.
TCP Probes establish (and tear down) a TCP connection between Equalizer and the server, in a typical Layer 4
exchange of TCP SYN, ACK, and FIN packets. If the connection cannot be completed, Equalizer considers the
server down and stops routing requests to it. TCP probes cannot be disabled.
Equalizer’s Active Content Verification (ACV) provides an optional method for checking the validity of a server’s
response using Layer 7 network services that support a text-based request/response protocol, such as HTTP. When
you enable ACV for a cluster, Equalizer requests data from each server in the cluster (using an ACV Probe string)
and verifies the returned data (against an ACV Response string). If Equalizer receives no response or the response
string is not in the response, the verification fails and Equalizer stops routing new requests to that server. (Note that
ACV is not supported for Layer 4 UDP clusters.) For more information, see “Using Active Content Verification
(ACV)” on page 134.
Server Agent Probes are an optional feature that enable Equalizer to communicate with a user-written program (the
agent) running on the server. A server agent is written to open a server port and, when Equalizer connects to the
port, the server agent responds with an indication of the current server load and performance. This enables Equalizer
to adjust the dynamic weights of the server according to detailed performance measurements performed by the
agent, based on any metrics available on the server. If the server is overloaded and you have enabled server agent
load balancing, Equalizer reduces the server’s dynamic weight so that the server receives fewer requests. The
interface between Equalizer and server agents is simple and well-defined. Agents can be written in any language
supported on the server (e.g., perl, C, shell script, javascript, etc.). For more information see “Server Agent Probes”
on page 255.
For those who have one or more VMware ESX Servers, Equalizer VLB can be configured to use VMware’s status
reporting to determine server status, and can also be configured to automatically manage VMware servers based on
status information obtained from VMware. For more information, see Appendix F, ”Equalizer VLB”.
Network Address Translation and Spoofing
The servers load balanced by Equalizer provide applications or services on specific IP addresses and ports, and are
organized into virtual clusters, each with its own IP address. Clients send requests to the cluster IP addresses on
Equalizer (instead of sending them to the IP addresses of the servers).
Central to the operation of any load balancer is the Network Address Translation (NAT) subsystem. On Equalizer,
NAT is used in the following ways:
1.When Equalizer receives a client packet, it always translates the destination IP (the cluster IP) to the IP address
of one of the servers in the cluster. The server IP used is determined by the cluster’s load balancing settings.
2.Depending on the setting of the cluster
When the
spoof option is enabled, then SNAT is disabled: the NAT subsystem leaves the client IP address as
the source IP address in the packet it forwards to the server. For this reason, the servers in a cluster with
enabled are usually configured to use Equalizer’s IP as their default gateway, to ensure that all responses go
through Equalizer (otherwise, the server would attempt to respond directly to the client IP).
When the
spoof option is disabled, then SNAT is enabled. Equalizer translates the source IP (the client IP) to
one of Equalizer’s IP addresses before forwarding packets to a server. The servers will send responses back to
Equalizer’s IP (so it is usually not necessary to set Equalizer as the default gateway on the servers when
is disabled).
spoof option, Equalizer may also perform Source NAT, or SNAT.
spoof
spoof
Match rules can be used to selectively apply the
selective SNAT. See the section “Changing the Spoof (SNAT) Setting Using Match Rules” on page 231.
3.When a server sends a response to a client request through Equalizer, the NAT subsystem always translates the
source IP in the response packets (that is, the server IP) to the cluster IP to which the client originally sent the
22Equalizer Installation and Administration Guide
spoof option to client requests. This is sometimes called
Introducing Equalizer
request. This is necessary since the client sent its original request to the cluster IP and will not recognize the
server’s IP address as a response to its request -- instead, it will drop the packet.
4.NAT can also be enabled for packets that originate on the servers behind Equalizer and are destined for subnets
other than the subnet on which the servers reside -- on Equalizer, this is called outbound NAT. This is usually
required in dual network mode when reserved IP addresses (e.g., 10.x.x.x, 192.168.x.x) are being used on the
internal interface, so that the recipients do not see reserved IP addresses in packets originating from the servers.
When the global
outbound NAT option is enabled, Equalizer translates the source IP in packets from the servers
that are not part of a client connection to the Equalizer’s Default VLAN IP address (the external interface IP
address on the E250GX and legacy ‘si’ systems), or to the address specified in the server’s
Enabling
outbound NAT, as a result, has a performance cost since Equalizer is examining every outbound
Outbound NAT tab.
packet.
Note – When Equalizer is in single network mode, outbound NAT should be disabled. Since Equalizer
resides on a single subnet, outbound NAT is not needed, and may cause unexpected behavior. See “Adding
Equalizer to Your Network” on page 29 for a description of Equalizer’s network modes.
Note that when Equalizer receives a packet that is not destined for a virtual cluster IP address, a failover IP address,
a client IP address on an open connection, or one of its own IP addresses, Equalizer passes the packet through to the
destination network unaltered.
For more information:
•about setting NAT and spoofing options, see “Working with Virtual Clusters” on page 112.
•about using reserved, non-routing IP addresses with Equalizer, see Appendix C, ”Using Reserved IP
Addresses” on page 271.
Maintaining Persistent Sessions and Connections
The persistence of session data is important when a client and server need to refer to data previously generated
again and again as they interact over more than one transaction, possibly more than one connection. Whenever a
client places an item in a shopping cart, for example, session data (the item in the cart, customer information, etc.) is
created that potentially needs to persist across many individual TCP connections before the data is no longer needed
and the session is complete.
It’s important to note that session persistence is managed by the server application, not Equalizer. Equalizer provides
server persistence so that a persistent connection between a particular client and a particular server can be
maintained; this supports a client-server session where session data is being maintained on the server for the life of
the connection. In other words, whether you need to enable persistence on Equalizer depends on the application you
are load balancing.
Equalizers have no knowledge of the fact that the user has placed something in a shopping cart, logged into a web
application, requested a file from shared storage, or made a "post" in a front end presentation server that has been
written to a database. Basically, a "state" has been created in the load balanced application of which Equalizer is not
aware. What Equalizer does know is that a specific client has been load balanced to a specific server in one of its
virtual clusters. With this knowledge, Equalizer can track that information and send that client back to the same
server they were connected the first time.
Equalizer provides server or connection persistence using cookies in Layer 7 HTTP and HTTPS clusters, and using
the client IP address in Layer 4 TCP and UDP clusters. The following sections explain connection persistence
provided by Equalizer, and its relationship to session persistence.
Cookie-Based Persistence (Layer 7)
Equalizer can use cookie-based persistent connections for Layer 7 HTTP and HTTPS clusters. In cookie-based
persistence, Equalizer "stuffs" a cookie into the server's response header on its way back to the client. This cookie
Equalizer Installation and Administration Guide23
Chapter 1: Equalizer Overview
uniquely identifies the server to which the client was just connected. The client includes (sends) the cookie in
subsequent requests to the Equalizer. Equalizer uses the information in the cookie to route the requests back to the
same server.
Equalizer can direct requests from a particular client to the same server, even if the connection is to a different
virtual cluster. For example, if a user switches from an HTTP cluster to an HTTPS cluster, the persistent cookie will
still be valid if the HTTPS cluster contains a server with the same IP address.
If the server with which a client has a persistent session is unavailable, Equalizer automatically selects a different
server. Then, the client must establish a new session; Equalizer stuffs a new cookie in the next response.
IP-Address Based Persistence (Layer 4)
For Layer 4 TCP and UDP clusters, Equalizer supports IPaddress based persistent connections. With the sticky
connection feature enabled, Equalizer identifies clients by their IP addresses when they connect to a cluster.
Equalizer then routes requests received from a particular client during a specified period of time to the same server
in the cluster.
A sticky timer measures the amount of time that has passed since there was a connection from a particular IP address
to a specific cluster. The sticky time period begins to expire as soon as there are no longer any active connections
between the client and the selected cluster. Equalizer resets the timer whenever a new connection occurs. If the client
does not establish any new connections to the same cluster, the timer continues to run until the sticky time period
expires. At expiration, Equalizer handles any new connection from that client like any other incoming connection
and routes it to an available server based on the current load balancing policy.
To correctly handle sticky connections from ISPs that use multiple proxy servers to direct user connections,
Equalizer supports sticky network aggregation, which uses only the network portion of a client's IP address to
maintain a persistent connection. Sticky network aggregation directs the user to the same server no matter which
proxy he or she connects through.
You can also configure Equalizer to ensure that it directs requests from a particular client to the same server even if
the incoming connection is to a different virtual cluster. When you enable intercluster stickiness for a cluster,
Equalizer checks the cluster for a sticky record as it receives each connection request, just like it does for ordinary
sticky connections. If Equalizer does not find a sticky record, Equalizer proceeds to check all of the other clusters
that have the same IP address. If Equalizer still does not find a sticky record, it connects the user based on the
current load balancing policy.
Is Connection Persistence Always Needed With Session Persistence?
Session persistence is a function of the application and the state created when a user logs into a web site. If the
session persistence is maintained in the front end server, then Equalizer cookie persistence should be enabled. The
client must maintain the connection to the same front end server in order for the login to remain valid. For example,
Windows Terminal Services maintains a session directory "database" when a user logs into a session. If that state or
database is in the front end server, or even in a back end server that only associates the client connection to that front
end server, then the client must "persist" to the front end server to which it is originally connected.
In other configurations, the session "state" is kept in shared storage in a backend server or database that is accessible
to all the front end servers. If this is the case, then connection persistence may not be needed; if the user is balanced
among servers, then the session can still be maintained across the front end server group via access to the shared
storage.
It’s therefore important to understand how the load balanced application provides session persistence when
managing persistent connections on Equalizer.
Layer 7 Load Balancing and Server Selection
Equalizer’s support for Layer 7 content-sensitive load balancing enables administrators to define rules for routing
HTTP and HTTPS requests, depending on the content of the request. Layer 7 load balancing routes requests based
24Equalizer Installation and Administration Guide
Introducing Equalizer
Internet
Envoy
Site A
Envoy
Site B
on information from the application layer. This provides access to the actual data payloads of the TCP/UDP packets
exchanged between a client and server. For example, by examining the payloads, a program can base load-balancing
decisions for HTTP requests on information in client request headers and methods, server response headers, and
page data.
Equalizer’s Layer 7 load balancing allows administrators to define rules in the administration interface for routing
HTTP and HTTPS requests according to the request content. These rules are called match rules. A match rule might,
for example, route requests based on whether the request is for a text file or a graphics file:
•
load balance all requests for text files (html, etc.) across servers A and B
•load balance all requests for graphics files across servers C, D, and E
•load balance all other requests across all of the servers
Match Rules are constructed using match functions that make decisions based on the following:
•HTTP protocol version; for HTTPS connections, the SSL protocol level the client uses to connect.
•Client IP address
•Request method (GET, POST, etc.)
•All elements of the request URI (host name, path, filename, query, etc.)
•Pattern matches against request headers
Match functions can be combined using logical constructs (AND, OR, NOT, etc.) to create extremely flexible cluster
configurations. Please see “Using Match Rules” on page 207 for an overview of Match Rules, a complete list of
match functions, and usage examples.
Geographic Load Balancing
The optional Envoy add-on supports , which enables requests to be automatically distributed across Equalizer sites
in different physical locations. An Equalizer site is a cluster of servers under a single Equalizer’s control. A is a
collection of sites that provide a common service, such as Web sites. The various sites in a geographic cluster can be
hundreds or even thousands of miles apart. For example, a geographic cluster might contain two sites, one in the
eastern U.S. and one on the U.S.’s west coast (Figure 1).
Geographic load balancing can dramatically improve reliability by ensuring that your service remains available even
if a site-wide failure occurs. Equalizer can also improve performance by routing requests to the location with the
least network latency.
Figure 1 Geographic cluster with two sites
Equalizer Installation and Administration Guide25
Chapter 1: Equalizer Overview
Geographic Load Balancing Routing
Envoy routes each incoming request to the site best able to handle it. If a site is unavailable or overloaded, Envoy
routes requests to the other sites in the geographic cluster. When you enable geographic load balancing, Envoy
directs incoming client requests to one of the sites in the geographic cluster based on the following criteria:
•Availability: If a site is unavailable due to network outage, server failure, or any other reason, Equalizer
stops directing requests to that site.
•Performance: Envoy tracks the load and performance at each site and uses this information to determine
the site that can process the request most efficiently.
•Distance: Envoy notes the site that is closest to the client (in network terms) and offers the least network
latency.
Distributing the Geographic Load
Envoy uses the Domain Name System (DNS) protocol1 to perform its geographic load distribution. DNS translates
fully-qualified domain names such as
Internet. For Envoy, the authoritative name server for the domain is configured to query the Equalizers in the
geographic cluster to resolve the domain name. When Envoy receives a resolution request, it uses the load-balancing
algorithms configured for the geographic cluster to determine the site that is best able to process the request and then
returns the address of the selected site.
www.coyotepoint.com into the IP addresses that identify hosts on the
For example, the geographic cluster
www.coyotepoint.com might have three sites (see Figure 2): one on the east
coast of the U.S., one on the west coast of the U.S., and one in Europe. The servers at each site are connected to an
Equalizer with the Envoy add-on installed.
When a client in California attempts to connect to coyotepoint.com:
1. For more information about DNS, see Paul Albitz and Cricket Liu, DNS and BIND, 3rd ed. (O'Reilly & Associates, 1998).
26Equalizer Installation and Administration Guide
1.The client queries its local DNS server to resolve the domain name (see Figure 3).
Envoy Site B
(West Coast USA)
Envoy Site A
(East Coast USA)
Internet
Envoy Site C
(Europe)
Client
(California, USA)
Client’s
Local DNS
Authoritative
DNS
for
coyotepoint.com
Envoy Site B
(West Coast USA)
Envoy Site A
(East Coast USA)
Internet
Envoy Site C
(Europe)
Client
(California, USA)
Client’s
Local DNS
Authoritative
DNS
for
coyotepoint.com
Introducing Equalizer
Figure 3 Client queries its local DNS for coyotepoint.com
2.The local DNS server queries the authoritative name server for coyotepoint.com (see Figure 4).
Figure 4 Client’s local DNS queries the authoritative name server for coyotepoint.com
Equalizer Installation and Administration Guide27
Chapter 1: Equalizer Overview
Envoy Site B
(West Coast USA)
Envoy Site A
(East Coast USA)
Internet
Envoy Site C
(Europe)
Client
(California, USA)
Client’s
Local DNS
Authoritative
DNS
for
coyotepoint.com
3.The authoritative name server provides a list of Envoy-enabled Equalizer sites and returns this list to the client’s
local DNS server (see Figure 5).
Figure 5 The authoritative name server for coyotepoint.com returns a list of delegates
4.The client’s DNS server sends a request for the IP address of coyotepoint.com to each Envoy site in the list
until one of them responds.
5.The Envoy site contacted returns the IP Address of the virtual cluster best able to handle the client’s request.
6.Finally, the client’s local DNS server returns the virtual cluster IP to the client, which then sends the request to
(For an overview of how Envoy chooses the virtual cluster IP to return to the client’s DNS, see “Administering
GeoClusters” on page 237.)
the virtual cluster.
28Equalizer Installation and Administration Guide
Adding Equalizer to Your Network
Serial Port
External Interface Port
Internal Interface Port
Adding Equalizer to Your Network
Equalizer is a versatile traffic management and application acceleration solution that is easily configured for your
network. Equalizer models E350GX and above have 12 or more front panel network switch ports, are Virtual Local
Network (VLAN) capable, and can be configured for tagged and untagged VLANs. Equalizer model E250GX has
two front panel ports configured into two port based VLANs.
Note – VLAN management capabilities were introduced in Version 8.6 of the Equalizer O/S software on Equalizer
GX hardware. If you are running Version 8.6 or later on pre-GX Equalizer hardware (such as the ‘si-R’ hardware),
the front-panel switches are managed as they were in Version 8.5 of the Equalizer software. Please refer to the
Version 8.5 Installation and Administration Guide at docs.coyotepoint.com.
Equalizer E250GX Network Configuration
Equalizer model E250GX has two front-panel network interface ports configured into two untagged (or port-based)
Virtual Local Networks (VLANs): the External Network VLAN and the Internal Network VLAN. Initial network
configuration of Equalizer is performed over the serial port, where you assign an IP address to one or both of the
network interface ports. The figure below shows the port configuration of an E250GX model Equalizer.
Figure 6 Equalizer E250GX default port configuration
The E250GX can be deployed in either a single network or a dual network configuration:
•In a single network configuration, all cluster IPs and server IPs are on the same subnet, and are connected
to Equalizer using the Internal Interface Port; the External Interface Port is unused.
•In a dual network configuration, all cluster IPs are on one subnet connected to Equalizer using the External
Interface Port, while servers are on another subnet connected to Equalizer’s Internal Interface Port.
Equalizer Installation and Administration Guide29
Chapter 1: Equalizer Overview
Using Equalizer E250GX in a Single Network Environment
In single network mode, the client systems, servers, Intranet and/or Internet must all connect to Equalizer through
the Internal Interface Port. Figure 7 shows an example.
Figure 7 Example single network configuration for Equalizer E250GX
Single network mode is often the simplest way to fit Equalizer into an existing network with minimal changes to the
current network infrastructure. Certain protocols and applications that use dynamic port mapping or multiple TCP/
UDP ports may also work best in a single network environment.
As you can see in the example above, Equalizer’s internal IP, cluster IP, and all server IPs are located on the
192.168.0.x network, and communicate through the same switch. The switch, in turn, is connected to a router which
is this subnet’s gateway to other subnets on the Intranet and Internet networks. The gateway or router that conects
Equalizer’s subnet to the Intranet and Internet is assumed to perform all necessary NAT for external clients, so they
can access Equalizer’s cluster IPs.
Internal clients can access the cluster IPs directly, and so may require selective SNAT on Equalizer or special routing
on the servers to ensure that all server responses go through Equalizer.
30Equalizer Installation and Administration Guide
Loading...
+ 314 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.