Perlbal::Manual::LoadBalancer man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

Perlbal::Manual::LoadBUsercContributed Perl DoPerlbal::Manual::LoadBalancer(3)

NAME
       Perlbal::Manual::LoadBalancer - Using Perlbal as a Load Balancer

   VERSION
       Perlbal 1.78.

   DESCRIPTION
       How to configure a Perlbal Load Balancing service.

   READ ME FIRST
       Please read Perlbal::Manual::Configuration first for a better
       explanation on how to configure Perlbal. This document will make much
       more sense after reading that.

   Using Perlbal as a Load Balancer
       For a better understanding of how to set up Perbal as a Load Balancer,
       it should be noted that a Load Balancer and a Reverse Proxy can often
       be the same thing; not always, but often.

       A Load Balancer is a server (or device) that balances requests across a
       number of servers to spread the load. A Reverse Proxy can still do this
       but also have a number of other features.

       Perlbal as a Reverse Proxy provides features such as buffering content,
       preserving connections to the backend servers, starting connections
       ahead of time and a high priority queue, among others.

       You could almost say that a Load Balancer is a subset of a Reverse
       Proxy (it's not, but you could).

       When it comes to Perlbal, the Load Balancer is implemented as a Reverse
       Proxy without all the extra options, and that's why you set the role of
       a Load Balancer to "reverse_proxy":

	   SET role	       = reverse_proxy

       Simple load balancing

       Let's assume you want to configure two machines to serve your website
       and you want to let Perlbal decide how to balance the requests. For the
       sake of this exercise let's assume you have two servers at:

	   10.0.0.1:80
	   10.0.0.2:80

       And now you want to use these two machines to serve your website at:

	   10.0.0.3:80

       Here's a sample configuration to make this happen:

	   CREATE POOL mywebsite
	       POOL mywebsite ADD 10.0.0.1:80
	       POOL mywebsite ADD 10.0.0.2:80

	   CREATE SERVICE service_mywebsite
	       SET role		   = reverse_proxy
	       SET pool		   = mywebsite
	       SET listen	   = 10.0.0.3:80
	   ENABLE service_mywebsite

       The first line defines a pool of machines called "mywebsite". The
       second and third lines add your two machines to that pool (note that
       the indentation is not mandatory).

       After that you define a service called "service_mywebsite" with the
       role "reverse_proxy" set to listen on "10.0.0.3:80" and using the pool
       "mywebsite" to serve the requests.

       The last line is what allows you have several services configured in a
       file even if they are not currently active (a common scenario is to
       configure everything on the file and then enable/disable services on-
       the-fly as required; see Perlbal::Manual::Management for more
       information on this process).

       The Load Balancing algorithm

       Perlbal uses a highly efficient load balancing algorithm. It is very
       effective for distributing dynamic web requests among potentially
       heterogeneous hardware.

       First, backend servers must have their MaxClients (for apache, or
       equivalent) setting tuned to a reasonable limit. If your hardware can
       run 20 requests in parallel before running out of CPU, set MaxClients
       to 20.

       Next, by default Perlbal will distribute requests randomly. Opening a
       new connection to any available backend, and issuing the request.

       The proper algorithm is able to be used if "verify_backend",
       "backend_persist", "backend_persist_cache", and "connect_ahead" are
       enabled.

	   SET persist_backend	     = on
	   SET verify_backend	     = on
	   SET backend_persist_cache = 5
	   SET connect_ahead	     = 2

       In this configuration, Perlbal will only route client requests to
       backends that it knows are real processes, instead of the OS listen
       queue. It will attempt to reuse pre-verified backends, and will attempt
       to create slightly more idle connections than it needs in preparation
       of future requests.

       When you put all this together, it becomes less likely that a client
       will wait for Perlbal to find an available backend. By setting your
       MaxClients properly, backends are able to serve traffic without getting
       overwhelmed. If no backends are available, Perlbal will queue them
       internally, rather than overload backends.

       You would want to disable "verify_backend" if you are balancing across
       image servers, or other extremely lightweight requests.

   SEE ALSO
       Perlbal::Manual::Configuration, Perlbal::Manual::FailOver,
       Perlbal::Manual::Management, Perlbal::Manual::ReverseProxy.

perl v5.14.2			  2011-01-23  Perlbal::Manual::LoadBalancer(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net