ZEN LOAD BALANCER ADMINISTRATION

GUIDECreated on December 2011 - Documentation Version v01

Table of Contents

1 Overview2 Basic Concepts3 Zen Installation

3.1 Download the install ISO image3.2 Updates 3.3 Installation Process

4 Access to the Zen Web Administration Panel5 Zen Web Administration Panel Sections

5.1 Manage::Global View Section5.2 Manage::Farms Section Section

5.2.1 Edit Farm Global Parameters5.2.1.1 TCP/UDP Profile Options5.2.1.2 HTTP/HTTPS Profile Options

5.2.2 Edit Farm Real Servers5.2.2.1 TCP/UDP Profile5.2.2.2 HTTP/HTTPS Profile

5.2.3 View Status Farm Action5.3 Manage::Certificates Section

5.3.1 Adding a new Certificate5.4 Monitoring::Graphs Section5.5 Monitoring::Logs Section5.6 Settings::Server Section5.7 Settings::Interfaces Section5.8 Settings::Cluster Section5.9 Settings::Change Password Section5.10 Settings::Backup Section

6 Farm Guardian Usage6.1 Philosophy6.2 Configuration

7 License

1 Overview

Zen Load Balancer is an Open Source Load Balancer Appliance Project that provides a full set of tools to run and manage a complete load balancer solution which includes: farm and server definition, networking, clustering, monitoring, secure certificates management, logs, config backups, etc.

2 Basic Concepts

Farm is a set of servers that offer the same service over a single one entry point defined with an IP address and a port, which is commonly called virtual service. The main farm work is to deliver the client virtual service connection to the real backend service and back. Meanwhile, the farm definition establishes the delivery policies to every real server.

Backend is a server that offers the real service over a farm definition 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 identify 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 configuration which is assigned to a server or NIC.

Virtual IP is a floating IP address over a layer 4 network configuration which is used to be the entry point of a virtual service defined by a farm 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 from the official 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 software

Usually you'll be able to download the latest stable version or the latest release candidate testing version, depending of your feature needs. They'll be avaliable from the download section of http://www.zenloadbalancer.com.

3.2 Updates

Zen Load Balancer is under continuous development with new features, improves and bug fixes, 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 following line into the /etc/apt/sources.list config file:

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 official repository:

And compare it with your ZenLB installed version:

If the last official version is greater than your installation, you'll be able to upgrade your ZenLB through the command below:

If would be necessary you can force the reinstallation through the following 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 file, you've to select the default value [N].

Finally it's recommended to restart Zen Load Balancer service at your convenience.

To upgrade from v1 to v2 you've to follow 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

Configure your physical or virtual x86 machine to boot from 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 format built on top of the common GNU/Debian Linux stable distribution. If you're familiar 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 software components. Just wait a few seconds.

Now the installation process will configure the network interface, 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 config data like netmask, gateway and dns will be requested.

Set up a hostname for the load balancer.

Set up the domain name for 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.

Configure 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 configuration by default. 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 free space for the whole operating system. On this example we select the option by default.

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 modified through the following 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 configuration.

Now you've your brand new ZenLB installation and finally it's necessary to restart the system.

On the boot process is shown your management IP address configured and the system started.

Remember the configured 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://:444

The first time you enter to the administration panel, you've to accept the secure certificate of ZenLB and then a login window will appear.

The default credentials to get into the Zen web administration panel are the following:

User name: adminPassword: 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 farms state, memory, cpu consumption, established connections and the % of established connections from the total system connections consumed by every farm.

The Global Farms Information table summarizes the farm status you'll be able to control the farms 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:

The % of cpu usage by the farms

The % of memory usage by the farms

The number of "Total connections on system" shows the concurrent connections that is used by the farm 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 free memory not cached by the system.

MemUsed: It's the memory used by the system.

Buffers: It's the memory used by the buffers.

Cached: It's the total memory cached by the system.

SwapTotal: It's the total swap memory reserved.

SwapFree: It's the total free 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 Traffic Interfaces table shows the traffic 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 configuration panel of virtual services.

Through the Add New Farm icon, you can define a new farm with the next properties:

Farm Description Name: It's an identification for the farm and could be used to define a description of the virtual service to be provided.

Profile: Define 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 traffic in raw TCP data. The basic mechanism is about open 2 sockets for 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 for protocols like SMTP, RDP, IMAP, LDAP, SSH, etc.

UDP: It's a simple load balancing that deliver traffic in raw UDP data. The basic mechanism is about open 2 sockets for 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 for 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 for 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 avaliable in the system network configuration to be used to configure a virtual service for a farm. This IP would be the bind address where the virtual service will be listen on for 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 field has to be a port number avaliable on the system, where the virtual service will be listen in.

It's not possible to define two farms through the same virtual IP and port.

To finalize the process adding a new farm press the Save button.

Once the new farm 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 farm connections, PID, status, profile and actions.

The connections data is collected from the system netstat.

The Pending Conns are calculated with the SYN requests that are pending to be processed in the system for this farm.

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 field shows the state of the farm system process with a green dot if the farm is up and a red dot if the farm is down.

The actions avaliable for a running farm are:

Stop Farm: The selected farm will be stopped, and the virtual service will be disabled. Once the

farm is stopped, it will not be started at the boot up process of the load balancer. The status field will be shown with a red dot and the PID will be disappeared. A confirmation window will be shown.

Edit Farm: You've to select this action to edit the farm properties and the definition of the real servers for the current farm. The properties to be configured depends on the load balancing

profile selected for the current virtual service.

Delete Farm: This action disables the current farm and removes the virtual service. A confirmation 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

for every backend.

5.2.1 Edit Farm Global Parameters

In this panel you'll be able to set the parameters for improving your farms performance and the basic functionalities of your virtual service. The properties of the Edit Farm Action depends on the profile type that we've selected while the farm was created.

The common parameters for all farm profiles are the following:

Farm's name. It's the identification field and a description for the virtual service. To change this item you've to modify the name field and press the Modify button. The load balancing service will be restarted automatically after applying this operation. Be sure the new farm name is avaliable, if not, an error message will appear.

Backend response timeout. It's the max seconds that the real server has to respond for 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 for TCP and UDP profiles. To be applied for HTTP and HTTPS, the farm 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 first successful connection is done. The change of this parameter is applied online for TCP and UDP profiles. To be applied for HTTP and HTTPS, the farm 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 for the farm will be bind and listening in the load balancer system. To make changes in these fields, be sure the new virtual ip and virtual port are not in use. To apply the changes the farm service will be restarted automatically for TCP and UDP profiles. To be applied for HTTP and HTTPS, the farm needs to be restarted manually through the restart icon .

5.2.1.1 TCP/UDP Profile Options

The specific parameters for a simple TCP or UDP farm are the following:

Load Balance Algorithm. This field shows the different load balancing algorithms that are possible to be configured for the current farm. Four algorithms are avaliable. Selecting an unappropiate algorithm for your service infrastructure could cause a lot of processor consumption over the load balancer. To apply the changes check the Modify Button and the new algorithm will be applied on line without restarting the farm.

Here you've a brief explanation about the avaliable algorithms for TCP and UDP profiles.

Round Robin equal sharing. An equal balance of traffic 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 for each IP client and send each connection from that hash to the same real server. A hash table is created with the real servers and the requests are assigned through the following 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 powerful if youve a variety of subnets clients accessing to your service (for example, an international service).

Weight connection linear dispatching by weight. Balance connections depending on the weight value, you have to edit this value for 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 avaliable. 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 configured. 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 Modify Button and will be modified on line on the load balancer service. This option is not avaliable for UDP farms.

Max number of clients memorized in the farm. This values have only sense if you enable the client ip persistence. The client field is about the max number of clients that will be possible to memorize and the time value is the max time of life for this clients to be memorized (the max client age). To change these values you've to press the Modify Button and then the farm service will be restarted automatically. This option is not avaliable for UDP farms.

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 farms this value indicates the max pending packets to be processed by the virtual service. To change this field the farm will be restarted automatically.

Max number of real ip servers. It's the max number of real servers that the farm will be able to have configured. To change this value the farm 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 feature will be applied online. By default is disabled. This option is not avaliable for UDP farms.

Use farmguardian to check backend servers. Checking this box will enable a more advanced monitoring state for backends and totally personalized for your our scripts. When a problem is detected by farmguardian automatically disables the real server and will be marked as blacklisted. This is an independent service so you've not to restart the farm service. To get more details about this service, please read the FarmGuardian section. This option is not avaliable for UDP farms.

5.2.1.2 HTTP/HTTPS Profile Options

The vast majority of parameters you'll be able to configure in a HTTP/HTTPS farm, needs a manual restart of the farm 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 before be applied. The system administrator is able to modify whatever parameters are needed and then restart the farm service to apply all them at the same time.

Note that in the HTTP/HTTPS farms profile, the HTTP header X-Forwarded-For is included by default with the IP client address data.

By contrast with the TCP or UDP farms profile, the HTTP/HTTPS profile use a weight algorithm implicitly.

The specific parameters for advanced HTTP or HTTPS farm are the following:

Persistence session. This parameter defines how the farm service is going to manage the client session and what HTTP connection field has to be controlled to maintain safe client sessions. When a type of persistence session is selected a persistence session TTL will appear.

No persistence. The farm service won't control the client sessions and the HTTP or HTTPS requests will be free 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 following:

Then the client answer with the header:

This basic authentication string is used like an ID for the session to identify 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 configured as shown below:

To configure the URL session persistence, you've to select this option in the Persistence Session

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

GET /private/index.html HTTP/1.1

Host: localhost

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

field and then press the Modify Button. Later, two new fields will be shown:

Persistence session time to limit (TTL). This value indicates the max time of life for an inactive client session (max session age).

Persistence session identifier. This field is the URL parameter name that will be analyzed by the farm service and will manage the client session.

After configuring this items and pressed the Modify Button, it's needed to restart the farm

service to apply the changes.

PARM a URI parameter. Another way to identify a client session is done through a URI parameter. This is a field separated by a semicolon like the following " http://www.example.com/private.php;EFD4Y7 "

To configure this kind of persistence is sufficient to select the PARM option and press the Modify Button. Finally, to apply the changes will be necessary to restart the farm 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 identify the client session, for example:

With this specification, the following configuration will be needed:

After configuring this items and pressed the Modify Button on all of them, it's needed to restart

the farm service to apply the changes.

GET /spec.html HTTP/1.1

Host: www.example.org

Cookie: sessionidexample=75HRSd4356SDBfrte

HEADER a certain request header. A custom field of the HTTP header could be used to identify the client session. For example:

With this specification, the following configuration will be needed:

After configuring this items and pressed the Modify Button on all of them, it's needed to restart the farm service to apply the changes.

HTTP verbs accepted. This field 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).

GET /index.html HTTP/1.1

Host: www.example.org

X-sess: 75HRSd4356SDBfrte

To apply any of these options, press the Modify Button and restart the farm service.

HTTPS Certificate. The SSL certificate is only avaliable for HTTPS farms, where a list of certificates will be shown to be selected for the current farm. This list could be modified under the Manage::Certificates section.

To apply this configuration press the Modify Button and restart the farm service.

Personalized error messages. Through the personalized error messages, the farm service is able to answer a custom message of your site when a web code error is detected from the real servers. A personalized HTML page will be shown.

To apply the changes press the Modify Button and restart the farm service.

5.2.2 Edit Farm Real Servers

Once a new farm is created, you've to include the servers with the real services to deliver the input connections.

Under the Edit real IP servers table configuration you'll be able to include the configuration backends for every backend and their specific parameters.

The common properties to be entered for a real backend are the following:

Server. It's an automatic ID established to be an index for 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 farm, you'll be able to configure the following 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 for the current real server which is only useful if the Weight Algorithm is enabled. More weight value indicates more connections delivered to the current backend.

Priority. It's the priority value for the current real server which is only useful 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 configuration, or you'll be able to cancel

the process through the button. A message with the result will be displayed.

Once the real server configuration is entered, you'll be able to edit the config throught the Edit button

or delete the configuration with the Delete Real Server button.

The server index is useful to identify the real server configuration for the current farm.

The changes of the real servers configuration for the TCP and UDP profiles are applied online, and a restart action isn't needed.

5.2.2.2 HTTP/HTTPS Profile

With a HTTP or HTTPS farm, you'll be able to configure the following properties:

Timeout. It's the specific value of timeout for a backend to response. This value override the global timeout farm parameter for the current backend.

Weight. It's the weight value for the current real server. By default a value of 5 is established.

With the Save Real Server button you'll apply the new configuration, or you'll be able to cancel

the process.

For the HTTP/HTTPS farm profile a message with the result will be displayed and a restart action will be requested to the administrator to the changes take effect. To apply the new configuration you have to restart the farm through the restart button .

The TIP message will not disappear until the farm is restarted.

Once the real server configuration is entered, you'll be able to edit the config throught the Edit button

or delete the configuration with the Delete Real Server button.

The server index is useful to identify the real server configuration for the current farm.

The changes of the real servers configuration for the HTTP and HTTPS profiles needs a manual farm restart.

5.2.3 View Status Farm Action

This action shows the actual state of backends, clients and connections that are being delivered from the virtual service to the real servers.

The Real Server Status table shows the state of every backend:

Server. It's the backend identification 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 for the current backend, indepently of farm service.

Established Conns. This is the number of established connections in the system that are on ESTABLISHED state for the current backend, indepently of farm service.

Closed Conns. This is the number of closed connections in the system that are on TIME_WAIT state for the current backend, indepently of farm service.

Clients. It's the number of clients (unique IP addresses) that are associated with the current backend server. This is only avaliable for TCP farms.

Sessions. It's the number of HTTP client sessions that are associated with the current backend server. This is only avaliable for HTTP and HTTPS farms.

Weight. It's the weight value established for every backend.

Priority. It's the priority value established for every backend server. This option is only avaliable for HTTP and HTTPS farms.

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 information pressing the Maximize

button.

Note that for very high load farms showing this table could slowdown the machine and could be shown a very large table.

5.3 Manage::Certificates Section

The Certificates inventory table is used to manage the SSL certificates to be used for the HTTPS profile farms.

All the certificates has to be generated a PEM file extension to be valid for HTTPS farms. By default a zencert.pem certificate is possible to be used and is not able to be deleted.

5.3.1 Adding a new Certificate

To upload a custom certificate it's necessary to press the button Upload Certificate to be used for

SSL wrapper.

A new window is shown to upload a custom certificate through the Browse... button on your local computer.

To upload the new certificate file it's needed to press the Upload button. Automatically, the new file will be accessible for the balancer.

Then we're able to select the certified uploaded to be used for the HTTPS farms.

5.4 Monitoring::Graphs Section

This section is useful to monitorize the internal load balancer system to detect problems through the parameters of CPU usage, swap memory, ram memory, all configured nework interfaces, load and hard disk storage.

All the graphs that are shown in the first 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 files and then establish the number of tailed lines to be shown pressing the See logs button.

The files are associated to the following services:

ucarp.log. Log file for cluster service.

zenlatency.log. Log file for latency service launcher of ucarp service.

zeninotify.log. Log file for config replication service.

mini_https.log. Log file for the web gui http service.

zenloadbalancer.log. Log file for the global zen load balancer actions service through the web GUI.

farmguardian.log. Log file for farmguardian advanced monitoring service.

5.6 Settings::Server Section

This section provides some global parameters for the load balancer server system.

The meaning of these parameters are the following:

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 config 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 interface where the web panel service will be bind to. It's safe 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 file content to apply the DNS servers for the system.

APT repository. This is the /etc/apt/sources.list file content to apply the APT repositories for 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 configuration panel for Zen Load Balancer, where will be shown the network interfaces table for physical, virtual and vlan interfaces, and the default gateway configuration field.

At the Interfaces Table will appear all the physical network interfaces installed in the system after the ZenLB installation. The meaning of every table fields are the following:

Name. It's the name of the current interface and will be unique. The virtual interfaces will be identificated by a colon ":" character within the interface name, meanwhile the vlan is identificated by a dot "." character within the interface name which will be the vlan tag.

Addr. It's the IP address in ipv4 format for the current network interface.

HWAddr. It's the MAC physical address for the current network interface. Note that the virtual and vlan network interfaces have the same MAC address of its parent physical interface.

Netmask. It's the netmask of the network interface, which defines the subnet of the network for the current interface.

Gateway. It's the gateway for the current network interface. ZenLB could work with independent route tables for every physical or vlan network interfaces. Virtual interfaces always inherit the gateway from the parent physical or vlan interface.

Status. A green dot means the interface is UP and running, meanwhile a red dot means an interface is DOWN. Sometimes a disconnect icon will be shown when the interface is UP but it hasn't link.

Actions. The action icons are used to apply changes to the current network interface. Applying a certain action could affect to one or more network interfaces.

Down interface. Disables the current interface.

Up interface. Enable the current interface.

Edit interface. Change the current network interface configuration.

To apply the changes press the Save & Up! Button.

Add virtual interface. Adds a new virtual interface inherited from the current network

interface.

Creating a new virtual interface will appear a field with a colon ":" character that will be used to establish an identification for the virtual interface. The IP address has to be under the same subnet that the parent interface.

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 interface inherited from the current network interface.

Creating a new vlan interface will appears a field with a dot "." character that will be used to

establish an identification for the vlan interface. The IP address could be different of the parent interface.

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 interface 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 following:

GUI service is bind to a certain interface. In this case, a home icon is shown and some actions are disabled to be safe from bad configurations 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 interfaces, and finally restart the GUI service.

Cluster configuration. In this case, the cluster has been configured and the interfaces configuration is only enabled when the cluster is disabled.

Finally a default gateway for the system could be established through the Defatul gateway table.

To change this field, you've to press the edit button and enter the gateway address and interface.

To apply the new configuration press the Save button or Cancel to reject the changes.

To remove the default gateway press the Delete Button.

5.8 Settings::Cluster Section

On this section you can configure the cluster service and check the cluster service status. During the cluster process configuration you don't have to access to the second node, as the configuration 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 for the cluster service, if you didn't configure one, please go to Settings::Interface and configure one, this virtual interface is only needed to be configured on the first node that you are configuring the cluster service.

Local hostname and Remote Hostname. Once a virtual interface is selected the hostnames and IP address information about the cluster nodes are needed.

Press the Save button to save the changes. At this point, it's needed that the physical IP for both nodes are configured over the same physical interface that the "virtual IP Cluster" on the last step (for example, eth0).

Remote Hostname root password. Enter the second node root password, this information won't be memorized, it's only needed to configure 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 from the current node to the remote node is working fine.

A message like the following 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 powerful server than node2.

node1 or node2 can be masters: anyone can be master, there is no automatic failback when one node is recovered. If you have two very similar servers for node1 and node2 that can both handle the full load of your traffic then you can use this option.

To connect two Zen Load Balancer servers over cross over cable for 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 configure the cluster, at this point you can press the refresh icon to update the cluster status view.

If the cluster is configured and working fine 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 configured 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 configuration and changes of networking and farms.

Over the cluster configured 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 force is useful after a cluster service recovery.

Test the RSA connection. Verify that the RSA connection between nodes is working fine that it's needed for syncronization over zen inotify service.

Force failover. Switch the cluster service node. It's useful 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 for only 30 seconds, after that, the cluster service will be switched back to node1.

Once the cluster service is configured you'll be able to change the cluster type but the service could produce some outages.

Over the web GUI is easy to identify which is the cluster role for both nodes. On the upper side of the webpage will show this message for the master node:

And for the backup node:

Once the cluster service is running on both nodes you only have to connect to master node to apply changes for farms and interfaces, which will be automatically configured 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

With the Backup option you can save the configurations on the ZenLB server and download to your local computer.

On this panel you can create, restore, upload and download backup files.

The Description name field will be the identification for the backup file to be generated pressing the Create Backup button. Please, do not include blank spaces.

The new backup file generated will be listed on the Backup files table:

The actions to be applied are the following:

: Through this icon you can download the selected file.

: Through this icon you can delete the selected backup file.

: Through this icon you can apply this backup. The config files will be rewritten if exists.

: Through this icon you can upload a backup file. It's useful if you've created a backup and

downloaded it for 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 files to select your backup file to be uploaded. It is important to know that the file need to follow the next pattern:

backup-description.tar.gz

If you modify the pattern, then the file isn't going to be listed on the Settings::Backup section.

6 Farm Guardian Usage

6.1 Philosophy

By default Zen Load balancer checks the tcp backends port status, but sometimes this check its not enough to conclude that the backend status is working fine. 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 avaliable scripts under the /usr/local/zenloadbalancer/app/libexec/ directory.

Farm Guardian checks the execution error output from the selected script ($? = 0 when there isn't error for the backend and $? 0 when there is an error for 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 farm and will list the backends and ports. Then the selected script will be runned for each server replacing the HOST and PORT token string by each backend and port configured on your farm.

6.2 Configuration

At the moment, Farm Guardian is only implemented for TCP profile:

To enable the Farm Guardian monitoring check the box Use FarmGuardian to check Backend Serversand establish the time period of checks:

Now select a default script under the path /usr/local/zenloadbalancer/app/libexec or include your own script on that directory:

Farm Guardian connects to the farm to obtain the backend list and execute this script for 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 for Farm Guardian checking the Active logs checkbox.

7 License

This documentation has been created by the Zen Load Balancer Developers Team for 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.