On Jul 25, 2007, at 9:30 AM, Mike Wynholds wrote:
> well, I did come up with a solution, however it is Resin-specific
> and requires some client-side code at all login points (ie: there
> is a customer login implemented in Flex as well as an
> administrative login implemented in HTML).
>
> I set up apache for the web-tier and resin as the app-tier,
> connected by mod_caucho. I have an idea of the overall systems
> architecture, but for this discussion we just assume that there is
> some farm of apache servers that are available under a single URL.
>
> Resin offers a way to specify a preferred app-tier server in the
> cluster by accessing the web-tier and passing in a pre-fab
> jsessionid, utilizing the Resin-specific algorithm of starting it
> with an "a", "b", "c", etc. for example, if I wanted the second
> server listed in the cluster in resin.conf, I request the following:
>
> http://www.myserver.com;jsessionid=b
I'm finally getting a chance to look at this.
Does the project selection occur before you have a session?
In other words, would something like the following work?
request.setAttribute("caucho.session-server", "b");
session = request.getSession(true);
If the session is new, then it will be assigned an ownership of
server "b", even if that's a totally different machine than the
current server. The next request will be directed to server "b",
which will be the same as the pinned data.
-- Scott
>
> now, if there is no current session, mod_caucho will do its best to
> point the web-tier to the second server in the app-tier cluster.
> it will still, however, fall back to the other clustered servers if
> B is down. this is exactly what I want.
>
> the downside to this solution is that my client code has to do some
> work to make this happen. as a user logs in, the client must a)
> clear the session, and b) figure out the appropriate URL (ie:
> jsessionid prefix) to use and switcheroo it in as the user logs in,
> based on the project number entered in to the login form.
>
> I actually have a server-side servlet that does the logic, so I
> just need a way to call it easily. basically, in Flex I just use
> the standard Flash mx:HTTPService, which is easy, and in HTML I
> just use AJAX. so it's not too bad, but it would be nice if it was
> even more "behind the scenes". it can't be 100% behind the scenes,
> tho. I would at least need a convention of putting the project
> number in the session or in the login URL under a specific name, or
> something like that, even if I could do custom load balancing login
> on a hardware load-balancer.
>
> anyway, so far so good.
>
> any suggestions for improvements would be definitely appreciated!
>
> ..mike..
>
> .....
> Michael Wynholds
> President
> Carbon Five, Inc.
> 310 821 7125 x13
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:resin-interest-
> [EMAIL PROTECTED] On Behalf Of Jay Ballinger
> Sent: Wednesday, July 25, 2007 8:43 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Resin / Apache load balancing with
> customResin server weighting (for data segmentation purposes)
>
> Mike,
>
> This sounds like a perfect use for a hardware load-balancer. A
> hardware load-balancer can create the affinity for a particular server
> much like you describe - except for the choosing of a server based on
> your algorithm, that is.
>
> Most hardware solutions implement some sort of persistence feature
> where, once a load-balancing decision has been made by the device, it
> will try to persist that same 'user' to that same server for a
> configurable amount of time. We use this to keep a user's access and
> application log on one server versus having to hunt around all the
> servers to piece their session together.
>
> If you are trying to create logic that says, "All project 'A' users go
> on server 'X'," I see that as a big challenge for the chicken-egg
> scenario you describe - the user already has an affinity to a server
> before you know the user or the project. However, there are some
> pretty slick hardware load-balancers out there that can use
> cookie-driven values. Check out the lineup from F5 - specifically
> their Big-IP Local Traffic Managers.
>
> Of course, you could have a farm of login servers that simply takes
> the login info and then redirects the user to a different farm of
> servers based on the project info.
>
> Good luck, and let us know what you come up with.
>
> + jay
>
> On 7/11/07, Mike Wynholds <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>> I have a somewhat complex load balancing scenario that I wish to
>> accomplish.
>> From my investigation it seems that it's *probably* possible but
>> I haven't
>> gotten it to work yet. Here is the scenario:
>>
>>
>>
>> I have a web app running on Resin 3.1.1 with Apache 2.2 in front
>> of it. I
>> want to have multiple Resin servers in a cluster. I may have
>> multiple
>> Apache servers as well, but I don't think that's important. If I
>> do I will
>> have a hardware load-balancer in front of that.
>>
>>
>>
>> I want to achieve both failover and server scalability with my
>> systems
>> architecture. I think I can utilize a clustering solution to
>> handle this.
>> I will need to cluster both Resin sessions as well as a number of
>> memory/disk caches using the distributed mode of EhCache (or possible
>> JBossCache). So far the Resin session clustering is working
>> fine. However,
>> for efficiency I really also want to segment my data between
>> users, in order
>> to reduce either a) the amount of cache replication (if I use cache
>> replication) or b) the amount of cache misses (if I use cache
>> invalidation)
>> in EhCache.
>>
>>
>>
>> When people come to the site, they are given a login page
>> immediately.
>> There are two entry points: one is HTML-based and one is Flash/
>> Flex-based.
>> Either way the user is prompted to log in with a username,
>> password and a
>> project number. I want to pin all users logged in to a particular
>> project
>> to the same backend server so that the EhCache can be used as
>> efficiently as
>> possible.
>>
>>
>>
>> But while I say I want to "pin" specific users to specific backend
>> servers,
>> I really also want the failover capability built in to load-
>> balancers. So
>> what I *really* want is a way to suggest to the load balancer
>> which server
>> to prefer, but allow it to fall back in the case of a server being
>> down. My
>> algorithm for choosing a server to suggest is simple: I just hash the
>> project number, mod by the amount of servers, and choose that
>> one. Not
>> smart, but for now that's fine.
>>
>>
>>
>> I feel like I will want to use the Resin load balancing features
>> (although I
>> am open to other suggestions). From the docs it seems like there
>> may be a
>> way to do it. I have spent a few hours on this and am not seeing
>> a very
>> clear solution. My main theoretical issue is that when the user
>> hits the
>> login page a session is created. There is no way to know which
>> project
>> number the user will then enter, and therefore which server to try
>> to pin
>> him too. But then if he enters a project number, Resin already
>> has him
>> pinned to a server by the jssesionid.
>>
>>
>>
>> Is there a way to tell Resin to keep the session but now house it
>> on a
>> different server?
>>
>>
>>
>> I think the logic of project number à server needs to be in the app
>> somewhere (ideally the server side, not the Flash side). Can I
>> set a cookie
>> or something that can be sniffed by Resin's load balancing
>> capabilities that
>> will determine the suggested server to pin to?
>>
>>
>>
>> I can kind of see the light at the end of the tunnel but haven't
>> been able
>> to come up with even a best theoretical approach to this problem.
>> There is
>> just too much about Resin load balancing, mod_caucho, hardware load
>> balancers and the such that I am not intimately familiar with, and
>> I don't
>> want to reinvent anything that already exists and works well.
>>
>>
>>
>> Thanks for any suggestions.
>>
>> ..mike..
>>
>>
>>
>> .....
>>
>> Michael Wynholds
>>
>> President
>>
>> Carbon Five, Inc.
>>
>> 310 821 7125 x13
>>
>> [EMAIL PROTECTED]
>>
>>
>> _______________________________________________
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>
>>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
