TCP/UDP profile farms

TCP/UDP EDIT GLOBAL PARAMETERS

In this panel you’ll be able to set the parameters to improve your farms performance and your virtual service custom features for TCP and UDP farms.

The TCP/UDP farm profile provides a distribution panel with the following parameters:

Farm’s name. It’s the identification field and a description for the virtual service. In order 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. Ensure that the new farm name is available, in another case an error message will appear.

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 bound and listening in the load balancer system. To make changes in these fields, ensure that the new virtual IP and virtual port are not in use. In order to apply the changes the farm service will be restarted automatically.

Load Balance Algorithm. This field shows the different load balancing algorithms that are possible to be configured for the current farm. Four algorithms are available. Selecting an inappropriate 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 available 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 it’s more powerful if you’ve 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 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 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, it will be 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 available for UDP farms.

Max number of clients memorized in the farm. These 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 available for UDP farms.

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.

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 available for UDP farms.

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.

Use farmguardian to check backend servers. Checking this box will enable a more advanced monitoring state for backends and totally personalized for your own 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 don’t have need to restart the farm service. To get more details about this service, please read the FarmGuardian section. This option is not available for UDP farms.

TCP/UDP EDIT REAL SERVERS CONFIGURATIONS

Once a new farm is created, you’ve to include the servers with the real services in order to deliver the client 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.

With a TCP or UDP farm, you’ll be able to configure the following properties:

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.
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, delete the configuration with the Delete Real Server button, enable the maintenance mode for the backend in order to stop sending requests to the current server or disable the maintenance mode for the current backend in order to start again to send requests to the seleted server.

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.

TCP/UDP VIEW STATUS

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

Refresh stats option will allow to refresh the status view every 10, 30, 60 or 120 seconds. It must be used with caution as this feature could overload the load balancer.

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

Server. It’s the backend identification number within the farm.
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 (it could be due to a connection error or due to farmguardian advanced checking), meanwhile a green dot means that the backend is online and delivering connections. A yellow dot means that the backend is in maintenance mode.
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 available for TCP farms.
Weight. It’s the weight value established for every backend.
Priority. It’s the priority value established for every backend server. Not available for HTTP farm profiles.

In order 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.

The Client sessions status will be only populated when the client persistence is enabled.

Client. Client connection identification.
Address. Client connection IP address.
Age(sec). Client total time that the connection is being alive (in seconds).
Last Server. Last backend server where the client connection has been delivered.
Connects. Client total connections counter since the client session is memorized.
Sent(mb). Total data amount the client has sent to the load balancer (in Mb).
Received(mb). Total data amount the client has received from the load balancer (in Mb).

Connection. Connection identification within the load balancer core where the association between the client and server is recorded.
Client. Client identification within the load balancer core.
Server. Server identification within the load balancer core.

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

Share on:

Documentation under the terms of the GNU Free Documentation License.

Was this article helpful?

Related Articles