In almost all cases HTTP servers of one sort or another (Apache, IIS, Netscape) are used as a front end to the cluster. A client process is not required to know what server it is requesting a resource fromit sends all requests to the DNS name or IP on the front end. If the request is for a static Web page or perhaps a non-Java CGI script, it is handled by the HTTP server. All other requests are passed on to the WebLogic Server members of the cluster. The HTTP servers pass requests on to the WebLogic servers in round- robin orderweighted algorithms are not supported. HTTP Session State ReplicationThe other important feature of clustered HTTP servers is that they all support session state replication. This is a high-availability feature of WebLogic clusters. In session state replication, the session state object of an HTTP server is replicated in the memory of one or more other servers in the cluster. If the first server fails, the task it was performing at the time of failure can be completed by one of the servers containing the replica. In order to use HTTP session state replication, all the HTTP servers in a cluster must be configured identically. Replication GroupsBy default, when replication is enabled, the server will attempt to duplicate its session states on some other member of the cluster. For small clusters (< 3 nodes) this is adequate. In larger clusters, however, some machines may be more desirable as backup servers than others. It is possible to configure primary and secondary replication groups to reflect these choices. To configure a replication group :
Note that before any cluster- related configuration changes take effect, the servers involved must be restarted. For this reason, it is recommended that your Administration server not participate in any replication groups or, indeed, service any client requests. HTTP session state and session state for stateful EJBs may be persisted in a variety of ways:
See Chapter 5 for more detailed discussion of the process of configuring HTTP servers. |