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 machine.) 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 sort. 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 balancer. 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 frequently. 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 machine: 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 > > Thanks, > _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
