Single-point failure of proxy server??

Question

Three questions regarding using the proxy server for WLS clustering:
          1. What happen if the proxy server fails? The entire cluster won't be
          accessible?
          If so, is there a implication of having "meta-configuration" for
          proxy server failover?
          2. Does the term "in-memory persistence" clustering (over JDBC) does
          imply
          the session data is "shared" in memory between the primary &
          secondary
          servers, or they are compleleted replicated in each server??
          3. How bad is it in terms of performance using the JDBC session
          persistence
          and the in-memory replication? Any one has experimented it??
          Any thoughts and comments are helpful and appreciated??
          Frank Wang
          

Answer 1

Frank,
          If using File/JDBC persistence, it doesn't matter which server gets the request
          because all servers have access to every session's data.
          When you assign a hostname "to the cluster" and map that hostname to the IP
          address of each server in the cluster, this sets up something called DNS
          round-robining. What this does is round-robin which IP address is returned when
          the cluster hostname is resolved. Unfortunately, DNS is not very good at
          detecting failed machines so it may continue to hand out IP addresses of failed
          machines.
          A better way to do this is with a hardware router that is made for this purpose
          (e.g., LocalDirector). The router can detect a failed machine and redirect the
          request to another machine in the cluster. Unlike the in-memory replication
          case, it doesn't matter which server gets each request so no proxy is required.
          Hope this helps,
          Robert
          Frank Wagn wrote:
          > Hi, Robert,
          >
          > Thank you for the answers !!
          >
          > It is still not very clear to me when using the File/JDBC session
          > persistence.
          > Since there is no such a "coordinating" proxy server who knows how to
          > load balancing among the servers in the cluster (based on the specified
          > algorithm in the proxy server properties file), how does the load balancing
          > (and failover) work, when the requests are directed to a "mask" of cluster IP
          >
          > (virtual proxy) which in terms broadcast to all the servers??
          >
          > Frank
          >
          > Robert Patrick wrote:
          >
          > > Hi Frank,
          > >
          > > Frank Wang wrote:
          > >
          > > > Three questions regarding using the proxy server for WLS clustering:
          > > >
          > > > 1. What happen if the proxy server fails? The entire cluster won't be
          > > > accessible?
          > > > If so, is there a implication of having "meta-configuration" for
          > > > proxy server failover?
          > >
          > > If you have a single proxy server, this is correct in that it is a single
          > > point of failure. A common configuration is to use multiple proxy
          > > servers (with something like LocalDirector sitting in front to do routing
          > > and load balancing to the proxy servers) that proxy requests to a cluster
          > > of WLS servers.
          > >
          > > > 2. Does the term "in-memory persistence" clustering (over JDBC) does
          > > > imply
          > > > the session data is "shared" in memory between the primary &
          > > > secondary
          > > > servers, or they are compleleted replicated in each server??
          > >
          > > HttpSession state can be shared across the servers in a cluster in one of
          > > three ways.
          > >
          > > 1.) Using File-based persistence (i.e., serialization) - This requires a
          > > shared file system across all of the servers in the cluster. In this
          > > configuration, all servers are equal and can access the session state.
          > > As you might imagine, this approach is rather expensive since file I/O is
          > > involved.
          > >
          > > 2.) Using JDBC-based persistence - This requires that all servers in the
          > > cluster be configured with the same JDBC connection pool. As with method
          > > 1, all servers are equal and can access the session state. As you might
          > > imagine, this approach is rather expensive since database I/O is
          > > involved.
          > >
          > > 3.) In-memory replication (not really persistence) - This scheme uses a
          > > primary-secondary replication scheme so that each session object is kept
          > > on only two machines in the cluster (which two machines vary depending on
          > > the particular session instance). In this scheme, we need a proxy server
          > > sitting in front of the cluster that can route the requests to the server
          > > with the primary copy of the session for each request (or to the
          > > secondary if the primary has failed). The location information is
          > > encoded in the session id and the proxy knows how to decode this
          > > information and route the requests accordingly (because the proxy is
          > > using code supplied by BEA -- the NSAPI or ISAPI plugins or the
          > > HttpClusterServlet).
          > >
          > > > 3. How bad is it in terms of performance using the JDBC session
          > > > persistence
          > > > and the in-memory replication? Any one has experimented it??
          > >
          > > JDBC session persistence performance is highly dependent on the
          > > underlying DBMS. In my experience in doing benchmarks with WLS,
          > > in-memory replication (of a reasonably small amount of session data) does
          > > not add any measurable overhead. Of course, the key words here are
          > > "reasonably small amount of session data". The more data you stuff into
          > > the HttpSession, the more data that needs to be serialized between
          > > servers, more performance will be impacted.
          > >
          > > Just my two cents,
          > > Robert