-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Duffey, Kevin
Sent: Monday, July 16, 2001 1:35 PM
To: Orion-Interest
Subject: RE: Clustering..
Thanks for the reply.
> 1. clustering only handles http session data. sfsb's will not
> be replicated.
I thought that the entire application context was replicated? So anything
set to Application scope (beans, etc) is NOT replicated? Is that the way it
is supposed to be..or just a bug/enhancement for Orion team to work on?
ew> I believe only the session context is replicated, but you will notice
that if you don't have a Serializable object, the server will throw an
error. I don't think the application context is replicated...since each
server has its own application context. If you fall over to another server,
you get that servers application context...otherwise all of the other
applications would have problems. This shouldn't be a problem, since usually
the app context is the same on each server in a cluster.
> 2. Although rmi can be clustered and you can get fail-over
> for ejb's, the
> ejb's are not load-balanced.
Not sure if I understand..I thought load balancing was done via a hardware
load balancer? In other words, wouldn't you have a setup like a firewall
that feeds to a load-balancer that then feeds to one (or more) islands, each
having one (or more) servers running EJB? The front-end cluster would access
this single fire-wall IP (via JNDI when looking up EJBs), which would follow
the flow to the ejb cluster. When you are talking about clustering EJB's
(load balancing them), how have you done this, or how is it normally done?
Again..i would think the identical hardware to load-balance the front-end
cluster would be in place for the EJB tier..including a firewall since EJB's
may be directly accessed via WAN clients, or from Web Services?
ew> you can use hardware or the software loadbalancer. The ejb's have
nothing to do with the http loadbalancing. That the ejb's happen to be on
the same servers is not actually garanteed unless you plan it that way. You
can use remote ejb's from other servers on other machines. I mean, that's
the whole point of ejb's. One ejb pseudo loadbalancing technique is to set
the maximum number of beans on any one server, and then cluster the rmi. As
one server fills up, another server will kick-in to server ejb's. This isn't
really loadbalancing, though, but it is fail-over.
> 3. careful specification of the server is required, for example, the
> web-apps must be in the config/application.xml.
This is new to me. I haven't read any recent clustering docs, but the
original clustering doc (not even sure if Orion ever posted it, or if it is
on orionsupport.com or not) had specific settings in web.xml (setting the
clusterable option), and I think in orion-web.xml and the .xml config file
under /orion/config for the specific application to be clustered. Has this
all changed?
ew> if an application is not bound to the default application, you will need
a separate web-app tag in the config/application.xml file to make sure the
session data is clustered. The docs only cover clustering and loadbalancing
the default web site and anything bound to this app. Of course you can have
more than one web-app which is not bound to the default web site, but
another web-site.
> 4. ssl loadbalancing does not work and is broken.
I just mentioned this to our CTO. I think using a hardware SSL device
(whether as a separate linux box that handles the encoding/decoding, web
server that forwards all SSL on after encoding/decoding, or a stand-alone
hardware box that does this very fast (my personal favorite)) should take
care of this. For the mere $5K you pay for a box that can handle several
hundred SSL transactions per second, I think its worth the peace of mind it
gives you in not having to do any SSL coding tricks. I remember reading
something about how SSL sessions were getting lost. Don't recall what this
was about..but it makes me worry about moving to Orion (or OC4J) if SSL
doesn't fully work.
ew> proxy or hardware for the ssl acceleration is the way to go. Sonicwall
even has a hardware accelerator that looks like a network interface to your
server for $2500. SSL works fine on the server, its just the software
loadbalancer that doesn't work with ssl.
Maybe I am missing something..but I would think a good part of the appeal to
move to an App Server is for its clustering capabilities. Sure, you get
awesome web performance, simple setup and powerful features for a single
server/app server setup. But if your site grows, you are bound to require
clustering..aren't you? Or does everyone just add a new box and load-balance
via session/cookie keys to the specific one box with no fail-over of the
session? Alot of sites, like google.com and the bunch must have tons of web
servers. Are they not set up in a cluster? I mean..search engines probably
aren't..they just have to handle major hits and database access for
searches. But transaction based sites like online bank sites, e-commerce,
etc must use more than a single server AND preserve the sessions incase of
failure..don't they?
ew> oracle doesn't recommend using ssl at all with oc4j, because they want
to use their apache/proxy frontend.
Thanks again.
>
> regards,
>
> the elephantwalker
>
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Duffey, Kevin
> Sent: Monday, July 16, 2001 12:39 PM
> To: Orion-Interest
> Subject: Clustering..
>
>
> Hi all,
>
> I know how to cluster Orion..after all, its pretty easy. What
> I want to know
> from someone who knows..is if in the 1.5.2 version all the
> bugs (if there
> were actually any) are worked out. Does Orion cluster with no
> problems? Does
> session fail-over and application context fail-over work
> without a hitch
> (providing all objects in the session and/or context are
> serializable)? If
> you have two machines in an island, and the session begins on
> one..does it
> automatically "copy" any session info to the other box for
> you? If you shut
> that box off, and all requests go to the 2nd box, does the
> session still
> exist with all objects still in memory?
>
> I take it each and every request on a clustered box requires
> the session to
> be duplicated exactly as is to the other machine? If this is
> the case, at
> what "rate" does Orion copy out the session and anything else
> to another
> server in the island (or to each and every server in the
> island)? How does
> this affect performance as compared to using just a single box without
> clustering..is it 2 to 3 times slower because of not only copying its
> session to one or more boxes, but also having to deal with
> "merging" other
> boxes context/session information into its own? Or does a
> cluster simply
> create the objects and session stuff on each box as its
> generated (thus..its
> not some background thread that copies session info when it
> has time to
> other boxes)?
>
> Is it equally good at clustering on the EJB tier (so
> scalability on the EJB
> tier or the front-end WEB tier is equally as easy)?
>
>
> Thanks.
>
