Re: mod_perl in larger scale environments

LVS does sound interesting but in your infrastructure layout aren't your 
single LVS load balancers single points of failure? Especially if they 
are running on older hardware? Maybe that isn't important in your 
environment?  However, it seems like that negates a lot of the "high 
availability" goal of load balancing.

  It still may be a possibility for me, possibly running on the same 
host as my existing web layer apache instance and using a localhost 
connection... I will definitely look into it.

> Again, I'm used to working in web applications with a full blown app 
> server. I love working with mod_perl, but I do find myself missing the 
> advantages an app server gives me sometimes.

I'm ignorant there. What advantages exactly?

I'l be brief here because this is a mod_perl list :)

The specific product I'm used to working with is IBM Websphere, which 
allows you to cluster your individual app servers and then manage them 
all from one administration tool.  So settting or config changes, code 
deployments, etc... are snynced across all nodes.  It makes managing app 
"clusters" extremely easy.    It also provides a plugin to IBM's http 
server that handles proxying back to the application servers and 
provides load balancing/high availability,

Those are the two advantages that address my original questions 
directly.  App servers provide a lot of other benefits such as allowing 
you to leverage things like shared memory and shared DB and messaging 
connections/buses... many of these can be simulated in mod_perl.  
(Apache::DBI, etc...)




On 4/14/2010 6:27 PM, Cosimo Streppone wrote:
> In data 14 aprile 2010 alle ore 22:57:06, Brad Van Sickle 
> <[email protected]> ha scritto:
>
>> My first question relates to quality of service and load balancing:
>
> Hi Brad,
>
> we're using LVS (http://en.wikipedia.org/wiki/Linux_Virtual_Server),
> and I find it very useful and reliable.
>
> Our infrastructure for the modperl application, simplifying,
> consists of:
>
> a) 1 main "front" lvs load balancer
> b) 2 web frontends
> c) 1 "back" lvs load balancer
> d) 12 apache/modperl backends
> e) 5 db servers
> f) ...other stuff... :)
>
> a) load balances incoming traffic between the 2 web frontends.
> b) rewrites backend requests to a single address, "wlb" (web load 
> balancer)
>    which is handled by c)
> c) takes incoming requests for several different "virtual" hostnames, 
> as in:
>    wlb.domain.com => {weighted round robin to} => 
> (back1,back2,...,back12)
>    mlb.domain.com => {wrr} => (db1, db2, ..., db5) (mysql load balancer)
>    s-mlb.domain.com => {wrr} => (search-db1, search-db2, ...) (search 
> mysql lb)
> d) app servers are "stateless", so we don't need sticky sessions
>
> This architecture can be simplified, and we're trying to do it.
> So, I'm not saying this is the best practice or not even sane. :)
>
> LVS performs health checking via HTTP requests,
> with or without md5 checksum of the responses,
> or direct TCP connections to the port you specify (f.ex. for db servers).
>
>> I'm currently using mod_proxy on the web layer, and I know I can set 
>> that up to load balance requests to multiple app layer nodes, but to 
>> the best of my knowledge mod_proxy is not able to provide any quality 
>> of service.  So if a node in the app layer had a problem (or was shut 
>> down for maintenance) mod_proxy would be unaware of that and would 
>> still send requests to that node.
>
> That's where LVS is useful.
>
> LVS can do direct routing or tcp handoff IIRC, and we're using it.
> The client and servers talk directly to each other,
> without taking up too much resources on the LVS machine itself.
>
>> I'd rather not use a hardware load balancer here if I can avoid it.
>
> LVS usually runs on our older less powerful machines.
>
>> My second question deals with management of multiple mod_perl nodes:
>> At some point, if you have enough app layer nodes, managing the code 
>> deployments, apache configs and server restarts becomes very 
>> cumbersome if you're doing it all manually.
>
> We're using a simple but limited in-house tool that basically uses
> rsync, ssh, and keeps list of hosts w/ roles.
>
> Currently for a pilot project I used puppet for config management
> and fabric as "last mile" deployment tool. So far I'm happy
> with the result.
>
>> Are there any tools that can make these tasks easier or give me one 
>> management view?
>
> I don't know. Everything we've done is command line based,
> so it's not very friendly. Actually I'm currently looking into
> higher level tools to integrate what we've done.
>
> I also looked at ControlTier, but it feels too heavy for me.
> Needs its own (powerful) machine. I'd be glad to hear experiences on it.
>
>> Again, I'm used to working in web applications with a full blown app 
>> server. I love working with mod_perl, but I do find myself missing 
>> the advantages an app server gives me sometimes.
>
> I'm ignorant there. What advantages exactly?
>