This document describes how to set up several different server configurations using the Eddie Enhanced DNS Server and Intelligent HTTP Gateway applications. For an overview of how Eddie works please refer to the White Paper (Web Servers for Commercial Environments: The imperatives and the solution.)
Section 1: Basic Load Balancing and Failure Detection
Section 2: Advanced Load Balancing and Failure Detection
Section 4: Admission Control and Quality of Service
In this section, we describe how to configure Eddie to perform basic load balancing and the automatic detection of server failure. No admission control or URL parsing is performed in the following configurations.
This example comprises two servers located on a single Local Area Network and an Enhanced DNS running on another computer as shown in Figure 1.
Figure 1: Two servers and an Enhanced DNS running on another computer
We will use the Enhanced DNS to distribute DNS translation requests across server01.eddieware.org and server02.eddieware.org. The Enhanced DNS domain file is constructed so as to have the domain www.eddieware.org include server01 and server02.
There are two basic ways in which load balancing and automatic failure detection may be achieved.
In each case, we will start Eddie Front End and Back End nodes on each server. However, the Front Ends and Back Ends are used only to convey load information between each other and the Enhanced DNS.
Note that there is no application dependence when only the DNS performs load balancing. That is, the DNS can perform load balancing for any IP-based application in which the same information is replicated on each server. Examples can include HTTP, FTP, and so on.
This method describes how to perform basic load balancing and the automatic detection of server failure by defining each server on a LAN to be a cluster in its own right
We start an Eddie Front End (FE) node and an Eddie Back End (BE) node on each server.
We configure the two servers as two distinct, single computer clusters. The FE on a server is responsible for monitoring the BE on the same server.
Each FE will automatically report the load information on its server to the Enhanced DNS. The Enhanced DNS will automatically perform load balancing of incoming address translations across the two servers. If a server fails, it stops sending load information to the Enhanced DNS. The Enhanced DNS will, after a period, decide that the server has failed and stop translating incoming address resolutions to that server.
When the failed server comes back on-line it will recommence sending load information to the Enhanced DNS, which will then return it to the pool of available servers and start sending it traffic again.
The configuration files for this example are as follows:
#---------------------------------------------------------------------- # File : Method1.1.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- # No instructions needed in the Gateway configuration file # since Front Ends will not be the entry point for HTTP requests # to the server # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method1.1.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@host01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@host02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@host01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@host02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend BackendClusters backend01.eddieware.org <Server eddieFE@host01> AutoConfig Off IPAddress 10.0.0.11 </Server> </Cluster> <Cluster www02.eddieware.org> ClusterType Frontend BackendClusters backend02.eddieware.org <Server eddieFE@host02> AutoConfig Off IPAddress 10.0.0.12 </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@host01> AutoConfig Off IPAddress 10.0.0.11 </Server> </Cluster> <Cluster backend02.eddieware.org> ClusterType Backend <Server eddieBE@host02> AutoConfig Off IPAddress 10.0.0.12 </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method1.1.boot # Purpose : Load balancing via the Enhanced DNS: The DNS boot file #-------------------------------------------------------------- Port 6789 TTL 120 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
Note: This method describes how to perform basic load balancing and the automatic detection of server failure by having all servers act as a single cluster.
We start an Eddie Front End (FE) node and Eddie Back End (BE) node on each server. We configure the two servers as belonging to a single cluster. The FE on each server will monitor each BE.
A Master FE will be elected and will report the load information on the cluster as a whole to the Enhanced DNS, as well as the load on each server running a FE (which is each server in this case).
The Enhanced DNS will automatically perform load balancing of incoming address translations across the two servers. If a server fails, the FEs on the other servers will automatically detect the failure of the FE on that server. The remaining FEs will elect a new Master FE, which will take over sending the load information to the DNS. Further, the failure of the FE will also be reported. The enhanced DNS will then rebalance the load sent to each active server.
When the failed server comes back on-line, the Master FE will detect it and inform the Enhanced DNS, which will then return it to the pool of available servers and start sending it traffic again.
#---------------------------------------------------------------------- # File : Method1.2.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- # No instructions needed in the Gateway configuration file # since Front Ends will not be the entry point for HTTP requests # to the server # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method1.2.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@host01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@host02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@host01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@host02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend BackendClusters backend01.eddieware.org <Server eddieFE@host01> AutoConfig Off IPAddress 10.0.0.11 </Server> <Server eddieFE@host02> AutoConfig Off IPAddress 10.0.0.12 </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@host01> AutoConfig Off IPAddress 10.0.0.11 </Server> <Server eddieBE@host02> AutoConfig Off IPAddress 10.0.0.12 </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method1.2 .boot # Purpose : Load balancing via the Enhanced DNS #-------------------------------------------------------------- Port 6789 TTL 200 Netmask 10.0.0.0/24 Domain www.eddieware.org #End of dns boot file ----------------------------------------
In some cases, it might be preferable to use the load-balancing DNS features without using the Eddie Gateway's other features. Every machine that the Eddie DNS load balances requires a load server to run and send data to the DNS. Each machine is treated as a separate cluster and only runs a load server to send data to the DNS. To start the Intelligent HTTP Gateway as only a load server, we start Eddie with the -load option and a configuration file like the one described in Method1.1.mig .
We now describe how to use the advanced load balancing and failure detection capabilities of Eddie. More explicitly, we show how to use the Eddie Front Ends as the HTTP access point to the web site. By doing this, we enable Eddie's URL parsing and admission control capabilities, which will be demonstrated in Sections 3 and 4.
In these two examples we again look at a multi-computer web server located on a single Local Area Network, as in Figure 1. The only difference from the previous section is that we have arranged to make use of alias IP addresses, 10.0.0.21 and 10.0.0.22, nominally assigned as shown.
In order to have the Eddie Front Ends receive HTTP requests, the FEs must "take control" of Port 80 (the usual HTTP port). If the BE and FE are on the same computer, the Apache web servers must use another port, in this case, we select 8001. The Eddie Front Ends will then receive incoming requests, and establish a connection with an Apache server on Port 8001.
In these configurations, the Front End nodes take responsibility for distributing traffic across the Apache Servers, rather than the DNS. The DNS still performs a load balancing function, namely, load balancing across the Front End nodes.
In this somewhat contrived example, the fact the Front End nodes and Back End nodes are on the same machines means that the balancing is unnecessarily being performed twice. However, in the next section we will show how to configure Eddie with Front End and Back End nodes on different machines, the result being a convenient method for performing load balancing hierarchically.
The configurations described in the following section have two Front End servers and two Back End servers, as shown in Figure 2.
Figure 2: Front End and Back End nodes on different machines
In this example, we retain the static IP addresses of each server, that is, we do not use the aliased IP addresses. They will be used in Method 2.2.
The configuration files for this example look very similar to those of Method 1.2 in the previous section. The differences are highlighted in bold.
#---------------------------------------------------------------------- # File : Method2.1.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> AdmitTime 600 AdmitControl false # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns uri / Proxy 10.0.0.11 8001 </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns uri / Proxy 10.0.0.12 8001 </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method2.1.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@fe01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@fe02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@server01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@server02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend BackendClusters backend01.eddieware.org <Server eddieFE@fe01> AutoConfig Off IPAddress 10.0.0.21 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> <Server eddieFE@fe02> AutoConfig Off IPAddress 10.0.0.22 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@server01> AutoConfig Off IPAddress 10.0.0.11 </Server> <Server eddieBE@server02> AutoConfig Off IPAddress 10.0.0.12 </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method2.1.boot # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #-------------------------------------------------------------- Port 6789 TTL 200 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
We now move to performing load balancing across a set of Apache web servers, but with the Eddie Front End nodes running on dedicated machines and Eddie controlling the starting and stopping of the Apache servers.
To keep the examples as similar to those discussed previously, we will add two new computers to our LAN, fe01 and fe02, and run a single Front End node on each.
The two Apache web servers will still run on server01 and server02 using Port 8001, as previously, and an Eddie Back End node will be started on each of these.
In order to have the Eddie Back End nodes control the Apache we require:
A major advantage of having Eddie control the web servers themselves is that if the web servers fail, Eddie is able to automatically restart them. With regard to failure modes, if a machine running an Eddie Front End fails, it will be detected by the other Front Ends, the Enhanced DNS notified, and traffic routed away from the failed Front End to the other two. These Front Ends will still distribute traffic across all two Apache servers.
If an Apache server machine fails, both Front End Nodes will detect the failure and automatically route traffic only to the remaining Apache servers. The Enhanced DNS will not be notified of such events as the Front Ends have the situation under their local control.
The DNS will translate incoming requests to the computers running the Eddie Front End Nodes, rather than the machines running the Apache web servers. Thus, changes need to be made to the DNS zone files, as well as the Eddie configuration files. The changes from the previous example are highlighted in bold.
#---------------------------------------------------------------------- # File : Method2.2.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> AdmitTime 600 AdmitControl false # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns uri / Proxy 10.0.0.11 8001 </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns uri / Proxy 10.0.0.12 8001 </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method2.2.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@fe01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@fe02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@server01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@server02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend BackendClusters backend01.eddieware.org <Server eddieFE@fe01> AutoConfig Off IPAddress 10.0.0.21 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> <Server eddieFE@fe02> AutoConfig Off IPAddress 10.0.0.22 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@server01> AutoConfig Off IPAddress 10.0.0.11 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> <Server eddieBE@server02> AutoConfig Off IPAddress 10.0.0.12 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method2.2.boot # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #-------------------------------------------------------------- Port 6789 TTL 200 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
We now move to performing fault detection and automatic failover for Eddie Front End nodes. This will be achieved via the Eddie IP address migration capability.
To do this, we will need two unassigned IP addresses to use as aliases. We now configure the Eddie Front End nodes using the Autoconfig capability, but using the IP alias addresses rather than the static IP addresses of fe01 and fe02.
If a machine running an Eddie Front End fails, it will be detected by the other Front Ends. One of the remaining Front End nodes takes over the aliased IP address of the failed machine. Traffic destined for the failed machine is still correctly processed, but by another Front End. Should the machine that took over the failed IP address become heavily loaded, the DNS will automatically re-distribute the traffic.
If an Apache server machine fails, both Front End nodes will detect the failure and automatically route traffic only to the remaining Apache servers. The Enhanced DNS will not be notified of such events as the Front Ends have the situation under their local control.
The DNS will translate incoming requests to the computers running the Eddie Front End nodes, but using the alias IP addresses rather than the actual IP addresses of the machines running the Front End nodes. Thus, changes again need to be made to the DNS zone files, as well as the Eddie configuration files. The changes from the previous example are highlighted in bold.
#---------------------------------------------------------------------- # File : Method2.3.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> AdmitTime 600 AdmitControl false # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns uri / Proxy 10.0.0.11 8001 </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns uri / Proxy 10.0.0.12 8001 </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method2.3.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@fe01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@fe02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@server01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@server02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend FailoverNodes eddieFE@fe01 eddieFE@fe02 BackendClusters backend01.eddieware.org <Server eddieFE@fe01> AutoConfig On IPAddress 10.0.0.201 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> <Server eddieFE@fe02> AutoConfig On IPAddress 10.0.0.202 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@server01> AutoConfig Off IPAddress 10.0.0.11 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> <Server eddieBE@server02> AutoConfig Off IPAddress 10.0.0.12 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method2.3.boot # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #-------------------------------------------------------------- Port 6789 TTL 200 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
We now move to performing URL pattern matching and using pattern matching to distribute incoming requests to servers dedicated to specific purposes.
Pattern matching may be used on a number of HTTP header and request fields. The header/request lines that can be matched have to be in the file http_fields .erl in inet_server/src/ . These include:
Anti-patterns may also be used (anti-pattern is our term for not matching), for example ^www.eddieware.org means not the pattern www.eddieware.org . Pattern matching is case sensitive in Eddie.
If more than one server can handle a particular request, the Front End performs load balancing across those servers. Within a single client session, once a server has been selected it continues to be used until a request arrives that the server cannot handle.
Information on placement of functionality on Back End servers is placed in the .gate file within the schedules of each Back End node. An example definition a schedule is shown below.
In the example below, server01 can receive all requests for URIs that are not destined www.eddieware.org excluding those URIs referencing objects matching /manual/images . And server02 can receive all requests for URIs on host www.eddieware.org .
Note that the .mig and .boot are unchanged from the previous example.
#---------------------------------------------------------------------- # File : Method3.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> AdmitTime 600 AdmitControl false # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns host www.eddieware.org Patterns uri / ^/manual/images Proxy 10.0.0.11 8001 </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns host www.eddieware.org Patterns uri / Proxy 10.0.0.12 8001 </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method3.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@fe01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@fe02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@server01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@server02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend FailoverNodes eddieFE@fe01 eddieFE@fe02 BackendClusters backend01.eddieware.org <Server eddieFE@fe01> AutoConfig On IPAddress 10.0.0.201 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> <Server eddieFE@fe02> AutoConfig On IPAddress 10.0.0.202 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@server01> AutoConfig Off IPAddress 10.0.0.11 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> <Server eddieBE@server02> AutoConfig Off IPAddress 10.0.0.12 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> </Cluster> # End of migration file --------------------------------------
#-------------------------------------------------------------- # File : Method3.boot # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #-------------------------------------------------------------- Port 6789 TTL 200 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
Admission control enables a certain quality of service to be offered to users admitted to a web site. A user admitted to a site with admission control will receive priority access to server resources over new users. This ensures that any delay in moving from web page to web page on the server are minimised, thereby ensuring that the "service" a user perceives is maintained at an acceptable level. This improves the perception of the quality of the site, while also minimising the number of clients that abandon the site due to dissatisfaction.
If a web site is receiving more hits than it is physically capable of processing with rapid response time, the admission control feature dynamically determines the rate that new sessions may be forwarded to the Back End Apache web servers. The Front End nodes then queue the excess sessions and return a page to the client informing them that the system is heavily loaded and that there will be a delay in giving them access to the server.
Within Eddie, a session is defined as a series of interactions between the client and the server, with each interaction occurring within an administrator defined time of the previous one. All transactions for sessions that have already been admitted to the Back End Apache servers bypass the admission control function, so only new sessions (that is, those that have not started yet) are subject to admission control.
To configure Eddie to use this functionality requires no changes to the .mig or .boot files from the previous example. We need only change the .gate file to instruct the Front End nodes to activate admission control and set up the required parameters.
Activate Admission Control (AdmitControl true) .
Allow 600 seconds between user interactions before we decide that a session has terminated (AdmitTime 600) .
Always allow requests from users at IP number 150.120.90.* into the server, regardless of the load on the system (AdmitAlways 150.120.90.*) .
Always reject requests from users at IP number 150.120.100.* from the server, regardless of the load on the system (AdmitNever 150.120.100.*) .
Subject all requests from any other IP numbers to admission control.
Allow a maximum of 100 sessions to be active simultaneously (AdmitMaxSessions 100) .
Allow up to 1,000 session requests to be queued for later admission. Requests in excess of this limit are termed "blocked" requests (AdmitQueuePlaces 1000) .
Send Rejected clients the HTML page defined in the file /eddie_admit_reject (AdmitRejectPage /eddie_admit_reject) .
Send Queued clients the HTML page defined in the file /eddie_admit_queue (AdmitQueuePage /eddie_admit_queue) .
Send Blocked clients the HTML page defined in the file /eddie_admit_block (AdmitBlockPage /eddie_admit_block) .
Run the erlet /erlet_admit_ctrl to construct the HTML page that clients see when they are blocked from a site.
#---------------------------------------------------------------------- # File : Method4.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> AdmitTime 600 AdmitControl true AdmitAlways 150.120.90.* AdmitNever 150.120.100.* AdmitMaxSessions 100 AdmitQueuePlaces 1000 AdmitRejectPage /eddie_admit_reject AdmitQueuePage /eddie_admit_queue AdmitBlockedPage /eddie_admit_blocked <Erlets admit_control> <Erlet erlet_admit_ctrl> </Erlet> </Erlets> # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns host www.eddieware.org Patterns uri / ^/manual/images Proxy 10.0.0.11 8001 </Schedule> <Schedule> Patterns uri /eddie_admit Erlets admit_control </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns host www.eddieware.org Patterns uri / Proxy 10.0.0.12 8001 </Schedule> <Schedule> Patterns uri /eddie_admit Erlets admit_control </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
#---------------------------------------------------------------------- # File : Method4.mig # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- DNSServer dns.eddieware.org 6789 # define a Front End node for each server <Node eddieFE@fe01> LoadThreshold 0.8 4.0 Interfaces de1 </Node> <Node eddieFE@fe02> LoadThreshold 0.8 4.0 Interfaces de1 </Node> # define a Back End node for each server <Node eddieBE@server01> LoadThreshold 0.8 4.0 Interfaces de0 </Node> <Node eddieBE@server02> LoadThreshold 0.8 4.0 Interfaces de0 </Node> Netmask 255.255.255.255 # Configure each of the Front End Nodes # Each Front End is in the one cluster <Cluster www01.eddieware.org> ClusterType Frontend FailoverNodes eddieFE@fe01 eddieFE@fe02 BackendClusters backend01.eddieware.org <Server eddieFE@fe01> AutoConfig On IPAddress 10.0.0.201 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> <Server eddieFE@fe02> AutoConfig On IPAddress 10.0.0.202 Interface de1 Start generic module eddie start @IPAddress @Port http Stop generic module eddie stop @IPAddress @Port http </Server> </Cluster> #Define each of the Back End Nodes <Cluster backend01.eddieware.org> ClusterType Backend <Server eddieBE@server01> AutoConfig Off IPAddress 10.0.0.11 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> <Server eddieBE@server02> AutoConfig Off IPAddress 10.0.0.12 Port 8001 Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/local/sbin/httpd /usr/local/lib/eddie/conf/conf Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port </Server> </Cluster> # End of migration file -------------------------------------- #-------------------------------------------------------------- # File : Method4.boot # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #-------------------------------------------------------------- Port 6789 TTL 120 Netmask 10.0.0.0/24 Domain www.eddieware.org # End of dns boot file ----------------------------------------
The differentiated quality of service feature in Eddie allows a web site operator to provide preferential treatment to particular clients. The operator can set up different levels of services so that preferred clients will be queued for shorter period of time compared to other clients.
The site operator can define different levels of service by specifying weights for the service. For example, a site might want to have 3 classes of clients: gold, silver and bronze. The gold class may be give a weight of 100, the silver class 30 and the bronze class 5.
Suppose that there are clients queued to a web site and the clients that are in the queue belong to the gold and bronze classes. There are no clients being queued in the silver class. When a client is to be selected to enter the site, the probability of a gold class client being selected is 100/(100+5). Similarly, the probability of a bronze class client being selected is 5/(100+5).
The clients identify themselves by means of persistent cookies (RFC2109) stored on their browsers. This cookie may be implanted during a previous session. It is up to the web server or application server on the backends to implant these cookies.
When a client attempts to enter a web site and the site is loaded, Eddie will attempt to queue the client. It inspects the request for cookies that determines the treatment of the client. When the site's load has reduced sufficiently, it might be time to select a client for entry into the site. The chances of the client being selected is according to the weighting of the client. From the point of view of the clients, there isn't any difference.
Using the example above, the following configuration block can be written in the "Frontend" configuration block in the gateway file. Following the above example, the configuration block can be written in the "Frontend" configuration block in the gateway file. The .mig and .boot files remain unchanged.
#---------------------------------------------------------------------- # File : Method5.gate # Purpose : Load balancing via the Enhanced DNS and Eddie Front End Nodes #---------------------------------------------------------------------- <Frontend http> ProtocolModule http # Tell the Front End Nodes to accept requests on Port 80 <EndpointConfig http_tcp> Port 80 ReadTimeout 480 KeepAliveTimeout 20 ExternalProxy usr/local/lib/eddie/bin/relay @ip @port @control_port </EndpointConfig> <QoS> CookieName ServiceLevel <Queue gold> CookieValue gold Weight 100 </Queue> <Queue silver> CookieValue silver Weight 30 </Queue> <Queue bronze> CookieValue bronze Weight 5 </Queue> </QoS> AdmitTime 600 AdmitControl true AdmitAlways 150.120.90.* AdmitNever 150.120.100.* AdmitMaxSessions 100 AdmitQueuePlaces 1000 AdmitRejectPage /eddie_admit_reject AdmitQueuePage /eddie_admit_queue AdmitBlockedPage /eddie_admit_blocked <Erlets admit_control> <Erlet erlet_admit_ctrl> </Erlet> </Erlets> # Tell the Front End Nodes to act as a proxy and send all # requests through to Port 8001 <Backend http_tcp eddieBE@server01> <Schedule> Patterns host www.eddieware.org Patterns uri / ^/manual/images Proxy 10.0.0.11 8001 </Schedule> <Schedule> Patterns uri /eddie_admit Erlets admit_control </Schedule> </Backend> <Backend http_tcp eddieBE@server02> <Schedule> Patterns host www.eddieware.org Patterns uri / Proxy 10.0.0.12 8001 </Schedule> <Schedule> Patterns uri /eddie_admit Erlets admit_control </Schedule> </Backend> </Frontend> # End of Gateway configuration file -----------------------------------
