balance.xtp

解压在c盘

<s1 title="Reliability and Load Balancing">

<summarylist/>

<p>As traffic increases, web sites need to add additional web
servers and servlet engines.  Distributing the traffic across the
servers and coping when a server restarts is the challenge of
load balancing.</p>

<ul>
<li>What is balancing the load?
<ul>
<li>Hardware load-balancer
<li>Resin web server using LoadBalanceServlet
<li>Web Server (Apache/IIS) with plugin
</ul>
<li>How is session consistency maintained?
<ul>
<li>Sticky sessions
<li><a href="sessions.xtp">distributed sessions</a>
</ul>
</ul>

<p>In general, the hardware load-balancer will have the best results
while using the Resin or Apache/IIS is a low-cost alternative for
medium sites.</p>

<s2 title="Hardware Load Balancing">

<p>Sites with a hardware load balancer will generally put one Resin JVM
on each server and configure the load balancer to distribute the load
across those JVMs.  Although it's possible to configure Resin with Apache/IIS
in this configuration, it's not necessary and running the Resin as a web
server reduces the configuration complexity.</p>

<p>Sites using sessions will configure <a
href="sessions.xtp">distributed sessions</a> to make sure the users
see the same session values.  The IP-based sticky sessions provided by
hardware load balancers should be used to increase efficiency.  The
IP-sessions will usually send the request to the right server, but
there are clients behind firewalls and proxies which will have
different IPs for each request even though the session is the same.
IP-sessions are only mostly sticky.</p>

<p>A typical configuration will use the same resin.conf for all
servers and use the -server flag to start the correct one:</p>

<example title='resin.conf for all servers'>
&lt;http-server>
  &lt;srun id='a' host='192.168.0.1' port='6802' srun-index='1'/>
  &lt;srun id='b' host='192.168.0.2' port='6802' srun-index='2'/>
  &lt;srun id='c' host='192.168.0.3' port='6802' srun-index='3'/>
  &lt;srun id='d' host='192.168.0.4' port='6802' srun-index='4'/>

  &lt;session-config>
    &lt;tcp-store/>
  &lt;/session-config>

  ...
&lt;/http-server>
</example>

<p>On Unix, the servers will generally be started using some
<a href="httpd.xtp#script">startup script</a>.  Each server will have
a different value for -server and for -pid.</p>

<example title="Starting each server on Unix">
unix> bin/resin -server a -pid server-a.pid start
</example>

<example title="Installing each server on Windows">
resin> bin/httpd -server a -install-as resin-a
resin> net start resin-a
</example>
  
</s2>

<s2 title="Using Resin as the Load Balancer">

<p>Resin 2.1 includes a LoadBalanceServlet which will balance
requests to backend servers.  Because it's implemented as a servlet,
this configuration is the most flexible.  A site might send all
requests for /foo to the backend host 192.168.0.1  and all requests to
/bar to the backend host 192.168.0.2.  Since Resin has an
integrated HTTP proxy cache, the front-end machine can cache results
for the backend servers.</p>

<p>Using Resin as the load balancing web server, requires a minimum
of two configuration files: one for the load balancing server, and one
for the backend servers.  The front configuration will dispatch
several url-patterns to the backend servers, while the backend will
need to actually serve the requests.</p>

<p>The following example sends all URLs starting with /foo to one
of the servers in srun-group <var/a/>.</p>

<example title="front.conf">
&lt;http-server>
  &lt;http port='80'/>

  &lt;srun id='back1' srun-group='a' srun-index='1'
           host='192.168.0.1' port='6802'/>
  &lt;srun id='back2' srun-group='a' srun-index='2'
           host='192.168.0.2' port='6802'/>
  &lt;srun id='back3' srun-group='b' srun-index='3'
           host='192.168.0.3' port='6802'/>

  &lt;servlet>
    &lt;servlet-name>balance-a&lt;/servlet-name>
    &lt;servlet-class>com.caucho.http.servlet.LoadBalanceServlet&lt;/servlet-class>
    &lt;init-param srun-group='a'/>
  &lt;/servlet>

  &lt;servlet-mapping url-pattern='/foo/*' servlet-name='balance-a'/>
&lt;/http-server>
</example>

<ul>
<li>The &lt;http> and &lt;srun> must have different values for <var/id/>.
<li>The &lt;srun> must have an <var/id/> so they will not be
started along with the &lt;http>.
<li>Since the &lt;http> configuration has no <var/id/> it will be
used when you start Resin without a <var/-server/> configuration.
<li>The <var/srun-index/> is important and must match the <var/srun-index/>
in the backend configuration.
</ul>

<p>The backend server configuration is identical to the server
configuration for the hardware load balancer.  In general, most sites
will use some form of distributed session management.</p>

<example title='back.conf for all backend servers'>
&lt;http-server>
  &lt;srun id='a' host='192.168.0.1' port='6802' srun-index='1'/>
  &lt;srun id='b' host='192.168.0.2' port='6802' srun-index='2'/>

  &lt;session-config>
    &lt;tcp-store>
  &lt;/session-config>

  ...
&lt;/http-server>
</example>

</s2>

<s2 title="Balancing with the Apache/IIS plugin">

<p>To understand how Resin's load balancing works, it's important to review
how the plugin dispatches requests to the backend JVM, i.e. the srun.  The
following sequence describes a typical request:</p>

<ol>
<li>Request arrives at web server.
<li>Plugin (mod_caucho, mod_isapi, etc) checks if it's a Resin request
<li>Plugin selects a backend JVM, i.e. a &lt;srun>
<ul>
<li>If it's an old session, send it to the owner JVM. (sticky-sessions)
<li>If it's a new request, send it to the next &lt;srun>, using a
round-robin policy.
</ul>
<li>Plugin sends the request to the backend JVM with a TCP socket.
<li>Plugin receives the response from the backend JVM with the same TCP socket.
</ol>

<p>The plugin needs to know which requests should go to Resin, i.e. the
servlet-mappings.  And it needs to know the TCP host/port names of the
backend machines, i.e. the &lt;srun> and &lt;srun-backup> tags.
/caucho-status shows all that information in one table.  All the
plugins and the JVMs can read the same resin.conf, making maintenance
easier.</p>

<p>The plugin controls the load balancing since it needs to decide
which JVM to use.  Because the plugin is key in load-balancing, looking at
the /caucho-status will tell you exactly how your system is configured.
The JVMs are just passive, waiting for the next request.  From the
JVM-perspective, a request from a plugin is identical to
an HTTP request, except it uses a slightly different encoding.  In fact, with
Resin 1.2, the same JVM can server as an srun and as an httpd listening to
port 8080, for example.  The dual srun/http configuration can be
useful for debugging.
</p>

<p>Selecting a free JVM is done using a round-robin policy.
Although the round-robin policy is simple, in practice it is as
effective as complicated balancing policies.  In addition, because
it's simple, round-robin is more robust and faster than adaptive policies.
</p>

</s2>

<s2 title='Single Machine'>

<p>The cheapest backup strategy just uses a single machine for the web
server and two JVMs.  One JVM is designated as primary and the other
is a backup.  If the first fails for some reason, the second will take
over.  Because the backup is normally not used, it doesn't really take
up much system resources.</p>

<figure src="backup.gif"/>

<example title="resin.conf">
&lt;caucho.com>
&lt;http-server>

  &lt;srun id="a" host='localhost' port='6802' srun-index='1'/>
  &lt;srun-backup id="b" host='localhost' port='6803' srun-index='2'/>

  ...
  
&lt;/http-server>
&lt;/caucho.com>
</example>

<sidebar>Use <var//caucho-status/> to check your configuration</sidebar>

<p>You will start the two srun processes separately.  Each srun needs to
know which port to listen to.  The <var/-server/> argument to httpd.sh selects
a srun block to start.  <var/-server a/> selects the first one, i.e.
port 6802 and <var/-server b/> selects the second one.</p>

<p>Here's how to start them on unix:</p>

<example>
unix> httpd.sh -pid srun1.pid -server a start
unix> httpd.sh -pid srun2.pid -server b start
</example>

<p>On Unix, the <var/-pid/> is used to keep track of the live srun so
a later <var/httpd.sh stop/> will work.  It just names a file that will
contain the process id (pid) of the started process.</p>

<p>Use the -install-as to install them on NT.  <note>The -install-as must
occur before the -server</note>.</p>