While using DNS may well be a naive, I think it is more naive to
think that user space code running on a general purpose computer is
a good solution if you are concerned about load and/or failover.
If you really want performance and reliability, then firmware is the
solution for you and the 25K will do a little to help my Cisco shares :-)
However, I do think we need a reasonable solution that works as a
reasonable introduction to loadbalancing and failover.
If my understanding of the clustering / session manager is correct, it does
not really matter if sessions are not 100% sticky. The clustering stuff will
cope, but it is just more efficient if it does not need to move everything to
a new node.
So this is the approach that I would like to take for this:
+ Write it in java, because we want to be 100% pure. If that is not
fast enough - buy Cisco ( I will declare an interest here as Cisco are the
prime sponsor of Jetty development !-)
+ Use java.nio as:
* if you care about performance you should be using jdk1.4 anyway
* if you want one machine to handle more connections than the sum of
all your servers, then java.net.ServerSocket aint going to do the job!
* I want to play with nio before I write the NioListener for Jetty!
* Allow sticky sessions, sticky IP and sticky host options.
* If sticky sessions are used, or all new connections look for
"jsessionid=" in the first packet of the request and the response. If
found, associate the ID with the current connecton allocation.
* If sticky IP is set, use a hashmap of the source InetAddress to determine
the connection association.
* If sticky host option is set, use hashmap on InetAddress.getCanonicalHostName()
to determine the connection association.
* If multiple options are set, they are tried in the order they we defined
until an association is found.
* Stickyness applies to a listener, so you can have different settings for http and
https ports.
* If you have a new connection, an association to a server will be made via a
pluggable balance policy. The default will be round robin or least connections.
* If a connections are only re-associated as they break or fail to connect to
a server.
+ A failing server will continue to be tried for new connections according to the
balancing policy - so that it can come back into the fold.
A fancy balancing policy may wish to exclude a failed server for a period of
time, or until further notice.
+ At this stage, there will be no re-balancing of existing associations if the
load becomes asymmetric due to random chance (or any other reason).
How does that sound? It should at least be a start for load balancing and failover.
I should have something working like this within a day or a month (Now there
is a broad estimate for you). I'm happy to do this myself, but would also
appreciate a keen buddy on this once the skeleton is in place.
cheers
Bill Burke wrote:
> I was looking at the way Apache+Tomcat works. They use a protocol between
> themselves. Apache decrypts the SSL message and extracts "sticky" session
> information as well as SSL information and passes this over a load-balanced
> socket over a proprietary protocol to the Tomcat instance. The message
> contains the HTTP request as well as all the SSL information. Tomcat
> unpacks the message, creates an HttpRequest, and sends the request on their
> local "bus". I guess they call this a Tomcat Connector.
>
> ---
>
> Marc, I see no reason why you have to be separate from Apache. The issues
> here aren't trivial and they've already done all the work and they're
> open-source. Actually their license is much more liberal than LGPL. Plus
> for this kind of stuff you probably want something written in C for speed as
> Greg suggested. Jetty already leverages Jasper, why not mod_jk?
>
> ---
>
> As far as load-balancing based on client IP and AOL, it is even worse than
> you think. Supposedly, a client's IP can change in the middle of the
> session.(I said supposedly remember ;) You acutally have to stick on a mask
> of the IP. Sure, client IP isn't the best way, but it was the only thing us
> ignorant bloaks knew at the time :)
>
>
>>-----Original Message-----
>>From: Greg Wilkins [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, March 07, 2002 6:05 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: [jetty-discuss] HTTP loadbalancing
>>
>>
>>
>>Chris,
>>
>>Your comments are correct (and user are the only ones who should post
>>to jetty-discuss!-)
>>
>>There are two common solutions:
>>
>>As the load balancer is in your organization then you can give it
>>the server certificate and it can terminate the SSL connection.
>>The forwarded connection is then done using standard HTTP or some
>>other protocol. It is not over the internet, so it is moderately
>>secure (depending on the organizations network setup).
>>
>>The main problem with this setup, is that the server knows nothing
>>about the SSL side of things. Thus the container rewrites URLs as
>>http: rather than https:
>>
>>The other solution is to have the balancer work at the TCP/IP level,
>>so that it does not decrypt the packet. As it cannot crack open
>>the packets, it must use some other way of making sessions sticky.
>>The common way to do this is a hash on the client IP address, so
>>all connections from the same IP go to the same server.
>>
>>The problem with this one is that all AOL users may share the same
>>HTTP proxy - thus the same source IP address.
>>
>>But then there is no such thing as a silver bullet!
>>
>>I'm about halfway through implementing the first solution - but it
>>is complex and will take time.
>>
>>The second solution is easier and I'll try to find the day or two
>>that will be needed to implement it. I already have most of the
>>required infrastructure in the JettyExtra InetGateway class.
>>
>>cheers
>>
>>
>>
>>
>>Chris Haynes wrote:
>>
>>>"Bill Burke" <[EMAIL PROTECTED]> wrote:
>>>...
>>>
>>>
>>>>Especially for HTTPs, since you have to decrypt the message to get
>>>>
>>>>
>>>the
>>>
>>>
>>>>session cookie.
>>>>
>>>>
>>>
>>>Forgive a mere user for intruding on jetty-discuss, but isn't there
>>>something architecturally awry here.
>>>
>>>As I understand HTTPS, there can only be one server-end to the
>>>SSL/TLS.
>>>
>>>Either the server-end is at the 'proxy' (with it holding the host
>>>keystore etc.), or the proxy can't decrypt.
>>>
>>>If the proxy acts as the server-end, then how is the Servlet system at
>>>the 'actual' server to supply the 'isSecure()' value to the Servlet?
>>>
>>>
>>>Chris Haynes
>>>
>>>
>>>
>>>For the latest information about Jetty, please see
>>>
> http://jetty.mortbay.org
>
>>To alter your subscription to this list goto
>>
> http://groups.yahoo.com/group/jetty-discuss
>
>>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>
>>
>>
>
>
>
> --
> Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
> Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
> http://www.mortbay.com AU Phone: +61-(0)2 98107029
>
>
>
> For the latest information about Jetty, please see http://jetty.mortbay.org
>
> To alter your subscription to this list goto
> http://groups.yahoo.com/group/jetty-discuss
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
> ------------------------ Yahoo! Groups Sponsor ---------------------~-->
> Access Your PC from Anywhere
> Full setup in 2 minutes! - Free Download
> http://us.click.yahoo.com/Y8IZpD/2XkDAA/yigFAA/CefplB/TM
> ---------------------------------------------------------------------~->
>
> For the latest information about Jetty, please see http://jetty.mortbay.org
>
> To alter your subscription to this list goto
>http://groups.yahoo.com/group/jetty-discuss
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
