1 Reply Latest reply: Jun 30, 2008 3:49 PM by 807574 RSS

    Can someone clear my understanding of HA Access Manager and Portal Server?

    JimKlimov
      I need some theoretical help, a simple yes/no might be enough :)

      The "Sun Java System Portal Server 7.1 Configuration Guide, Chapter 8. Installing and Configuring Portal Server 7.1 in High Availability Scenarios" (http://docs.sun.com/app/docs/doc/819-5025/gebvt?a=view), as well as some other documents from 2005Q1, 2005Q4 and BigAdmin, go into great lengths to explain HOW to set up Berkeley DB and Message Queue for Access Manager
      failover, and how to set up HADB for Portal Server failover.

      I didn't find any concise answer to the first question that popped up - WHY do we need two HA solutions just for sessions, beside clustering in the Application or Web Servers and loadbalancing? Actually, I'm not even certain whether we do indeed need both of them (BDB/MQ + HADB).

      What makes my understanding more complicated, the referenced document describes how to check Portal Session failover with BDB/MQ Access Manager cluster, and then goes on explaining how to set up HADB for Portal failover.

      Actually, it does mention a clue - HADB takes care of portlet failover. Perhaps this is opposed to failover of simple portal channels like JSP pages, which can be achieved by BDB/MQ-enabled AM Server?

      After much reading and some thinking I decided (maybe erroneously), that for each product that Sun wrote (or bought and integrated) there are private methods for session failover, etc. which "just work" and should not be changed.

      And that to be certain, we do need to set up both (or more for other products) of these methods.

      And that these methods cover different niches and do not conflict.

      Can someone please state whether my conclusions are correct? (And include a small paragraph on this in a next edition of the Deployment Example or some other guide)?
        • 1. Re: Can someone clear my understanding of HA Access Manager and Portal Server?
          807574
          I can answer this one immediately, for others I may have to do some reading coz I didnt myself setup an HADB for JES pieces.

          Your Question:
          "I didn't find any concise answer to the first question that popped up - WHY do we need two HA solutions just for sessions, beside clustering in the Application or Web Servers and loadbalancing? Actually, I'm not even certain whether we do indeed need both of them (BDB/MQ + HADB)."

          Application Server Clusters group 2 or more JVMs into a set and when an Applicaiton is deployed the underlying framework can generate a Routing Table that contains mappings for URI -> Clustered-Transports {jvm1,jvm2...}. This routing table can be used by the WebServer Plugin to intelligently route and hence Spray load across multiple JVMs (with other goodies such as Sticky Routing, load Balancing, Failover etc.,). This only solves the problem of how to Route User's request across xle JVMs.
          1. Suppose UserA was routed to JVM1 and he got a session going there. For some reason JVM1 crashes.
          2. UserA's N+1th request will go to the webserver plugin, plugin looks at the JSESSONID(or something similar) cookie and its value for clues on which JVM user was sent originally to.
          3.It will detect that it was JVM1
          4. Then it checks its internal state table for whether JVM1 was last "online" or not. If it is online, it would route it back to JVM1 (sticky), else it will pick the nexat available JVM in the set.
          5. Say UserA's N+1th request goes to JVM5. JVM5 will accept the request but has no clue where is the user's session.

          User's session is stored as HTTP Session object in the JVM's session manager. Each JVM has its own Session cache. When you cluster JVMs you dont always get Session-cache-clustering. IBM's WebSphere allows Memory-Memory replication of Sessions which solves this problem. SUN's ApplServer doesnot have this.

          So to propagate SessionState/Cache Application Servers use an external DB (SessionDB) where all sessions are committed and all changes to user's session states are regularly updated. This way when the request is routed to some other JVM it will check its inmemory cache if its missing it goes to the SessionDB to recover the Session.

          Now I am not sure why SUN has BDB/MQ & HADB in the docs. As I understand HADB setuphas various pieces:
          1. Install the DB driver on each of the Application Server installs.
          2. Create a DataSource in each of the JVM's or at Domain to point to the HADB Instance.
          3. Configure the JVM's session manager to use a DataSource to store the Sessions.

          If the DB is on a 3rd party box, then you dont need MQ (for example Oracle on a DB Server). But if DB is running on the same box as the ApplicationServer then you need to create a local DB instance on each AS node and setup some kind of change replication (Clustered DB) between DB instances. This is where MQ will come into picture. Each ASNode will update its local DB with its session updates. MQ link between DB instances will replicate changes among themselves. Hence if you loose a Host, though you will loose an ASNode + DB instance on it, you wont loose the SessionDB as it was replicated and was kept insync on the other DB instance.

          HTH
          Dexthor.