Managing WebLogic 11g Clusters

<< Previous

* Applications are deployed using the two phase deployment (TPD) approach:
– phase 1: distribute components/modules to all server instances
– phase 2: if phase 1 succeed, applications are deployed to allow client access
* Relaxed deployment mode:
– if one or more server instances are not available/reachable (these servers are called partitioned server), deployment continues to available server instances
– when partitioned servers become reachable, deployment starts on these servers (potential performance hit)
* Relaxed deployment mode can be disabled by setting enforceClusterConstraints to true with weblogic.Deployer
* Production redeployment in a cluster
– may result in both older and new versions running simultaneously
– older version always fails to same older version (fail if none exists)

* Supports:
– in-memory replication: each user session always exists in two servers (primary and secondary servers)
– JDBC persistence
– file persistence
* Configured within each web application
– in weblogic.xml: session-descriptor
* All web servers should have identical configuration
* WLS also supports AsyncRep to improve cluster performance

* WLS supports in memory replication for:
– HttpSession objects
– Statefull session beans
* Session objects exist only on two servers: primary server and secondary server
* Primary/secondary servers are determined by replication group and machine definition
* Clients must access the cluster using one of the following:
– WLS aware hardware load balancer: LB must support SSL persistence and passive cookie persistence to allow cookie persistence between client and WLS
– OHS with mod_wl_ohs
– One or more web servers with WebLogic proxy plug-ins configured identically (WebLogic proxy plug-ins only supports round robin load balancing)
– Oracle WebLogic Server configured with HTTPClusterServlet

* Logical grouping of related servers in a cluster
* Used to decide where to put in-memory backup objects (preferred replication group)
* Better than using machines since one physical computer may have multiple IP addresses (machines)

* Use weblogic.xml:

<session-descriptor>
  <persistent-store-type>replicated</persistent-store-type>
</session-descriptor>

* persistent-store-type:
– memory: Disables persistent session storage.
– replicated: Same as memory, but session data is replicated across the clustered servers.
– replicated_if_clustered: If the Web application is deployed on a clustered server, the in-effect persistent-store-type will be replicated. Otherwise, memory is the default.
– async-replicated: Enables asynchronous session replication in an application or web application. See Configuring Session Persistence.
– async-replicated-if-clustered: Enables asynchronous session replication in an application or web application when deployed to a cluster environment. If deployed to a single server environment, then the – – session persistence/replication defaults to in-memory. This allows testing on a single server without deployment errors.
– file: Uses file-based persistence (See also persistent-store-dir).
– async-jdbc: Enables asynchronous JDBC persistence for HTTP sessions in an application or web application. See Configuring Session Persistence.
– jdbc: Uses a database to store persistent sessions. (see also persistent-store-pool).
– cookie: All session data is stored in a cookie in the user’s browser.

* Advantages:
– No primary/secondary needed.
– All members of a cluster have access to any client’s session data
* Disadvantages:
– Performance hit

* Create required wl_servlet_sessions table in database:

CREATE TABLE wl_servlet_sessions ( 
wl_id VARCHAR2(100) NOT NULL,
wl_context_path VARCHAR2(100) NOT NULL, 
wl_is_new CHAR(1),
wl_create_time NUMBER(20), 
wl_is_valid CHAR(1), 
wl_session_values LONG RAW, 
wl_access_time NUMBER(20),
wl_max_inactive_interval
INTEGER, PRIMARY KEY (wl_id, wl_context_path) );

* Create JDBC data source that has read/write privileges to the database
* Configure weblogic.xml:

<session-descriptor>
  <persistent-store-type>jdbc</persistent-store-type>
  <persistent-store-pool>MyDataSource</persistent-store-pool>
</session-descriptor>

* Create a folder shared by all servers on the cluster on a HA file system
* Assign read/write privileges to the folder
* Configure weblogic.xml

<session-descriptor>
  <persistent-store-type>file</persistent-store-type>
  <persistent-store-dir>/mnt/wls_share</persistent-store-dir>
</session-descriptor>

* Create WLS machines
* Use Replication Groups
* Choose replication strategy
* Use ServerDebugConfig MBean to debug session replication
* Ensure objects are serializable

* Achieved via replica-aware stubs
* Replica-aware stubs are generated at compile time for clusterable EJBs
* Supported algorithms:
– round robin
– weight based
– random
– parameter based (custom programming)
* Also uses server affinity so that calls to objects remain with the same server

* For EJB 2, configure in weblogic-ejb-jar.xml or weblogic-cmp-rdbms-jar.xml:

<stateless-clustering>
  <stateless-bean-is-clusterable>True</stateless-bean-is-clusterable>
  <stateless-bean-load-algorithm>random</stateless-bean-load-algorithm>
</stateless-clustering>

* For pure EJB 3, use deployment plan
* For EJB 3 that supports backward compatibility with EJB 2, configure like EJB 2
* Stateless session bean in weblogic-ejb-jar.xml

<stateless-session-descriptor>
  <!–- Other Tags As Appropriate Here… -->
  <stateless-clustering>
    <stateless-bean-is-clusterable>True</stateless-bean-is-clusterable>
    <stateless-bean-load-algorithm>random</stateless-bean-load-algorithm>
    <!–- Other Tags As Appropriate Here… -->
  </stateless-clustering>

* Stateful session bean in weblogic-ejb-jar.xml

<stateful-session-descriptor>
  <stateful-session-clustering>
    <home-is-clusterable>true</home-is-clusterable>
    <home-load-algorithm>random</home-load-algorithm>
    ....
    <!-- None for not to replicate -->
    <replication-type>InMemory</replication-type>
  </stateful-session-clustering>
</stateful-session-descriptor>

* Entity bean in weblogic-ejb-jar.xml

<entity-clustering>
  <home-is-clusterable>True</home-is-clusterable>
  <home-load-algorithm>random</home-load-algorithm>
  <home-call-router-class-name>beanRouter</home-call-router-class-name>
</entity-clustering>

* Configures default EJB cluster settings for the domain

* Set pool and cache sizes accordingly
* Cache size affects all nodes in the cluster
* Mark bean as idempotent at either bean or method level in weblogic-ejb-jar.xml
– bean level:

<stateless-bean-methods-are-idempotent>true</stateless-bean-methods-are-idempotent>

– method level:

<dempotent-methods>true</dempotent-methods>

Next >>

[mv_include id=’3268′]