Anda di halaman 1dari 40

zenloadbalancer.org http://www.zenloadbalancer.org/web/index.php?

page=zen-load-balancer-administration-guide
Zen Load Balancer Administration Guide
Created on December 2011 - Documentation Version v01
Table of contents:
1. OVERVIEW
2. BASIC CONCEPTS
3. ZEN INSTALLATION
3.1 DOWNLOAD THE INSTALL ISO IMAGE
3.2 UPDATES
3.3 INSTALLATION PROCESS
4. ACCESS TO THE ZEN WEB ADMINISTRATION PANEL
5. ZEN WEB ADMINISTRATION PANEL SECTIONS
5.1 MANAGE::GLOBAL VIEW SECTION
5.2 MANAGE::FARMS SECTION
5.2.1 EDIT FARM GLOBAL PARAMETERS
5.2.1.1 TCP/UDP PROFILE OPTIONS
5.2.1.2 HTTP/HTTPS PROFILE OPTIONS
5.2.2 EDIT FARM REAL SERVERS
5.2.2.1 TCP/UDP PROFILE
5.2.2.2 HTTP/HTTPS PROFILE
5.2.3 VIEW STATUS FARM ACTION
5.3 MANAGE::CERTIFICATES SECTION
5.3.1 ADDING A NEW CERTIFICATE
5.4 MONITORING::GRAPHS SECTION
5.5 MONITORING::LOGS SECTION
5.6 SETTINGS::SERVER SECTION
5.7 SETTINGS::INTERFACES SECTION
5.8 SETTINGS::CLUSTER SECTION
5.9 SETTINGS::CHANGE PASSWORD SECTION
5.10 SETTINGS::BACKUP SECTION
6. FARM GUARDIAN USAGE
6.1 PHILOSOFY
6.2 CONFIGURATION
7. LICENSE
1. OVERVIEW
Zen Load Balancer is an Open Source Load Balancer Appliance Project that provides a f ull set of tools to
run and manage a complete load balancer solution which includes: f arm and server def inition, networking,
clustering, monitoring, secure certif icates management, logs, conf ig backups, etc.
2. BASIC CONCEPTS
Farm is a set of servers that of f er the same service over a single one entry point def ined with an IP
address and a port, which is commonly called virtual service. The main f arm work is to deliver the client
virtual service connection to the real backend service and back. Meanwhile, the f arm def inition establishes
the delivery policies to every real server.
Backend is a server that of f ers the real service over a f arm def inition and it process all the real data
requested by the client.
Client is called to the IP address that connects to the virtual service of the initial connection that usually a
user requests. The client IP address that opens a new connection on the virtual service side is used to
communicate with the user. The same client could generate several (layer 4) connections to the virtual
service, and an IP client address could be generated by several users.
Application Session is a layer 7 concept which tries to identif y the requests of a single user although
several clients shares the same IP client address.
Real IP is a physical IP address over a layer 4 network conf iguration which is assigned to a server or NIC.
Virtual IP is a f loating IP address over a layer 4 network conf iguration which is used to be the entry point of
a virtual service def ined by a f arm that is ready to deliver connections between redundant load balancing
nodes.
3. ZEN INSTALLATION
3.1 DOWNLOAD THE INSTALL ISO IMAGE
The load balance appliance installer is able to be downloaded f rom the of f icial website that could be used
to:
Burn an installer CD-ROM to install under a physical machine
Record on an USB device to install on a physical machine with usb boot support
Install on a virtual machine through a virtualization sof tware
Usually you'll be able to download the latest stable version or the latest release candidate testing version,
depending of your f eature needs. They'll be available f rom the download section of
http://www.zenloadbalancer.com.
3.2 UPDATES
Zen Load Balancer is under continuous development with new f eatures, improves and bug f ixes, so there is
a very easy way to upgrade your ZenLB to a newer version through a simple procedure.
To maintain updated your ZenLB installation, be sure you've the f ollowing line into the /etc/apt/sources.list
conf ig f ile:
For v1 version: deb http://zenloadbalancer.sourceforge.net/apt/x86 v1/
For v2 version: deb http://zenloadbalancer.sourceforge.net/apt/x86 v2/
Then update the apt database with the root user:
Check the last version on our of f icial repository:
And compare it with your ZenLB installed version:
If the last of f icial version is greater than your installation, you'll be able to upgrade your ZenLB through the
command below:
If would be necessary you can f orce the reinstallation through the f ollowing command:
The process will ask you "install the package without verification", select [y].
Then the process will ask if you want to rewrite the global.conf f ile, you've to select the def ault value [N].
Finally it's recommended to restart Zen Load Balancer service at your convenience.
To upgrade f rom v1 to v2 you've to f ollow all these explained steps and additionally you've to delete the
RRD databases of monitoring to be automatically regenerated with the new structure.
rm -rf /usr/local/zenloadbalancer/app/zenrrd/rrd/*
3.3 INSTALLATION PROCESS
Conf igure your physical or virtual x86 machine to boot f rom your iso/cd/usb Zen Load Balancer installer.
Then a splash is going to be loaded to start the install process.
Select "Install" option and continue.
Zen Load Balancer is distributed under a standard ISO f ormat built on top of the common GNU/Debian
Linux stable distribution. If you're f amiliar with this distribution then you should have no problems installing
ZenLB. Select your language, location and keyboard map.
Later the installer is going to detect the hardware components and load additional sof tware components.
Just wait a f ew seconds. Now the installation process will conf igure the network interf ace, you must set up
a static IP address that it's going to be used in the startup to access to the Zen web administration panel.
Other conf ig data like netmask, gateway and dns will be requested.
Set up a hostname f or the load balancer.
Set up the domain name f or your organization.
Introduce the root system password and repeat to validate. This password will be used when you access
over a console or ssh to the Zen Load Balancer system.
Set your timezone, once Zen LB is installed the local time will be syncronized every hour with ntp.pool.org
servers.
Conf igure your partition disk, if you haven't experience with Linux environment you can select Guide use
entire disk and automatically the system will be installed with a conf iguration by def ault. Experimented
users could select their custom installation. It would be interesting to know that a special disk space is not
needed to work with Zen Load Balancer, although minimal recommended is 1 GB of f ree space f or the
whole operating system. On this example we select the option by def ault.
If you've got more than one disk on your machine, you can select one of them here to be installed.
The partition table can be modif ied through the f ollowing menu.
Finish and continue.
Select Yes to apply the changes and continue.
Now you've to wait some seconds while the system is installed on your disk with your custom
conf iguration.
Now you've your brand new ZenLB installation and f inally it's necessary to restart the system.
On the boot process is shown your management IP address conf igured and the system started.
Remember that the conf igured root password on the installation process would be needed to enter to the
system on the server via ssh or console.
4. ACCESS TO THE ZEN WEB ADMINISTRATION PANEL
Once the Zen Load Balancer distro is installed into your server, you've to access through the secure URL
shown below:
https://<zenlb_ip_address>:444
The f irst time you enter to the administration panel, you've to accept the secure certif icate of ZenLB and
then a login window will appear.
The def ault credentials to get into the Zen web administration panel are the f ollowing:
User name: admin
Password: admin
These credentials could be changed through the Settings::Change Password section.
5. ZEN WEB ADMINISTRATION PANEL SECTIONS
The menu bar is distributed by the sections of Manage, Monitoring, Settings and About.
5.1 MANAGE::GLOBAL VIEW SECTION
The Global View section is used to know the actual instant state of the system, like a photo system status.
Under this section you'll be able to analyse the f arms state, memory, cpu consumption, established
connections and the % of established connections f rom the total system connections consumed by every
f arm.
The Global Farms Inf ormation table summarizes the f arm status you'll be able to control the f arms status
with a simple view, which of them are on UP status, how many resources are using and which is on DOWN
status.
With this table you can analyse:
o The % of cpu usage by the f arms
o The % of memory usage by the f arms
o The number of "Total connections on system" shows the concurrent connections that is used by the f arm
compared with the total connections established on the system.
The Memory table shows the global memory status measured in Megabytes.
MemTotal: It's the total ram memory on the system.
MemFree: It's the total f ree memory not cached by the system.
MemUsed: It's the memory used by the system.
Buffers: It's the memory used by the buf f ers.
Cached: It's the total memory cached by the system.
SwapTotal: It's the total swap memory reserved.
SwapFree: It's the total f ree memory not used by swap, on optimal systems it should be the same that
SwapTotal.
SwapUsed: It's the swap used memory by the system, on optimal systems should be 0.
The Load table shows the system load:
The Network Traf f ic Interf aces table shows the traf f ic used by the system since last time that it was
switched on:
5.2 MANAGE::FARMS SECTION
Under the Farms section you'll be able to access to the main conf iguration panel of virtual services.
Through the Add New Farm icon, you can def ine a new f arm with the next properties:
Farm Description Name: It's an identif ication f or the f arm and could be used to def ine a description of the
virtual service to be provided.
Profile: Def ine the level of the sNAT load balancing method. You could choose one of the next types:
TCP: It's a simple load balancing that deliver traf f ic in raw TCP data. The basic mechanism is about open 2
sockets f or every connection, one to the client and other to the real server, and then deliver the raw data
between them. The selection of this method could be adecuated f or protocols like SMTP, RDP, IMAP, LDAP,
SSH, etc.
UDP: It's a simple load balancing that deliver traf f ic in raw UDP data. The basic mechanism is about open 2
sockets f or every connection, one to the client and other to the real server, and then deliver the raw data
between them. The selection of this method could be adecuated f or protocols like DNS, NTP, TFTP,
BOOTP, SNMP, etc.
HTTP: It's an advanced only HTTP layer 7 load balancing (or Application Delivery Controller) with proxy
special properties. This method is adecuated f or web services (web application servers included) and all
application protocols based on HTTP protocol like WebDav, RDP over HTTP, ICA over HTTP, etc.
HTTPS: It's an advanced only HTTPS layer 7 load balancing (or Application Delivery Controller) combinated
with SSL wrapper acceleration. In this case, the communication between the client and the load balancer is
secure through HTTPS, meanwhile the communication between the load balancer and the real server is
clear through HTTP.
Virtual IP: The list shows all the IP addresses available in the system network conf iguration to be used to
conf igure a virtual service f or a f arm. This IP would be the bind address where the virtual service will be
listen on f or client requests. If the cluster service is enabled then the physical IP address of the cluster
nodes and the management web GUI IP address aren't listed.
Virtual Port: This f ield has to be a port number available on the system, where the virtual service will be
listen in.
It's not possible to def ine two f arms through the same virtual IP and port.
To f inalize the process adding a new f arm press the Save button.
Once the new f arm is created, it will be shown under the Farms Table with the basic data about the virtual
service: the virtual IP, the virtual Port, the f arm connections, PID, status, prof ile and actions.
The connections data is collected f rom the system netstat.
The Pending Conns are calculated with the SYN requests that are pending to be processed in the system
f or this f arm.
The Established Conns are calculated with the ESTABLISHED requests that are processing currently.
The Closed Conns are calculated with the CLOSE WAIT connections that have been processed in the
system.
The status f ield shows the state of the f arm system process with a green dot if the f arm is up and a red
dot if the f arm is down.
The actions available f or a running f arm are:
Stop Farm: The selected f arm will be stopped, and the virtual service will be disabled. Once the f arm
is stopped, it will not be started at the boot up process of the load balancer. The status f ield will be
shown with a red dot and the PID will be disappeared. A conf irmation window will be shown.
Edit Farm: You've to select this action to edit the f arm properties and the def inition of the real
servers f or the current f arm. The properties to be conf igured depends on the load balancing prof ile
selected f or the current virtual service.
Delete Farm: This action disables the current f arm and removes the virtual service. A conf irmation
window will be shown.
View Farm Status: This action shows a complete backend status, pending connections, established
connections and closed connections of every real server, the clients and the properties f or every
backend.
5.2.1 EDIT FARM GLOBAL PARAMETERS
In this panel you'll be able to set the parameters f or improving your f arms perf ormance and the basic
f unctionalities of your virtual service. The properties of the Edit Farm Action depends on the prof ile type
that we've selected while the f arm was created.
The common parameters f or all f arm prof iles are the f ollowing:
Farm's name. It's the identif ication f ield and a description f or the virtual service. To change this item you've
to modif y the name f ield and press the Modif y button. The load balancing service will be restarted
automatically af ter applying this operation. Be sure the new f arm name is available, if not, an error message
will appear.
Backend response timeout. It's the max seconds that the real server has to respond f or a request. If the
backend response is too late, then the server will be marked as blacklisted. The change of this parameter is
applied online f or TCP and UDP prof iles. To be applied f or HTTP and HTTPS, the f arm needs to be
restarted manually through the restart icon .
Frecuency to check resurrected backends. This value in seconds is the period to get out a
blacklisted real server and checks if is alive. Note that the backend will
not be in up status until the f irst successf ul connection is done. The
change of this parameter is applied online f or TCP and UDP prof iles.
To be applied f or HTTP and HTTPS, the f arm needs to be restarted
manually through the restart icon .
Farm Virtual IP and Virtual Port. These are the virtual IP address and virtual port in which the virtual
service f or the f arm will be bind and listening in the load
balancer system. To make changes in these f ields, be sure
the new virtual ip and virtual port are not in use. To apply the
changes the f arm service will be restarted automatically f or
TCP and UDP prof iles. To be applied f or HTTP and HTTPS, the f arm needs to be restarted manually
through the restart icon .
5.2.1.1 TCP/UDP PROFILE OPTIONS
The specif ic parameters f or a simple TCP or UDP f arm are the f ollowing:
Load Balance Algorithm. This f ield shows the dif f erent load balancing algorithms that are possible to be
conf igured f or the current f arm. Four algorithms are available. Selecting an unappropiate algorithm f or your
service inf rastructure could cause a lot of processor consumption over the load balancer. To apply the
changes check the Modif y Button and the new algorithm will be applied on line without restarting the f arm.
Here you've a brief explanation about the available algorithms f or TCP and UDP prof iles.
Round Robin equal sharing. An equal balance of traf f ic to all active real servers. For every incoming
connection the balancer assigns the next round robin real server to deliver the request.
Hash sticky client. The Farm will create a hash string f or each IP client and send each connection f rom that
hash to the same real server. A hash table is created with the real servers and the requests are assigned
through the f ollowing algorithm:
index = cli % nServers
Where index is the index of the real server hash table, cli is the integer representation of the IP address
and the nServers is the number of real servers available. This algorithm is a way to create persistence
through the IP address, but its more powerf ul if youve a variety of subnets clients accessing to your
service (f or example, an international service).
Weight connection linear dispatching by weight. Balance connections depending on the weight value, you
have to edit this value f or each real server. The requests are delivered through an algorithm to calculate the
load of every server using the actual connections to them, and then to apply a linear weight assignation.
Priority connections to the highest priority available. Balance all connections to the same highest priority
server. If this server is down, the connections switch to the next highest server. With this algorithm you can
build an Active-Pasive cluster service with several real servers.
Enable client ip address persistence through memory. For every algorithm a persistence by ip address
client could be conf igured. With this option enabled all the clients with the same ip address will be
connected to the same server. A new incoming connection is delivered to the selected server by the
algorithm and stored in the memory table. The next times the client will be connected is delivered to this
same server. This behaviour provides a basic persistency by ip address. To apply the changes you've to
press the Modif y Button and will be modif ied on line on the load balancer service. This option is not
available f or UDP f arms.
Max number of clients memorized in the farm.
This values have only sense if you enable the
client ip persistence. The client f ield is about the
max number of clients that will be possible to
memorize and the time value is the max time of
lif e f or this clients to be memorized (the max client age). To change these values you've to press the
Modif y Button and then the f arm service will be restarted automatically. This option is not available f or UDP
f arms.
Max number of simultaneous connections for the virtual IP. It's the max value of established
connections and active clients that the virtual service will be able to manage. For UDP f arms this value
indicates the max pending packets to be processed by the virtual service. To change this f ield the f arm will
be restarted automatically.
Max number of real ip servers. It's the max number of real servers that the f arm will be able to have
conf igured. To change this value the f arm service will be restarted automatically.
Add X-Forwarded-For header to http requests.
This option enables the HTTP header X-Forwarded-
For to provide to the real server the ip client address.
To change this f eature will be applied online. By
def ault is disabled. This option is not available f or
UDP f arms.
Use farmguardian to check backend servers.
Checking this box will enable a more advanced monitoring
state f or backends and totally personalized f or your our
scripts. When a problem is detected by f armguardian
automatically disables the real server and will be marked
as blacklisted. This is an independent service so you've not to restart the f arm service. To get more details
about this service, please read the FarmGuardian section. This option is not available f or UDP f arms.
5.2.1.2 HTTP/HTTPS PROFILE OPTIONS
The vast majority of parameters you'll be able to conf igure in a HTTP/HTTPS f arm, needs a manual restart
of the f arm service, so a TIP message will be appear to alert at the administrator that there are global
parameters or backend changes that needs to restart the service through the icon bef ore be applied.
The system administrator is able to modif y whatever parameters are needed and then restart the
f arm service to apply all them at the same time.
Note that in the HTTP/HTTPS f arms prof ile, the HTTP header X-Forwarded-For is included by def ault with
the IP client address data.
By contrast with the TCP or UDP f arms prof ile, the HTTP/HTTPS prof ile use a weight algorithm implicitly.
The specif ic parameters f or advanced HTTP or HTTPS f arm are the f ollowing:
Persistence session. This parameter def ines how the f arm service is going to manage the client session
and what HTTP connection f ield has to be controlled to maintain saf e client sessions. When a type of
persistence session is selected a persistence session TTL will appear.
No persistence. The f arm service won't control the
client sessions and the HTTP or HTTPS requests
will be f ree delivered to real servers.
IP client address. The IP client address will be
used to maintain the client sessions through the
real servers.
BASIC basic authentication. The HTTP basic
authentication header will be used to control the
client sessions. For example, when a web page
request a basic authentication to the client a HTTP header will contain a string like the f ollowing:
HTTP/1.1 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2011 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 31
Then the client answer with the header:
GET /private/index.html HTTP/1.1
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
This basic authentication string is used like an ID f or the session to identif y the client session.
URL a request parameter. When the session ID is sent through a GET parameter with the URL will be
possible to use this option indicating the parameter name associated with the client session ID. For
example, a client request like " http://www.example.com/index.php?sid=3a5ebc944f41daa6f849f730f1 " has
be conf igured as shown below:
To conf igure the URL session persistence, you've to select this option in the Persistence Session f ield and
then press the Modif y Button. Later, two new f ields will be shown:
Persistence session time to limit (TTL). This value indicates the max time of lif e f or an inactive client session
(max session age).
Persistence session identifier. This f ield is the URL parameter name that will be analyzed by the f arm service
and will manage the client session.
Af ter conf iguring this items and pressed the Modif y Button, it's needed to restart the f arm service to
apply the changes.
PARM a URI parameter. Another way to identif y a client session is done through a URI parameter. This is
a f ield separated by a semicolon like the f ollowing " http://www.example.com/private.php;EFD4Y7 "
To conf igure this kind of persistence is suf f icient to
select the PARM option and press the Modif y Button.
Finally, to apply the changes will be necessary to
restart the f arm service.
COOKIE a certain cookie. Also, you'll be able to select
a http cookie variable to maintain the client session
through the COOKIE option. A cookie has to be
created by the programmer into the webpage to identif y the client session, f or example:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: sessionidexample=75HRSd4356SDBfrte
With this specif ication, the f ollowing conf iguration will be needed:
Af ter conf iguring this items and pressed the Modif y Button on all of them, it's needed to restart the
f arm service to apply the changes.
HEADER a certain request header. A custom f ield of the HTTP header could be used to identif y the client
session. For example:
GET /index.html HTTP/1.1
Host: www.example.org
X-sess: 75HRSd4356SDBfrte
With this specif ication, the f ollowing conf iguration will be needed:
Af ter conf iguring this items and pressed the Modif y Button on all of them, it's needed to restart the f arm
service to apply the changes.
HTTP verbs accepted. This f ield indicates the operations that will be permitted to the HTTP client
requests. If a not permitted verb is requested an error will be shown to the client.
Standard HTTP request. Accept only standard HTTP
requests (GET, POST, HEAD).
+ extended HTTP request. Additionally allow extended
HTTP requests (PUT, DELETE).
+ standard WebDAV verbs. Additionally allow standard
WebDAV verbs (LOCK, UNLOCK, PROPFIND,
PROPPATCH, SEARCH, MKCOL, MOVE, COPY,
OPTIONS, TRACE, MKACTIVITY, CHECKOUT, MERGE,
REPORT).
+ MS extensions WebDAV verbs. Additionally allow MS extensions WebDAV verbs (SUBSCRIBE,
UNSUBSCRIBE, NOTIFY, BPROPFIND, BPROPPATCH, POLL, BMOVE, BCOPY, BDELETE, CONNECT).
+ MS RPC extensions verbs. Additionally allow MS RPC extensions verbs (RPC_IN_DATA, RPC_OUT_DATA).
To apply any of these options, press the Modif y Button and restart the f arm service.
HTTPS Certificate. The SSL certif icate is only available f or HTTPS f arms, where a list of certif icates will
be shown to be selected f or the current f arm. This list could be modif ied under the Manage::Certificates
section.
To apply this conf iguration press the Modif y Button
and restart the f arm service.
Personalized error messages. Through the
personalized error messages, the f arm service is able
to answer a custom message of your site when a web
code error is detected f rom the real servers. A personalized HTML page will be shown.
To apply the changes press the Modif y Button and restart the f arm service.
5.2.2 EDIT FARM REAL SERVERS
Once a new f arm is created, you've to include the servers with the real services to deliver the input
connections.
Under the Edit real IP servers table conf iguration you'll be able to include the conf iguration backends f or
every backend and their specif ic parameters.
The common properties to be entered f or a real backend are the f ollowing:
Server. It's an automatic ID established to be an index f or the real server. The system administrator can't
change this value.
Address. It's the IP address of the real service.
Port. It's the port of the real server in which the real service is listening on.
5.2.2.1 TCP/UDP PROFILE
With a TCP or UDP f arm, you'll be able to conf igure the f ollowing properties:
Max connections. It's the max number of concurrent connections that the current real server will be able to
receive. This value must be less than the Max clients of the Global Parameters.
Weight. It's the weight value f or the current real server which is only usef ul if the Weight Algorithm is
enabled. More weight value indicates more connections delivered to the current backend.
Priority. It's the priority value f or the current real server which is only usef ul if the Priority Algorithm is
enabled. The priority value accepted is between 1 and 9, less value indicates more priority to the current
real server.
With the Save Real Server button you'll apply the new conf iguration, or you'll be able to cancel the
process through the button. A message with the result will be displayed.
Once the real server conf iguration is entered, you'll be able to edit the conf ig throught the Edit
button or delete the conf iguration with the Delete Real Server button.
The server index is usef ul to identif y the real server conf iguration f or the current f arm.
The changes of the real servers conf iguration f or the TCP and UDP prof iles are applied online, and a
restart action isn't needed.
5.2.2.2 HTTP/HTTPS PROFILE
With a HTTP or HTTPS f arm, you'll be able to conf igure the f ollowing properties:
Timeout. It's the specif ic value of timeout f or a backend to response. This value override the global
timeout f arm parameter f or the current backend.
Weight. It's the weight value f or the current real server. By def ault a value of 5 is established.
With the Save Real Server button you'll apply the new conf iguration, or you'll be able to cancel the
process.
For the HTTP/HTTPS f arm prof ile a message with the result will be displayed and a restart action will
be requested to the administrator to the changes take ef f ect. To apply the new conf iguration you
have to restart the f arm through the restart button .
The TIP message will not disappear until the f arm is restarted.
Once the real server conf iguration is entered, you'll be able to edit the conf ig throught the Edit
button or delete the conf iguration with the Delete Real Server button.
The server index is usef ul to identif y the real server conf iguration f or the current f arm.
The changes of the real servers conf iguration f or the HTTP and HTTPS prof iles needs a manual f arm
restart.
5.2.3 VIEW STATUS FARM ACTION
This action shows the actual state of backends, clients and connections that are being delivered f rom the
virtual service to the real servers.
The Real Server Status table shows the state of every backend:
Server. It's the backend identif ication number.
Address. It's the real server IP address.
Port. It's the port number where the real service of the current real server is listening on.
Status. A red dot means that the current real server is down or blacklisted, meanwhile a green dot means
that the backend is online and delivering connections.
Pending Conns. This is the number of pending connections in the system that are on SYN state f or the
current backend, indepently of f arm service.
Established Conns. This is the number of established connections in the system that are on
ESTABLISHED state f or the current backend, indepently of f arm service.
Closed Conns. This is the number of closed connections in the system that are on TIME_WAIT state f or
the current backend, indepently of f arm service.
Clients. It's the number of clients (unique IP addresses) that are associated with the current backend
server. This is only available f or TCP f arms.
Sessions. It's the number of HTTP client sessions that are associated with the current backend server.
This is only available f or HTTP and HTTPS f arms.
Weight. It's the weight value established f or every backend.
Priority. It's the priority value established f or every backend server. This option is only available f or TCP
and UDP f arms.
To analyze with details the clients, sessions and connections to the backends, you've to expand the Client
sessions status or Active connections tables to show all this inf ormation pressing the Maximize button.
Note that f or very high load f arms showing this table could slowdown the machine and could be shown a
very large table.
5.3 MANAGE::CERTIFICATES SECTION
The Certif icates inventory table is used to manage the SSL certif icates to be used f or the HTTPS prof ile
f arms.
All the certif icates has to be generated a PEM f ile extension to be valid f or HTTPS f arms. By def ault a
zencert.pem certif icate is possible to be used and is not able to be deleted.
The uploaded certif icate f ile must contain a PEM-encoded certif icate, optionally a certif icate chain f rom a
known Certif icate Authority to your server certif icate and a PEM-encoded private key (not password
protected).
5.3.1 ADDING A NEW CERTIFICATE
To upload a custom certif icate it's necessary to press the button Upload Certif icate to be used f or
SSL wrapper.
A new window is shown to upload a custom certif icate through the Browse... button on your local
computer.
To upload the new certif icate f ile it's needed to press the Upload button. Automatically, the new f ile will be
accessible f or the balancer.
Then we're able to select the certif ied uploaded to be used f or the HTTPS f arms.
5.4 MONITORING::GRAPHS SECTION
This section is usef ul to monitorize the internal load
balancer system to detect problems through the
parameters of CPU usage, swap memory, ram memory,
all conf igured nework interf aces, load and hard disk
storage.
All the graphs that are shown in the f irst page are the daily progress value of every parameter. Also, you'll
be able to access to the weekly, mothly and yearly history through the button.
5.5 MONITORING::LOGS SECTION
This section is used to access to the system logs. To display the logs you've to select one of the log f iles
and then establish the number of tailed lines to be shown pressing the See logs button.
The f iles are associated to the f ollowing services:
ucarp.log. Log f ile f or cluster service.
zenlatency.log. Log f ile f or latency service launcher of ucarp service.
zeninotify.log. Log f ile f or conf ig replication service.
mini_https.log. Log f ile f or the web gui http service.
zenloadbalancer.log. Log f ile f or the global zen load balancer actions service through the web GUI.
farmguardian.log. Log f ile f or f armguardian advanced monitoring service.
5.6 SETTINGS::SERVER SECTION
This section provides some global parameters f or the load balancer server system.
The meaning of these parameters are the f ollowing:
Time out execution Zen GUI CGIs. The Zen GUI web administration panel has been implemented in perl
CGI, so this is the time limit to execute the cgi. If the page execution exceed this timeout, the process will
be killed.
NTP server. Time server to syncronize the date-time of the system.
Rsync replication parameters. These are the parameters to syncronize the conf ig data of the cluster
replication. Do not change this settings if you dont know what are you doing.
Physical interface where is running the GUI service. This is the interf ace where the web panel service
will be bind to. It's saf e to keep the All interfaces enabled. To apply the changes it's needed to restart the
GUI service.
DNS servers. This is the /etc/resolv.conf f ile content to apply the DNS servers f or the system.
APT repository. This is the /etc/apt/sources.list f ile content to apply the APT repositories f or the system.
These apt servers have to be appropiately updated when a system upgrading is needed.
5.7 SETTINGS::INTERFACES SECTION
This section is the main network conf iguration panel f or Zen Load Balancer, where will be shown the
network interf aces table f or physical, virtual and vlan interf aces, and the def ault gateway conf iguration
f ield.
At the Interf aces Table will appear all the physical network interf aces installed in the system af ter the
ZenLB installation. The meaning of every table f ields are the f ollowing:
Name. It's the name of the current interf ace and will be unique. The virtual interf aces will be identif icated by
a colon ":" character within the interf ace name, meanwhile the vlan is identif icated by a dot "." character
within the interf ace name which will be the vlan tag.
Addr. It's the IP address in ipv4 f ormat f or the current network interf ace.
HWAddr. It's the MAC physical address f or the current network interf ace. Note that the virtual and vlan
network interf aces have the same MAC address of its parent physical interf ace.
Netmask. It's the netmask of the network interf ace, which def ines the subnet of the network f or the
current interf ace.
Gateway. It's the gateway f or the current network interf ace. ZenLB could work with independent route
tables f or every physical or vlan network interf aces. Virtual interf aces always inherit the gateway f rom the
parent physical or vlan interf ace.
Status. A green dot means the interf ace is UP and running, meanwhile a red dot means an interf ace is
DOWN. Sometimes a disconnect icon will be shown when the interf ace is UP but it hasn't link.
Actions. The action icons are used to apply changes to the current network interf ace. Applying a certain
action could af f ect to one or more network interf aces.
Down interface. Disables the current interf ace.
Up interface. Enable the current interf ace.
Edit interface. Change the current network interf ace conf iguration.
To apply the changes press the Save & Up! Button.
Add virtual interface. Adds a new virtual interf ace inherited f rom the current network interf ace.
Creating a new virtual interf ace will appear a f ield with a colon ":" character that will be used to
establish an identif ication f or the virtual interf ace. The IP address has to be under the same subnet that
the parent interf ace.
To apply the changes you have to press the Save button. Press the Cancel button to reject the
changes.
Add vlan interface. Adds a new vlan interf ace inherited f rom the current network interf ace.
Creating a new vlan interf ace will appears a f ield with a dot "." character that will be used to establish
an identif ication f or the vlan interf ace. The IP address could be dif f erent of the parent interf ace.
To apply the changes you have to press the Save button. Press the Cancel button to reject the
changes.
Delete interface. This action disables and delete the current interf ace if it's possible.
Some actions are locked. This icon means that some actions are locked and disabled temporarily.
Some reasons to this behaviour are the f ollowing:
GUI service is bind to a certain interface. In this case, a home icon is shown and some actions are
disabled to be saf e f rom bad conf igurations that could produce an unaccessible zen web GUI.
To restablish the actions, you've to go to the Settings::Server section and bind the GUI service over all
interf aces, and f inally restart the GUI service.
Cluster configuration. In this case, the cluster has been conf igured and the interf aces conf iguration is only
enabled when the cluster is disabled.
Finally a def ault gateway f or the system could be established through the Def atul gateway table.
To change this f ield, you've to press the edit button and enter the gateway address and interf ace.
To apply the new conf iguration press the Save button or Cancel to reject the changes.
To remove the def ault gateway press the Delete Button.
5.8 SETTINGS::CLUSTER SECTION
On this section you can conf igure the cluster service and check the cluster service status. During the
cluster process conf iguration you don't have to access to the second node, as the conf iguration will
be replicated automatically.
Cluster status. It's a global view of cluster elements, you can reload the check here
Virtual IP for Cluster, or create new virtual here. Select a virtual ip that will be used f or the cluster
service, if you didn't conf igure one, please go to Settings::Interface and conf igure one, this virtual interf ace
is only needed to be conf igured on the f irst node that you are conf iguring the cluster service.
Local hostname and Remote Hostname. Once a virtual interf ace is selected the hostnames and IP
address inf ormation about the cluster nodes are needed.
Press the Save button to save the changes. At this point, it's needed that the physical IP f or both nodes
are conf igured over the same physical interf ace that the "virtual IP Cluster" on the last step (f or example,
eth0).
Remote Hostname root password. Enter the second node root password, this inf ormation won't be
memorized, it's only needed to conf igure the RSA comunication over the both nodes.
Once the Configure RSA Connection between nodes is pressed the communication process is executed and
if everything is right you'll see messages as shown below.
Pressing the Test RSA connection button will check that the RSA communication f rom the current node to
the remote node is working f ine.
A message like the f ollowing will appear if everything is right.
Select the cluster type. Through this combo you can choose the behaviour of the cluster service.
--Disable cluster on all hosts--:The cluster service will be stopped and disabled on both nodes. Only use this
option if you need to stop the cluster service to make changes or disable the cluster service.
node1 master and node2 backup automatic failback: If node1 is detected as down the node2 will take over
the load balancing service. When node1 is restored the service will automatically switch back to node1. You
should choose this option when node1 is a more powerf ul server than node2.
node1 or node2 can be masters: anyone can be master, there is no automatic f ailback when one node is
recovered. If you have two very similar servers f or node1 and node2 that can both handle the f ull load of
your traf f ic then you can use this option.
To connect two Zen Load Balancer servers over cross over cable f or cluster communication you have to
check this option:
Now press to save the changes.
The cluster service is going to start on both nodes and at the end of the
process these messages will appear.
Processes are going to be launched on background to conf igure the cluster, at this point you can press the
ref resh icon to update the cluster status view.
If the cluster is conf igured and working f ine you can see a similar view like this:
On this view will be shown the cluster services and the status that we describe on the next lines:
Zen latency. Is a launcher of UCARP service, this service has to be running on both cluster nodes, and
check that the communication between nodes is OK.
Cluster IP. This IP is UP only on the master node and conf igured but DOWN on the backup node.
Zen inotify. This service has to be running only on the master node and will send to the backup node all
the conf iguration and changes of networking and f arms.
Over the cluster conf igured view you can:
Reload the check for testing that the cluster service are working like a charm.
Force cluster sync from master to backup. This manual f orce is usef ul af ter a
cluster service recovery.
Test the RSA connection. Verif y that the RSA connection between nodes is
working f ine that it's needed f or syncronization over zen inotif y
service.
Force failover. Switch the cluster service node. It's usef ul if you
need to do some maintenance tasks on the master server or to test the cluster
service. For node1 master and node2 backup automatic failback cluster type will be
switched f or only 30 seconds, af ter that, the cluster service will be switched back
to node1.
Once the cluster service is conf igured you'll be able to change the cluster type but the
service could produce some outages.
Over the web GUI is easy to identif y which is the cluster role f or both nodes. On the
upper side of the webpage will show this message f or the master node:
And f or the backup node:
Once the cluster service is running on both nodes you only have to connect to
master node to apply changes f or f arms and interf aces, which will be
automatically conf igured and replicated to the backup node.
5.9 SETTINGS::CHANGE PASSWORD SECTION
In this section you'll be able to change the web admin user password.
It's necessary to insert the current password and a repeated new password. Pressing the Change button
will change the admin web password. Optionally you'll be able to sync the admin password with the root
system password through the Change & Sync with root password button.
5.10 SETTINGS::BACKUP SECTION
With the Backup option you can save the conf igurations on the ZenLB server and download to your local
computer.
On this panel you can create, restore, upload and download backup f iles.
The Description name f ield will be the identif ication f or the backup f ile to be generated pressing the Create
Backup button. Please, do not include blank spaces.
The new backup f ile generated will be listed on the Backup f iles table:
The actions to be applied are the f ollowing:
: Through this icon you can download the selected f ile.
: Through this icon you can delete the selected backup f ile.
: Through this icon you can apply this backup. The conf ig f iles will be rewritten if exists.
: Through this icon you can upload a backup f ile. It's usef ul if you've created a backup and
downloaded it f or security reasons. If you press this icon a window will be shown:
Pressing the Browse... button you'll be able to navigate through your local f iles to select your backup f ile to
be uploaded. It is important to know that the f ile need to f ollow the next pattern:
backup-description.tar.gz
If you modif y the pattern, then the f ile isn't going to be listed on the Settings::Backup section.
6. FARM GUARDIAN USAGE
6.1 PHILOSOPHY
By def ault Zen Load balancer checks the tcp backends port status, but sometimes this check its not
enough to conclude that the backend status is working f ine. To solve this problem Zen Load Balancer
implement a way to execute an advanced and personalized backends checks called Farm Guardian.
With this advanced monitoring application you can develope your own personalized scripts or use some
available scripts under the /usr/local/zenloadbalancer/app/libexec/ directory.
Farm Guardian checks the execution error output f rom the selected script ($? = 0 when there isn't error f or
the backend and $? <> 0 when there is an error f or the backend).
All scripts used by Farm Gardian have to accept two minimal input arguments, HOST and PORT
(HOST=backend ip, PORT= port backend).
Farm Guardian connects to your f arm and will list the backends and ports. Then the selected script will be
runned f or each server replacing the HOST and PORT token string by each backend and port conf igured on
your f arm.
6.2 CONFIGURATION
At the moment, Farm Guardian is only implemented f or TCP prof ile:
To enable the Farm Guardian monitoring check the box Use FarmGuardian to check Backend Servers and
establish the time period of checks:
Now select a def ault script under the path
/usr/local/zenloadbalancer/app/libexec or include
your own script on that directory:
Farm Guardian connects to the f arm to obtain the backend list and execute this script f or each of them.
Reading the output of the execution through the $? variable we could determine that if the web content on
a real server doesn't contain the string It works, the current backend will be marked as blacklisted.
It's recomended to read the help page of check_http script to understand this example.
You can activate the execution logs f or Farm Guardian checking the Active logs checkbox.
7. LICENSE
This documentation has been created by the Zen Load Balancer Developers Team f or
the Zen Load Balancer GNU/GPL Project.
This documentation is licensed under the terms of the GNU Free Documentation License.
This programm is licensed under the terms of the GNU General Public License.

Anda mungkin juga menyukai