Eddie HTTP Gateway: Installation and Configuration Guide

 

Contents

    1 Introduction 1
    1.1 Definitions 2
    1.2 Prerequisites 2
    2 Installation Procedure 2
    2.1 Access Permissions 4
    3 Configuring the Gateway 4
    3.1 Eddie Configuration File 4
    3.2 Gateway Configuration File 5
    4 The IP Migration Configuration File 9
    5 Configuration Examples 12
    6 Starting the Gateway 14
    7 References 15
    8 Configuration Files 15

 

1 Introduction

This document provides installation and configuration instructions for the Intelligent HTTP Gateway application.

Eddie is a 100% software solution for delivering commercial grade, quality of service to Internet sites.

Eddie consists of two main software packages:

1. The Enhanced DNS server which provides load balancing and monitoring of site accessibility for geographically distributed web sites.

2. The Intelligent HTTP Gateway which provides site based:

This document provides detailed instructions on the installation and configuration of the Eddie Intelligent HTTP Gateway Enhanced DNS and describes two example configurations. For installation information on the Eddie Enhanced DNS, see Eddie Enhanced DNS: Installation and Configuration Guide.

 

1.1 Definitions

Back End- A computer running a web server.

Erlang- A functional programming language developed by Ericsson. Information on Open Source Erlang may be found at www.erlang.org/erlang.html.

Front End - A computer running one or more instances of the Intelligent HTTP Gateway.

Node- An Erlang node. In this case, either an instance of the Intelligent HTTP Gateway (on a Front End), or an instance on a Back End which receives HTTP requests from Front Ends.

 

1.2 Prerequisites

Successful installation of Eddie using these guidelines assumes the following:

1) Secure shell (ssh) is installed on each computer and authorisation keys have been established on all computers for the user who will actually run Eddie. It is important that eddie is in the user path, this can be set in $HOME/.ssh/environment

or

Remote shell (rsh) is used and all computers are in each others .rhosts files for the user who will run Eddie.

2) Open Source Erlang 47.4.1 must be installed on all computers.

3) The program "GNU make" must be available. See www.gnu.org for details.

4) The Enhanced DNS server is plug-in compatible with named-4.x.y (BIND). Understanding of how to configure and use "named" is required to configure the base functionality of this server, e.g. knowledge about named.boot files, master files, and zone transfer configurations. There are a number of books available on this topic.

5) Each computer is running either:

  1. Red Hat Linux 5.2 and above,
  2. FreeBSD 2.2.8 and above,
  3. Solaris 2.5.1 and above, or
  4. Windows NT 4.0 Service Pack 5 with Cygnus 20.1B (as of Eddie 1.3.2).

7) Minor variations from the above should still work, but we have encountered minor problems on occasion. For help in such situations, please email talk@eddieware.org.

 

2 Installation Procedure

1) Download the Eddie tar ball eddie-1.3.1.tar.gz from the Eddie web site www.eddieware.org.

2) Ensure erl and erlc are in your standard path.

3) Extract the Eddie files using "GNU tar."

tar zxf eddie-1.3.1.tar.gz | tar xf -

Note: If you don't have "GNU make", use the following command:

gzip -d -c eddie-1.3.1.tar.gz

4) Change directory using:

cd eddie-1.3.1

5) The following command must be run before compiling the source code:

./configure

This will prepare the scripts to install Eddie into the following directories:

/usr/local/sbin/eddie

/usr/local/sbin/lbdns

/usr/local/lib/eddie/*

To change the default installation directories (i.e, change /usr/local/ ) use the following command:

./configure --prefix=<install prefix>

6) Then compile Eddie using the following command:

Note: "GNU make" must be used. If "make" isn't GNU make then type the appropriate command to invoke GNU make. You must also edit the eddie.mk produced by configure so that the make variable equals "gmake" (or whatever GNU make is on your system).

make

7) Then install Eddie as superuser using the following command:

make install

This should build Eddie successfully. Getting Eddie running requires an understanding of how you want to configure your cluster(s). Please read the documentation in the doc/ subtrees.

8) To clean up after installation use the following command:

make clean

Now set up some links and directory permissions. Erlang 47.4.1 has a bug that requires the person running Eddie to be able to write to the directory from which they start Eddie, hence the change of ownership to eddie_operator . An example of how to do this if you are using Apache is shown below.

cd <install prefix>/lib/eddie

ln -s $APACHE_ROOT/modules

chown -R eddie_operator conf

cd conf

ln -s $APACHE_ROOT/conf/access.conf

ln -s $APACHE_ROOT/conf/srm.conf

ln -s $APACHE_ROOT/conf/magic

Note: We refer to the directory in which Apache is installed as the Apache root directory, $APACHE_ROOT .

Copy the installed files to all machines that you intend to run Eddie on, preserving all symbolic links and permissions. You can install Eddie in the same locations on each machine using "rsync." This assumes; however, that each machine is running the same operating system. Otherwise, repeat the installation procedure on each machine with a different OS and then copy to all similar machines.

 

2.1 Access Permissions

By default Eddie are installed in group `daemon' and are only executable by members of the security group. You may wish to create a new security group for those who can control Eddie. Eddie files in /usr/local/sbin/ and /usr/local/etc/ must have their permissions set appropriately.

 

3 Configuring the Gateway

The Intelligent HTTP Gateway application runs on Front End computers and provides

Note that while we use the terminology "Front End" and "Back End" computers, it is possible to run both the Intelligent HTTP Gateway application and a web server on the same computer. However, running the application and web server in this way limits Eddie's effectiveness in providing admission control while maintaining throughput.

Three configuration files are required which we term:

The .conf , .mig and .gate configuration files are stored in /etc/eddie/.

 

3.1 Eddie Configuration File

The configuration file is used to control a number of different Eddie parameters:

 

 
###################################
#
# Basic Eddie Configuration
#
# Nodes/clusters should be configured in the eddie.mig file
# Gateway/admission control should be configured in the eddie.gate file

#
# Cookie to use within the cluster
# Note: two clusters on the same machine(s) using the same 
#  cookie will create serious problems!
#
###################################
#
#
Cookie=testsuite2
#
# Specify where the Mnesia database should be located
#
MnesiaDirectory=/usr/tmp

####################################
#
# Specify the path of callback modules to be used by eddie
#

CallBackDirectory=/usr/local/lib/eddie/conf


####################################
#
# Run in Enhanced DNS mode only?
#
DNSonly=false

####################################
#
# The location of the Clustering information
#

ClusterConfig=/etc/eddie/eddie.mig

####################################
#
# The location of the Gateway information
#

GatewayConfig=/etc/eddie/eddie.gate

 

3.2 Gateway Configuration File

Eddie consists of two major applications:

We now describe the Intelligent HTTP Gateway configuration files.

The Gateway application uses a configuration file of the form shown below. The file provides the application with information on the following:

By convention we use a .gate extension on Intelligent HTTP Gateway configuration files, but it is not necessary.

#---------------------------------------------------------------
# File : basic_gateway.gate
# Purpose : A configuration file for the Intelligent HTTP Gateway
# (inet server) application.
#
# Syntax : Most configuration directives are on the form Key
# Value(s).
# Some directives are context based though. That is, their
# respective contexts start with
# <Frontend ...> or <Backend ...>
# and end with </Frontend> or </Backend>,
# and the configuration done inside of the
# context defines that Frontend or Backend.
#----------------------------------------------------------
#
#
# This file will be read by each Frontend to find out which
# URIs run on each Backend, whether or not admission control should
# be employed and what default admission control resources
# are available (e.g. number of sessions that can be queued during
# overload).

<Frontend http>

# Protocol Module is the module that implements the protocol
# specific parts of the server, in this case, http.

ProtocolModule http

# Port Options
# EndpointConfig is used to configure sockets.
# Mainly it is used to change which port the inet server uses, but
# it is also possible to change socket options.
# The syntax is
# EndpointConfig Endpointname UsePort | default *(Sock_opt
# Sock_value)
# For example, the endpointname for http is http_tcp
# EndpointConfig http_tcp default
# EndpointConfig http_tcp 8888 nodelay false
# EndpointConfig http_tcp 8000
# ReadTimeout and KeepAliveTimeout are specified in seconds and
# refer to the corresponding HTTP 1.1 parameters.

<EndpointConfig http_tcp>
Port 80
ReadTimeout 480
KeepAliveTimeout 20
ExternalProxy /usr/local/lib/eddie/bin/relay @control_port @ip @port
</EndpointConfig>

# Admission control.
# Admission control is used to limit the number of new clients
# in times of overload. It does so by keeping track of the IP
# addresses of the clients.
# Clients may either be queued for later admission or rejected
# by the server (see AdmitAlways, AdmitNever, AdmitQueuePlaces,
# AdmitMaxSessions below).
#
# AdmitControl is used to turn Admission Control On or Off.
# AdmitControl true | false
AdmitControl true

# If a client has been granted
# access to the server, it is regranted access until it does not
# arrive again within a specified period of time, AdmitTime.
# We recommend a default of 600 seconds to allow users to read and
# think between downloading pages. This of course may be varied
# according to local requirements
# AdmitTime Time
AdmitTime 600

# We can allow specific IP addresses to bypass admission control.
# This provides a crude form of differentiated quality of service.
# For example, those that pay always get access. Those that do not
# may be rejected during periods of high load.
# It is possible to specify A, B and C classes nets (e.g. 150.*.*.*,
# 150.236.*.* and 150.236.20.*). Multiple IP Addresses may be
# specified.
# AdmitAlways IPAddress
AdmitAlways 150.236.14.*

# These IP addresses are never admitted. This may be used to keep
# banned users away from the server.
# It is possible to specify A, B and C classes nets (e.g. 150.*.*.*,
# 150.236.*.* and 150.236.20.*).
# AdmitNever (IpAddress)
AdmitNever 150.236.20.*

# During periods of congestion, there is a limit placed on the
# number of clients that may be queued for later admission.
# AdmitQueuePlaces N
AdmitQueuePlaces 1000

# There is a general limit on the total number of active sessions
# that can be simultaneously serviced
# AdmitMaxSessions N
AdmitMaxSessions 100

# This page is sent to the client if it is blocked
# by the `AdmitNever' configuration directive.
# AdmitBlockedPage URI
AdmitBlockedPage /eddie_admit_blocked

# This page is sent to the client if it is rejected due to overload.
# AdmitRejectPage URI
AdmitRejectPage /eddie_admit_reject

# This page is sent to the client if it is placed in
# queue. It is assumed to be a CGI-script and is invoked as
# `URI?place=N&estimate=S&reload=T'.
# AdmitQueuePage URI
AdmitQueuePage /eddie_admit_queue

# Backend definitions.
# The <Backend Endpointname Backendhost> directive configures a
# backend host to handle an endpoints jobs.
# `Backendhost' refers to the host where the backend runs
# (i.e. where Apache runs).
#
# The http protocol module has only one endpoint, http_tcp.
# Thus all backend definitions for the http protocol
# start with <Backend http_tcp ....>
#
# The SchedulePattern directive allows configuration of which
# incoming URIs can be sent to which backend.
# All URIs that start with one of the specified Schedulepatterns
# may be scheduled to that particular backend.
#
# URIs starting with particular patterns may also be excluded from
# being sent to particular backends. A schedule line that starts
# with a ^ excludes all request lines matching the rest of the line.
#
# If there are many backends that match the
# request line, the request is scheduled to one of the backends
# according to the load balancing parameters effective at the time.
# Multiple Patterns may be defined within a single Schedule.
# In these cases, all must be matched simultaneously.
#
# The Proxy Ip Port configuration directive specifies the
# IP address and port on which the backend is accepting connections.

<Erlets admit_control>
<Erlet erlet_admit_ctrl>
</Erlet>
</Erlets>

<Erlets status>
<Erlet erlet_status>
</Erlet>
</Erlets>

# We now tell the front end nodes about the capabilities of the
# back end nodes. One block is required for each back end node.
# Each erlang node running on the same computer requires a unique
# name. For example, a set of three nodes with the names
# eddie01@europa, eddie02@europa and eddie01@eva is OK.

# IMPORTANT NOTE: ALL NODE NAMES MUST START WITH LOWER CASE LETTERS
# e.g. eddie01@eva is OK
# but Eddie01@eva is NOT OK.
# This has to do with the way Erlang interprets various things.
# Don't ask: just follow the instructions!

# The backend erlang node eddie01 on computer europa uses IP address
# 10.0.0.162, and Port 8001 for HTTP requests.
# It can answer all URIs except those that begin with /eddie
# It can answer requests for HTTP/1.0 but not HTTP/1.1
# It can answer requests for www.eddieware.org but not www.eddieware.org
# IMPORTANT NOTE: In Eddie, all pattern matchings are case sensitive.
# Also, the admission control relies on the ^/eddie URI, so do not remove it.
<Backend http_tcp eddie01@europa>
<Schedule>
Patterns uri / ^/eddie
Patterns method HTTP/1.0 ^HTTP/1.1
Patterns host www.eddieware.org ^www.eddieware.org
Proxy 10.0.0.162 8001
</Schedule>

# The backend erlang node eddie01 on computer eva uses IP address
# 10.0.0.163, and Port 8001 for HTTP requests.
# It can answer all URIs except those that begin with /load
<Backend http_tcp eddie01@eva>
<Schedule>
Patterns uri / ^/load
Proxy 10.0.0.163 8001
</Schedule>

<Schedule>
Patterns uri /eddie_status
Erlets status
</Schedule>

<Schedule>
Patterns uri /eddie_admit
Erlets admit_control
</Schedule>
</Backend>
</Frontend>

#----------------------------------------------------------------

3.3 The IP Migration Configuration File

The IP Migration configuration file contains information on:

By convention we use a .mig extension on the IP migration configuration file.

#---------------------------------------------------------------
# File : basic_migration.mig
# Purpose : A configuration file for the IP address migration and
# load balancing applications.
#
# Syntax : Most configuration directives are on the form Key
# Value(s).
# Some directives are context based though. That is, their
# respective contexts start with
# <Server ...> or <Cluster ...>
# and end with </Server> or </Cluster>,
# and the configuration done inside of the
# context defines that Server or Cluster.
#----------------------------------------------------------

# Declare the available DNS Servers and the port they are using.
# The Front Ends must be configured with the address of the Eddie DNS
# if DNS Load Balancing is to be used, as the gateways provide load info.
# to the DNS.
DNSServer eddieware.org 4567

# Define each erlang node on each computer.
# Each node on a computer must have a unique name.
# <Node nodename@computer>

# Define the interface used by the node
# Interfaces eth0

# Define the load threshold used in the admission control and
# load balancing algorithms
# LoadThreshold X Y
# Note that X is no longer used. Y defines the loading returned
# by uptime at which load balancing and control begins to take
# place.
# We recommend Y values in the range 2 to 4.
<Node eddie01@evita>
Interfaces eth0
LoadThreshold 0.8 3.0
</Node>

<Node eddie01@erika>
Interfaces eth0
LoadThreshold 0.8 3.0
</Node>

<Node eddie01@europa>
Interfaces eth0
LoadThreshold 0.8 3.0
</Node>

<Node eddie01@eva>
Interfaces eth0
LoadThreshold 0.8 3.0
</Node>

# The netmask defines which machines are allowed to communicate
# with each other inside the LAN.
Netmask 255.255.255.0

# Now define the clusters within the distributed web server
# Clusters consist of nodes that can cover for each other in the
# event of failure.
# There are two types of cluster: Frontend | Backend
# A Frontend cluster directs / controls traffic to one or more
# Backend clusters. The cluster names need to be unique, but do not
# need to be in the DNS Server. They are used for matching purposes
# in various places.

# Front ends in a Frontend Cluster run the actual Intelligent HTTP
# Gateway application. They also perform IP address migration in
# the event of failure of another member of the Cluster. The nodes
# that can take over from each other is defined by the FailoverNodes
# key.

# To do IP address migration, a pool of alias IP addreses is
# required. One alias IP address is given to each Front End.
# It is MANDATORY to use aliases for Front Ends. The AutonConfig On
# Key insures that the aliasing is automatically taken care of.

# The Interface and the Port for each node are also defined here.
# The Port is that used by HTTP request from the outside world.

<Cluster www0101.eddieware.org>
ClusterType Frontend

FailoverNodes eddie01@erika eddie01@evita
BackendClusters backend0101.eddieware.org

<Server eddie01@erika>
AutoConfig On
Interface eth0
IPAddress 10.0.0.181
Port 80
Start generic module eddie start @IPAddress @Port http
Stop generic module eddie stop @IPAddress @Port http
</Server>

<Server eddie01@evita>
AutoConfig On
Interface eth0
IPAddress 10.0.0.182
Port 80
Start generic module eddie start @IPAddress @Port http
Stop generic module eddie stop @IPAddress @Port http
</Server>
</Cluster>

# We now define the backend clusters. The real IP addresses are used
# for backends because address migration is not employed. In the
# event of failures, traffic is routed away from the failed node.
# Hence AutoConfig is off.
# We define the Port that will be used on the backend to access
# httpd.
# If Eddie is supposed to start and stop the HTTP daemons, we also
# provide information on where to find the start and stop shell
# scripts. We also define the location of httpd and the directory
# containing the HTTP configuration files appropriate to our
# system.
# If the httpd does not have to be started and stopped by Eddie,
# then the Start and Stop lines may be left out.

<Cluster backend0101.eddieware.org>
ClusterType Backend

<Server eddie01@eva>
AutoConfig Off
IPAddress 10.0.0.163
Port 8001
# Following two lines should be on one line
Start generic exec /usr/local/lib/eddie/bin/start_httpd
@IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

# Following two lines should be on one line
Stop generic exec /usr/local/lib/eddie/bin/stop_httpd
@IPAddress @Port

<Server eddie01@europa>
AutoConfig Off
IPAddress 10.0.0.162
Port 8001
# Following two lines should be on one line
Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress
@Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

</Server>

</Cluster>

4 Configuration Examples

Attached are .gate and .mig files for four examples of configuring Eddie for simple systems. These examples may also be found in the Eddie distribution in the eddie/conf directory. The machine names and IP addresses refer to those shown in Figure 1.

We assume that

These allow Eddie to start and stop the Apache servers.

Example 1: A one computer system

In this configuration, the computer Europa runs a Front End node and a Back End node.

Example 2: A two computer system

In this configuration, the computer Europa runs a Front End node while Eva runs a Back End node.

Example 3: A three computer system

In this configuration, the computer Europa runs a Front End node while Eva and Erika run Back End nodes.

Example 4: A four computer system

In this configuration, the computers Europa and Evita run Front End nodes while Eva and Erika run Back End nodes.

 

Figure 1. A single LAN distributed WWW server, showing connection to Internet, client computers, and LAN computers with IP addresses.

 

5 Starting the Gateway

There are a small number of commands that can be run from the command line to control the Eddie Intelligent HTTP Gateway. Before running the commands you should have the appropriate .mig and .gate configuration files saved in /usr/local/etc/. To edit the configuration files please refer to the Eddie Basic Configurations document.

The cookie referred to in the following commands is an arbitrary string that acts as a password; all commands must use the same cookie to verify their authenticity. The Mnesia directory is any arbitrary directory for the system's database to be written to. An empty directory in /tmp/ , for example, will suffice.

1. To start Eddie use:

 
eddie 

2. To start Eddie in verbose mode use:

 
eddie start -v

-v specifies verbose mode

3. To start a Windows NT node remotely:

As Windows NT doesn't support SSH/RSH, each node must be started individually on each machine within the cluster before running Eddie. This command starts a node without loading the configuration files.

eddie remote [node_name]

4. To stop all Eddie nodes use:

 
eddie stop

5. To stop a single Eddie node use:

 
eddie stop [node_name]

6. To add a node to the system:

Edit the configuration files to include another node, distribute them, and then restart Eddie using:

 
eddie

7. To delete a node from the system:

First, stop the node using

 
eddie stop [node_name]

Note: If no node is specified all nodes will be stopped. Next, edit the configuration files to remove the node from the configuration and distribute them.

8. To diagnose a node use:

 
eddie force -v [node_name]

This command will restart a single node on a local host in verbose mode.

9. To get status information on a node use:

 
eddie status [node_name]

 

6 References

  1. Providing Commercial Grade Web Servers: The imperatives and the solution.
  2. Eddie Enhanced DNS: Installation and Configuration Guide.

 

7 Configuration Files

This section conatins .gate and .mig files for the four examples.

 

7.1 Example 1 .gate
 
#----------------------------------------------------------------------
# File 		: ex1.gate
# Purpose : A single computer Eddie configuration.
#           One front end and one back end on the computer europa  
#----------------------------------------------------------------------

<Frontend http>

	ProtocolModule http

	<EndpointConfig http_tcp> 
		 Port 80	 		 
		ReadTimeout 480
		KeepAliveTimeout 20
		ExternalProxy /usr/local/lib/eddie/bin/relay @control_port @ip @port
	</EndpointConfig>

	AdmitControl true
	AdmitTime 600
	AdmitAlways 150.236.14.*
	AdmitNever 150.236.20.*
	AdmitQueuePlaces 1000
	AdmitMaxSessions 100
	AdmitBlockedPage /eddie_admit_blocked
	AdmitRejectPage /eddie_admit_reject
	AdmitQueuePage /eddie_admit_queue
	
	<Erlets admit_control>
		<Erlet erlet_admit_ctrl>
		</Erlet>
	</Erlets>

	<Erlets status>
		<Erlet erlet_status>
		</Erlet>
 	</Erlets>

	<Backend http_tcp eddieBE@europa>
		<Schedule>
			Patterns uri /
			Proxy 10.0.0.162 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>
</Frontend>

 

7.2 Example 1 .mig
 
#----------------------------------------------------------------------
# File		: ex1.mig
# Purpose : A single computer Eddie configuration.
#           One front end and one back end on the computer europa
#----------------------------------------------------------------------

DNSServer eddieware.org 4567

<Node eddieFE@europa>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

<Node eddieBE@europa>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

Netmask 255.255.255.255

<Cluster www0101.eddieware.org>
	ClusterType Frontend

	FailoverNodes eddieFE@europa
	BackendClusters backend0101.eddieware.org

	<Server eddieFE@europa>
		AutoConfig On
		Interface eth0
		IPAddress 10.0.0.164
		Port 80
		Start generic module eddie start @IPAddress @Port http
		Stop generic module eddie stop @IPAddress @Port http
	</Server>
</Cluster>

<Cluster backend0101.eddieware.org>
	ClusterType Backend

	<Server eddieBE@europa>
		AutoConfig Off
		IPAddress 10.0.0.162
		Port 8001

		Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>
</Cluster>

 

7.3 Example 2 .gate
 
#----------------------------------------------------------------------
# File    : ex2.gate
# Purpose : A configuration with one front end running on europa
#           and one back end running on eva.
#----------------------------------------------------------------------

<Frontend http>

	ProtocolModule http

	<EndpointConfig http_tcp> 
		Port 80
		ReadTimeout 480
		KeepAliveTimeout 20 
		ExternalProxy /usr/local/lib/eddie/bin/relay @control_port @ip @port
	</EndpointConfig>

	AdmitControl true
	AdmitTime 600
	AdmitAlways 150.236.14.*
	AdmitNever 150.236.20.*
	AdmitQueuePlaces 1000
	AdmitMaxSessions 100
	AdmitBlockedPage /eddie_admit_blocked
	AdmitRejectPage /eddie_admit_reject
	AdmitQueuePage /eddie_admit_queue

	<Erlets admit_control>
		<Erlet erlet_admit_ctrl>
		</Erlet>
	</Erlets>

	<Erlets status>
		<Erlet erlet_status>
		</Erlet>
	</Erlets>

	<Backend http_tcp eddieBE@eva>
		<Schedule>
			Patterns uri /
			Proxy 10.0.1.171 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>
</Frontend>

 

7.4 Example 2 .mig
 
#----------------------------------------------------------------------
# File    : ex2.mig
# Purpose : A configuration with one front end running on europa
#           and one back end running on eva.
#----------------------------------------------------------------------

DNSServer eddieware.org 4567

<Node eddieFE@europa>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

<Node eddieBE@eva>
	Interfaces eth0
	LoadThreshold 0.8 3.0
</Node>

Netmask 255.255.255.255

<Cluster www0101.eddieware.org>
	ClusterType Frontend

	FailoverNodes eddieFE@europa
	BackendClusters backend0101.eddieware.org

	<Server eddieFE@europa>
		AutoConfig On
		Interface eth0
		IPAddress 10.0.0.164
		Port 80
		Start generic module eddie start @IPAddress @Port http
		Stop generic module eddie stop @IPAddress @Port http
	</Server>
</Cluster>

<Cluster backend0101.eddieware.org>
	ClusterType Backend

	<Server eddieBE@eva>
		AutoConfig Off
		IPAddress 10.0.1.171
		Port 8001

		Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>
</Cluster>

 

7.5 Example 3 .gate
 
#----------------------------------------------------------------------
# File    : ex3.gate
# Purpose : A configuration with one front end running on europa,
#           one back end running on eva and one back end running on erika.
#----------------------------------------------------------------------

<Frontend http>

	ProtocolModule http

	<EndpointConfig http_tcp> 
		Port 80
		ReadTimeout 480
		KeepAliveTimeout 20 
		ExternalProxy /usr/local/lib/eddie/bin/relay @control_port @ip @port
	</EndpointConfig>

	AdmitControl true
	AdmitTime 600
	AdmitAlways 150.236.14.*
	AdmitNever 150.236.20.*
	AdmitQueuePlaces 1000
	AdmitMaxSessions 100
	AdmitBlockedPage /eddie_admit_blocked
	AdmitRejectPage /eddie_admit_reject
	AdmitQueuePage /eddie_admit_queue

	<Erlets admit_control>
		<Erlet erlet_admit_ctrl>
		</Erlet>
	</Erlets>

	<Erlets status>
		<Erlet erlet_status>
		</Erlet>
	</Erlets>

	<Backend http_tcp eddieBE@eva>
		<Schedule>
			Patterns uri /
			Proxy 10.0.1.171 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>

	<Backend http_tcp eddieBE@erika>
		<Schedule>
			Patterns uri /
			Proxy 10.0.1.170 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>
</Frontend>

 

7.6 Example 3 .mig
 
#----------------------------------------------------------------------
# File    : ex3.mig
# Purpose : A configuration with one front end running on europa,
#           one back end running on eva and one back end running on erika.
#----------------------------------------------------------------------

DNSServer eddieware.org 4567

<Node eddieFE@europa>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

<Node eddieBE@eva>
	Interfaces eth0
	LoadThreshold 0.8 3.0
</Node>

<Node eddieBE@erika>
	Interfaces eth0
	LoadThreshold 0.8 3.0
</Node>

Netmask 255.255.255.248

<Cluster www0101.eddieware.org>
	ClusterType Frontend

	FailoverNodes eddieFE@europa
	BackendClusters backend0101.eddieware.org

	<Server eddieFE@europa>
		AutoConfig On
		Interface eth0
		IPAddress 10.0.0.164
		Port 80
		Start generic module eddie start @IPAddress @Port http
		Stop generic module eddie stop @IPAddress @Port http
	</Server>
</Cluster>

<Cluster backend0101.eddieware.org>
	ClusterType Backend

	<Server eddieBE@eva>
		AutoConfig Off
		IPAddress 10.0.1.171
		Port 8001

		Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>

	<Server eddieBE@erika>
		AutoConfig Off
		IPAddress 10.0.1.170
		Port 8001

Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>
</Cluster>

 

7.7 Example 4 .gate
 
#----------------------------------------------------------------------
# File    : ex4.gate
# Purpose : A configuration file with one front end on europa,
#           one front end on evita, one back end on eva, and one
#           back end on erika.
#----------------------------------------------------------------------

<Frontend http>

	ProtocolModule http

	<EndpointConfig http_tcp> 
		Port 80
		ReadTimeout 480
		KeepAliveTimeout 20 
		ExternalProxy /usr/local/lib/eddie/bin/relay @control_port @ip @port
	</EndpointConfig>

	AdmitControl true
	AdmitTime 600
	AdmitAlways 150.236.14.*
	AdmitNever 150.236.20.*
	AdmitQueuePlaces 1000
	AdmitMaxSessions 100
	AdmitBlockedPage /eddie_admit_blocked
	AdmitRejectPage /eddie_admit_reject
	AdmitQueuePage /eddie_admit_queue

	<Erlets admit_control>
		<Erlet erlet_admit_ctrl>
		</Erlet>
	</Erlets>

	<Erlets status>
		<Erlet erlet_status>
		</Erlet>
	</Erlets>

	<Backend http_tcp eddieBE@eva>
		<Schedule>
			Patterns uri /
			Proxy 10.0.1.171 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>

	<Backend http_tcp eddieBE@erika>
		<Schedule>
			Patterns uri /
			Proxy 10.0.1.170 8001
		</Schedule>

		<Schedule>
			Patterns uri /eddie_status
			Erlets status
		</Schedule>

		<Schedule>
			Patterns uri /eddie_admit
			Erlets admit_control
		</Schedule>
	</Backend>
</Frontend>

 

7.8 Example 4 .mig
 
#----------------------------------------------------------------------
# File    		: ex4.mig
# Purpose : A configuration file with one front end on europa,
#           	one front end on evita, one back end on eva, and one
#           back end on erika.
#----------------------------------------------------------------------

DNSServer eddieware.org 4567

<Node eddieFE@europa>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

<Node eddieFE@evita>
	Interfaces eth0
	LoadThreshold 0.8 2.0
</Node>

<Node eddieBE@eva>
	Interfaces eth0
	LoadThreshold 0.8 3.0
</Node>

<Node eddieBE@erika>
	Interfaces eth0
	LoadThreshold 0.8 3.0
</Node>

Netmask 255.255.255.255

<Cluster www0101.eddieware.org>
	ClusterType Frontend

	FailoverNodes eddieFE@europa eddieFE@evita
	BackendClusters backend0101.eddieware.org

	<Server eddieFE@europa>
		AutoConfig On
		Interface eth0
		IPAddress 10.0.0.164
		Port 80
		Start generic module eddie start @IPAddress @Port http
		Stop generic module eddie stop @IPAddress @Port http
	</Server>

	<Server eddieFE@evita>
		AutoConfig On
		Interface eth0
		IPAddress 10.0.0.173
		Port 80
		Start generic module eddie start @IPAddress @Port http
		Stop generic module eddie stop @IPAddress @Port http
	</Server>
</Cluster>

<Cluster backend0101.eddieware.org>
	ClusterType Backend

	<Server eddieBE@eva>
		AutoConfig Off
		IPAddress 10.0.1.171
		Port 8001

		Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>

	<Server eddieBE@erika>
		AutoConfig Off
		IPAddress 10.0.1.170
		Port 8001

		Start generic exec /usr/local/lib/eddie/bin/start_httpd @IPAddress @Port /usr/sbin/httpd /usr/local/lib/eddie/conf/conf

		Stop generic exec /usr/local/lib/eddie/bin/stop_httpd @IPAddress @Port

	</Server>
</Cluster>