On 11/8/12 6:11 PM, Rick Mann wrote:
> I've used Resin for 6 or 8 years now, ever since working at a company that 
> used it.
> I use it for a lot of little personal projects and web sites, nothing very 
> substantial. But there's a chance that something I did recently will grow, 
> and I'm looking at how to use Resin with Rackspace virtual hosts.
> I'm finding it hard to get through some of Caucho's concepts. How is a web 
> server different from an app server? Is a web server the same as a load 
> balancer? All my apps run completely self-contained on a single server, 
> talking to a MySQL instance running on the same machine, using Hibernate and 
> no special caching.
> I'm having a hard time quickly learning how to move from that environment to 
> the triad and elastic servers. Can I take the intermediate step of running 
> just two servers?
> How does load balancing work? I've only ever used a Big IP F5. Do I want to 
> bother with Rackspace's load balancers?
> Stuff like that. Is there a good introductory document (not just a set of 
> slides)? So far, everything I've read assumes a certain level of knowledge.

We're working on a video that should help.

In the meantime:

1) Basically, we start with a single server, just like you're using now. 
That's an "app" server because it runs your applications (it also serves 
static web requests of course.).

   app_servers :

2) Now you either want or need a second app server, either because of 
load or memory or reliability. That would be two servers. The two 
servers would be the first two in the triad. The triad stuff happens 
automatically. The first servers in your list are triad members. In 
truth, you don't usually need to know about the triad, except you should 
take a little care to put them on different hardware for reliability.

   app_servers :,

(You can also put two Resin servers on one box. Just use the same IP and 
different ports, like 6801. We use this for testing all the time, and 
some people do that for reliability or better memory management on one 

3) load balancing

But now there's a difficulty because some how the requests need to be 
shared across the multiple servers, so you need a load balancer of some 

Resin doesn't care what load balancer you use. We're trying to support 
whatever configuration you want, assuming that you have a better idea of 
how you want to balance your own load.

Resin's load balancer is mostly provided as an option for medium sites 
so you don't need to use a hardware load balancer, and because it's easy 
to configure. (Some sites even use a hardware load balancer in 
combination with Resin's load balancer.)

If you're using a non-Resin load balancer, just point it to the 2 
server's http ports.

If you're using Resin's load balancer, just add a web_server entry:

   web_servers :

In this case, I put the load balancer on the first machine. That's a 
perfectly reasonable configuration for a smallish configuration.

Make sure all servers are using the same resin.xml and resin.properties. 
The entire point of Resin's design is to allow you to use a single 
configuration for your entire cluster.

4) Adding servers.

You can keep adding servers to the app_servers list. The first three are 
automatically the triad. You don't need to do anything special, but if 
you have different physical servers, it's a good idea to split them for 
reliability. As long as every server sees that app_servers, the load 
balancing will just work with the new servers.

5) "web" vs "app" tiers.

The idea of those two is to mirror the common Apache/Resin or 
nginx/Resin "reverse proxy" configuration where you replace Apache with 
another Resin. You can use that configuration even if you have one 
app-server. (Benefit is that it isolates the application from the actual 
network. The penalty is a bit of performance.)

The "web" tier is simple and more reliable because it's only serving 
HTTP requests and cached data. It also isolates the web from the app 
tier, because only the web tier needs to worry about things like flaky 
network connections.

When you're using Resin as a load balancer the web tier is the load 

6) The triad.

Mostly, it's an internal Resin clustering concept.

The main purpose is to handle clustering for fairly large sites that 
have large variations in load where they want to add or drop servers 

The triad servers are the reliable servers. You don't actually need 3. 
If you have 2, the 2 servers act as backups for each other. The key of 
the triad is that every other server: 4, 5, 6 can be can be added or 
dropped whenever you want without affecting things like clustered 
sessions or caching.

For example, you can configure 7 servers, and only have 3 live. Shut 
down the last 4 and the system just works. But _don't_ shut down the 
first 3, because that's the triad. That's really the only reason you 
need to know about the triad (other than putting on different hardware 
for reliability.)

7) elastic servers.

The elastic server idea is just a way for you to be lazy about 
configuration, when you have lots of servers. Without elastic servers, 
you can just keep changing the app_servers in resin.properties on every 

   app_servers :,,,, ...

But to make this work, you need to update every server configuration 
when you want to add a new server.

The elastic servers lets you be lazy. You still need to configure 
"static" servers. A "static" server just means you have an explicit 
configuration in the resin.properties. But you can add elastic servers 
without updating all the configuration files.

   # static servers (you can have more or less. We recommend 3 if you 
have at least 3 servers.)
   app_servers :,,
   elastic_server : app:1

The "elastic_server" tells Resin that this server is an elastic server. 
Resin will automatically use the IP address and connect to the static 
servers, announce itself.

8) summary

Basically, you can ignore most of the concepts. Just try this experiment 
on a single server:

   app_servers :,
   web_servers :

   web-0.http : 8080
   app-0.http : 8090
   app-1.http : 8091

That will configure 1 web server at :8080 which will also act as a load 
balancer, and 2 app servers where your application will be deployed. 
Just browse to :8080 and you'll automatically be load balanced.

The app-0.http :8090 isn't absolutely necessary but it's nice to be able 
to connect to the server directly if necessary.

Also, if you use the "resinctl deploy -server app-0" to deploy your 
application, it will automatically get copied to app-1. You can still 
copy to webapps yourself, of course, if you prefer.

-- Scott

> Thanks,

resin-interest mailing list

Reply via email to