Reliability Options

Load-Balancing Options

Clearly a production environment needs to have load balancing in order to ensure that an application will be able to support an appropriate load. In this section, we examine a couple of options for load-balancing client requests across a number of servers: hardware load balancing and the use of Resin as a balancer.

Hardware Load Balancing

In a typical production environment where a hardware load balancer is used, there is generally a single Resin server on each of the server machines. The hardware load balancer is configured to send requests in an intelligent manner to the back-end servers. Figure 19.3 shows an example of this configuration.

Figure 19.3: Hardware load-balancing configuration.

Since the hardware load balancer doesn't know anything about the requests coming from the client browsers, you must define distributed sessions for all of the Resin servers. With the configuration shown in Figure 19.3, the Resin configuration file would look like this:

 <resin xmlns="http://caucho.com/ns/resin">   <javac compiler='jikes'/>   <server>     <cluster-definition id='a'>       <srun id='srun-a' index='2' host='localhost' port='6810'/>     </cluster-definition>     <host id=' '> <web-app id='/'>       <servlet servlet-name='remote'                servlet-class='com.caucho.servlets.LoadBalance- Servlet'>         init-param cluster='a'/>       </servlet>       <servlet-mapping url-pattern='/remote/*' servlet- name='remote'/>       </web-app>     </host>   </server> </resin> 

All of the servers use the same configuration file but start in slightly different ways. In a Unix farm, you start the three servers with these commands:

 Server 1> bin./resin -server resina -pid resina.pid start Server 2> bin/resin -server resinb -pid resinb.pid start Server 3> bin/resin -server resinc -pid resinc.pid start 

On a Windows farm, you use the following startup command lines:

 Server 1> bin.httpd -server resina -install-as resina Server 1> net start resina Server 1> bin.httpd -server resinb -install-as resinb Server 1> net start resinb Server 1> bin.httpd -server resinc -install-as resinc Server 1> net start resinc 

Using Resin as a Balancer

If you have a production system that doesn't include a hardware load balancer but you still want to provide this kind of reliability, you can use Resin itself and a servlet called LoadBalanceServlet. This configuration uses a machine running Resin that acts as the load balancer, as shown in Figure 19.4.

Figure 19.4: Configuring a Resin load balancer.

The LoadBalanceServlet is very flexible, and it allows server groups to be created based on specific requests. For example, Figure 19.5 shows a Resin load balancer that sends requests for /company.com to a server farm and requests for /ourcompany.com to a single server.

Figure 19.5: A Resin load balancer-specific request.

Not only is the Resin server able to provide load balancing, but Resin's internal cache provides better overall performance for all hosted sites. When configuring a Resin load-balance system, you need two configuration files: one for the load -balancing server and one for all of the back-end servers. Let's consider the configuration in Figure 19.5. The load-balancing configuration is:

 <server>   <http port='80'/>    <cluster-definition >      <srun id='resina' index='1' host='192.168.0.1'/>      <srun id='resinb' index='2' host='192.168.0.2'/>    </cluster-definition>    <cluster-definition >      <srun id='resinb' index='3' host='192.168.0.3'/>    </cluster-definition> <servlet>   <servlet-name>resingroup-a</servlet-name>   <servlet-class>com.caucho.servlets.LoadBalanceServlet </servlet- class>   <init-param cluster='a'/> </servlet> <servlet-mapping url-pattern='/company.com/*' servletname=resingroup- a/> <servlet>   <servlet-name>resingroup-b</servlet-name>   <servlet-class>com.caucho.servlets.LoadBalanceServlet </servlet- class>   <init-param cluster='b'/> </servlet> <servlet-mapping url-pattern='/ourcompany.com/*' servletname='resingroup-b'/> <server> 

In this configuration we have two LoadBalanceServlet servlets executing to handle client requests. Requests for company.com/* go to a three-server farm; requests for ourcompany.com/* go to a single server.

The configuration files for each of the back-end servers defined earlier resemble the load-balancer configuration file without the servlet mapping and session management. For example:

 <server>   <http port='80'/>   <cluster>     <cluster-group>       <srun id='resina' index='1' host='192.168.0.1' port='6802'/>       <srun id='resinb' index='2' host='192.168.0.2' port='6802'/>       <srun id='resinc' index='3' host='192.168.0.3' port='6802'/>     </cluster-group>     <cluster-group>       <srun id='resind' index='1' host='192.168.0.4' port='6802'/>     </cluster-group>   </cluster>   <session-config>     <tcp-store/>   </session-config> </server> 

Using srun-backup

In those situations where a load balancer or router is used to distribute load to multiple servers and each is running both a Web server and a servlet engine, you can use the <srun-backup> element to provide greater reliability.

When a Web server receives a request, it attempts to send the servlet request to a primary machine. If the request isn't successful, another servlet machine is attempted. For this situation to work, the configuration files must include distributed-session management and use a host attribute in the initial <srun> element to indicate the primary servlet engine. For example:

 <server>   <cluster>     <srun  port='6802' index="1"/>     <srun  port='6802' backup='true' index="2"/>     <srun  port='6802' backup='true' index="3"/>     <srun  port='6802' backup='true' index="4"/>   </cluster> </server> 

Here, we tell the configuration to use the localhost servlet engine as the primary and other servers as backups.