Thanks, Scott, I'll read through that more carefully shortly.
One question. Do I set up one server with the multi-machine additions as you
show, and then just replicate the config file (and server, webapp, et al) onto
all the machines? I realize that may seem obvious, but I want to be sure.
Also, how do I get them to talk to each other via private interfaces? Or does
that happen magically with Rackspace?
On Nov 8, 2012, at 19:08 , Scott Ferguson <f...@caucho.com> wrote:
> 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 : 127.0.0.1:6800
> 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 : 192.168.0.10:6800, 192.168.0.11:6800
> (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 : 192.168.1.10:6820
> 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 : 192.168.1.10:6800, 192.168.1.11:6800,
> 192.168.1.12:6800, 192.168.1.13:6800, ...
> 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 : 192.168.1.10:6800, 192.168.1.11:6800, 192.168.1.12:6800
> 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 : 127.0.0.1:6800, 127.0.0.1:6801
> web_servers : 127.0.0.1:6810
> 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
> resin-interest mailing list
resin-interest mailing list