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? -- Rick 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 > 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 > firstname.lastname@example.org > http://maillist.caucho.com/mailman/listinfo/resin-interest -- Rick _______________________________________________ resin-interest mailing list email@example.com http://maillist.caucho.com/mailman/listinfo/resin-interest