AFAIK, these accelerators handle the front end, and the backend doesn't use
ssl. You can also have ssl throughout, but ...I mean, what's the point of
having the accelerator if you don't use it. You may be able to "tunnel"
through the accelerator or proxy, or something.
I will check out the docs to see if you can proxy the certificate. This is
certainly necessary for login credentials if you use a client certificate
for a login.
regards,
the elephantwalker
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ismael
Sent: Wednesday, July 18, 2001 12:37 AM
To: Orion-Interest
Subject: RE: Clustering..
When you use a SSL hardware accelerator, are you able to retrieve the
digital certificate that the user uses from your application on Orion?.
Is there a way to retrieve the digital certificate while usin a SSL
hardware accelerator?
At 14:11 16/07/2001 -0700, you wrote:
>-----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.
> >
