Posts Tagged ‘pool’

Web Application Load Balancer types and when to use what kind of Load Balancer

Monday, February 3rd, 2014

General load balancer types description / active / passive / static / dynamic and additional
In this small article I will try to clear it up the general types of Web Server Load Balancers available. Whether one choose a Load Balancer he has the option to use a software LB or a hardware LB one there are plenty of software load balancer scripts out there. In this pos t I will mention just what choice is available in hardware load balancer interface BigIP LTM F5 standard. Generally BigIP LTM Load Balancers can be grouped in Static, Dynamic and Additional. One or more Load Balancers can be configured in front of group or farm of appplication servers. When more than one load balancer is used in front of application Load Balancer could be Active Load Balancer and Passive Load Balancer.
Below information will hopefully be useful to Web and Middleware working sys admins and anybody involved in frequent and large web systems integration.

Static Load Balancing

LB_RoundRobin_ type of load balancing example picture

Round Robin
Load Balancing

This is the default load balancing method. Round Robin mode passes each new connection request to the next server in line, eventually distributing connections evenly across the array of machines being load balanced.
Round Robin mode works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory.

ratio_member_load_balancer picture diagram

Ratio (member) / Ratio (node) Load Balancer

The Ratio (member) system distributes connections among pool members or nodes in a static rotation according to ratio weights that you define. In this case, the number of connections that each system receives over time is proportionate to the ratio weight you defined for each pool member or node. You set a ratio weight when you create each pool member or node.

These are static load balancing methods, basing distribution on user-specified ratio weights that are proportional to the capacity of the servers.

dynamic_ratio_member_load_balancer picture diagram

Dynamic Load Balancers


Dynamic Ratio (member) Dynamic Ratio (node) LB

The Dynamic Ratio load balancing select a server based on various aspects of real-time server performance analysis. These methods are similar to the Ratio methods, except that with Dynamic Ratio methods, the ratio weights are system-generated, and the values of the ratio weights are not static. These methods are based on continuous monitoring of the servers, and the ratio weights are therefore continually changing.
The Dynamic Ratio LBs are used specifically for load balancing traffic to RealNetworks® RealSystem® Server platforms, Windows® platforms equipped with Windows Management Instrumentation (WMI), or any server equipped with an SNMP agent such as the UC Davis SNMP agent or Windows 2000 Server SNMP agent.

dynamic_load_balancing load balancer diagram picture with circles

Fastest (node) /Fastest (application) LB

The Fastest methods select a server based on the least number of current sessions. The following rules apply to the Fastest load balancing methods:

These LB require that you assign both a Layer 7 and a TCP type of profile to the virtual server interface where LB IP is binded.
If a Layer 7 profile is not configured, the virtual server falls back to Least Connections load balancing mode.

Note: If the OneConnect feature is enabled, the Least Connections methods do not include idle connections in the calculations when selecting a pool member or node. The Least Connections balancing use only active connections in their calculations.
Fastest node load balancing is useful in environments where nodes are distributed across separate logical networks.


Least Connections (member) / Least Connections (node) LB    

The Least Connections method are relatively simple in that the system passes a new connection to the pool member or node that has the least number of active connections.

Note: If the OneConnect feature is enabled, the Least Connections methods do not include idle connections in the calculations when selecting a pool member or node. The Least Connections methods use only active connections in their calculations.
The Least Connections balancing function best in environments where the servers have similar capabilities. Otherwise, some amount of latency can occur.

For example, consider the case where a pool has two servers of differing capacities, A and B. Server A has 95 active connections with a connection limit of 100, while server B has 96 active connections with a much larger connection limit of 500. In this case, the Least Connections method selects server A, the server with the lowest number of active connections, even though the server is close to reaching capacity.

If you have servers with varying capacities, consider using the Weighted Least Connections load balancing instead.


Weighted Least Connections (member) / Weighted Least Connections (node)

Like  Least Connections, these load balancing methods select pool members or nodes based on the number of active connections. However, the Weighted Least Connections methods also base their selections on server capacity.

The Weighted Least Connections (member) method specifies that the system uses the value you specify in Connection Limit to establish a proportional algorithm for each pool member. The system bases the load balancing decision on that proportion and the number of current connections to that pool member. Example is member_a has 40 connections and its connection limit is 200, so it is at 20% of capacity. Similarly, member_b has 40 connections and its connection limit is 400, so it is at 10% of capacity. In this case, the system select selects member_b. This algorithm requires all pool members to have a non-zero connection limit specified.

The Weighted Least Connections (node) method specifies that the system uses the value you specify in the node's Connection Limit setting and the number of current connections to a node to establish a proportional algorithm. This algorithm requires all nodes used by pool members to have a non-zero connection limit specified.

If all servers have equal capacity, these load balancing  behave in the same way as the Least Connections methods.

Note: If the OneConnect feature is enabled, the Weighted Least Connections methods do not include idle connections in the calculations when selecting a pool member or node. The Weighted Least Connections  use only active connections in their calculations.

Weighted Least Connections methods work best in environments where the servers have differing capacities.
For example, if two servers have the same number of active connections but one server has more capacity than the other, the BIG-IP system calculates the percentage of capacity being used on each server and uses that percentage in its calculations.


Observed (member) / Observed (node)

With the Observed methods, nodes are ranked based on the number of connections. The Observed methods track the number of Layer 4 connections to each node over time and creates a ratio for load balancing.

The need for the Observered methods is rare, and they are not recommended for large pools.

Predictive (member) / Predictive (node)

The Predictive methods use the ranking methods used by the Observed methods, where servers are rated according to the number of current connections. However, with the Predictive methods, the BIG-IP system analyzes the trend of the ranking over time, determining whether a nodes performance is currently improving or declining. The servers with performance rankings that are currently improving, rather than declining, receive a higher proportion of the connections.

The need for the Predictive methods is rare, and they are not recommend for large pools.

Least Sessions LB type

The Least Sessions method selects the server that currently has the least number of entries in the persistence table. Use of this load balancing method requires that the virtual server reference a type of profile that tracks persistence connections, such as the Source Address Affinity or Universal profile type.

Note: The Least Sessions methods are incompatible with cookie persistence.
The Least Sessions method works best in environments where the servers or other equipment that you are load balancing have similar capabilities.


L3 Address

L3 Address is same LB type as Least Connections methods.

Share this on

How to configure NTP server (ntpd) to synchronize server clock over the Internet on FreeBSD

Friday, February 10th, 2012


FreeBSD ntpd logo / How to configure ntpd to synchronize with internet time servers on FreeBSD

On FreeBSD ntpd , ntpdc , ntpdate , ntpq doesn't need to be installed via a specific package like on GNU/Linux as they're part of the FreeBSD world (binary standardly shipped with FreeBSD basis system).

The FreeBSD handbook has a chapter explaining thoroughfully on ntp on FreeBSD ,however for the lazy ones here is a short few steps tutorial on how to install and configure ntpd on bsd :

1. Copy sample ntp.conf file to /etc/

freebsd# cp -rpf /usr/src/etc/ntp.conf /etc/ntp/

No need for any modifications if you don't want to apply some specific restrictions on whom can access the ntpd server. If you update regularly the FreeBSD system with freebsd-update or directly by rebuilding the FreeBSD kernel / world adding restrictions might be not necessery..

If you check /usr/src/etc/ntp.conf you will notice freebsd project people are running their own ntp servers , by default ntpd will use this servers to fetch timing information. The exact server hosts which as of time of writting are used can be seen in ntp.conf and are:

server iburst maxpoll 9
server iburst maxpoll 9
server iburst maxpoll 9

2. Add ntpd daemon to load on system boot via /etc/rc.conf

By default ntpd is disabled on FreeBSD, you can see if it is disabled or enabled by invoking:

freebsd# /etc/rc.d/ntpd rcvar
# ntpd

To Enable ntpd to get loaded each time it boots , following 3 lines has to be added in /etc/rc.conf .


Quick way to add them is to use echo :

echo 'ntpdate_enable="YES" >> /etc/rc.conf
echo 'ntpdate_flags="" >> /etc/rc.conf
echo 'ntpd_enable="YES" >> /etc/rc.conf

Now as the 3 rc.conf vars are set to "YES", the ntpd can be started. Without having this variables in /etc/rc.conf , "/etc/rc.d/ntpd start" will refuse to start ntpd.

3. Start the ntpd service

freebsd# /etc/rc.d/ntpd start

One interesting note to make is ntpd can also operate without specifying any config file (/etc/ntp.conf), the only requirement for the server to start is to have a properly set ntpdate server, like lets say (ntpdate_flags="")

4. Permit only certain host or localhost to "talk" to the ntpd server

If you want to imply some ntp server restrictions, the configuration directives are same like on Linux:

To allow only a a host inside a local network with IP as well as localhost, to be able to fetch time information via ntpd server put inside /etc/ntp.conf:

restrict mask nomodify notrap

If you want to prohibit ntpd to serve as a Network Time Server, to any other host except localhost, add in /etc/ntp.conf :

restrict default ignore

Allowing and denying certain hosts can be also done on pf (packet filter) or ipfw firewall level, and in my view is easier (and less confusing), than adding restrictions through ntp.conf. Besides that using directly the server firewall to apply restrictions is more secure. If for instance a remote exploit vulnerability is discovered affecting your ntpd server. this will not affect you externally as access to the UDP port 123 will be disabled on a firewall level.
Something good to mention is NTP servers communicate between each other using the UDP source/destination (port 123). Hence if the NTPD server has to be publicly accessible and there is a firewall already implemented, access to source/dest port 123 should be included in the configured firewall …

5. Check if the ntp server is running properly / ntp server query operations

[root@pcfreak /home/hipo]# ps axuww|grep -i ntp
root 15647 0.0 0.2 4672 1848 ?? Ss 2:49PM 0:00.04 /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ -f /var/db/ntpd.drift

To query the now running ntpd server as well as set various configuration options "on the fly" (e.g. without need for ntp.conf edits and init script restart), a tool called ntpdc exists. ntpdc tool could be used to connect to localhost running ntpd as well as to connect and manage remotely a ntpd server.
The most basic use of ntpdc is to check (server peers).:
freebsd# ntpdc localhost
ntpdc> peers
remote local st poll reach delay offset disp
=================================================== 2 64 377 0.00282 -0.050575 0.06059
*billing.easy-la 2 64 377 0.01068 -0.057400 0.06770
=ns2.novatelbg.n 2 64 377 0.01001 -0.055290 0.06058

ntpdc has also a non-interactive interface, handy if there is a need for requests to a ntpd to be scripted. To check ntpd server peers non-interactively:

freebsd# ntpdc -p localhost
=================================================== 2 64 377 0.00284 -0.043157 0.06184
=billing.easy-la 2 64 377 0.01059 -0.042648 0.05811
*ns2.novatelbg.n 2 64 377 0.00996 -0.041097 0.06094

ntpdc has plenty of other ntpd query options, e.g. :

ntpdc> help
ntpdc commands:
addpeer controlkey fudge keytype quit timeout
addrefclock ctlstats help listpeers readkeys timerstats
addserver debug host loopinfo requestkey traps
addtrap delay hostnames memstats reset trustedkey
authinfo delrestrict ifreload monlist reslist unconfig
broadcast disable ifstats passwd restrict unrestrict
clkbug dmpeers iostats peers showpeer untrustedkey
clockstat enable kerninfo preset sysinfo version
clrtrap exit keyid pstats sysstats

ntpdc is an advanced query tool for ntpd , servers. Another tool exists called ntpq which syntax is almost identical to ntpdc . The main difference between the two is ntpq is a monitoring tool mostly used just for monitoring purposes, where ntpdc can also change plenty of things in the server configuration.

For people who want to learn more on ntpd the man page is a great reading , containing chapters describing thoroughfully exactly how NTPD time servers operate, etc.

Share this on

Fix of “Unable to allocate memory for pool.” PHP error messages

Saturday, October 15th, 2011

Since some time, I don’t know exactly where, after some updates of my WordPress running on a small server with FreeBSD 7.2. I’ve started getting a lot of Apache crashes. Often the wordpress scripts stopped working completely and I got only empty pages when trying to process the wordpress blog in a browser.

After a bunch of reading online, I’ve figured out that the cause might be PHP APC stands for Alternative PHP Cache .

I was not sure if the PHP running on the server had an APC configured at all so I used a phpinfo(); script to figure out if I had it loaded. I saw the APC among the loaded to show off in the list of loaded php modules, so this further led me to the idea the APC could be really causing the unexpected troubles.

Thus first I decided to disable the APC on a Virtualhost level for the domain where the crashing wordpress was hosted, to do I placed in the VirtualHost section in the Apache configuration /usr/local/etc/apache2/httpd.conf the following config directive:

php_flag apc.cache_by_default Off

These get me rid of the multiple errors:

PHP Warning: require_once() [function.require-once]: Unable to allocate memory for pool. in /usr/local/www/data-dist/blog/wp-content/plugins/tweet-old-post/top-admin.php on line 6

which constantly were re-occuring in php_error.log:

Further after evaluating all the websites hosted on the server and making sure none of which was really depending on APC , I’ve disabled the APC completely for PHP. To do so I issued:

echo 'apc.enabled = 0' >> /usr/local/etc/php.ini

Similarly on GNU/Linux to disable globally APC from PHP only the correct location to php.ini should be provided on Debian this is /etc/php5/apache2/php.ini .

Share this on