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
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest


-- 
Rick




_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to