session clustering

web 2007. 8. 22. 19:56

Session clustering에 대한 조사입니다.

 

Session clusteringWAS에서 대부분 제공되고 있나 봅니다. 톰캣, 웹 스피어 등등

 

Session clustering의 특징을 요약해 보겠습니다.

-       여러대의 JVM에서 돌아가는 서버들이 하나의 공통된 HTTP Session table을 사용한다.

-       Load balancing도 같이 된다. (의미 때문에)

-       Server 2.2 스펙에서는 하나의 세션에 대해서 여러 리쿼스트가 여러 jvm에 있어서는 안된다고 되어 있어서 각 WAS별로 솔루션을 제공하고 있다.

n  ) websphere에서는 클러스터내의 한 서버에서 session 처리가 실패하면 클러스트터내의 다른 서버로  session table을 보내고, session처리가 가능하게 하도록 함.

 

http://publib.boulder.ibm.com/infocenter/wasinfo/v4r0/index.jsp?topic=/com.ibm.websphere.v4.doc/wasa_content/001102.html

0.11.2: What is session clustering?

The Session Manager session support allows multiple application server instances to share a common pool of sessions, known as a session cluster. A session cluster is the binding of the session to more than one active application server Java virtual machine (JVM) sharing a common HTTP session table.

The implementation of clustering in IBM WebSphere Application Server allows failover. This preserves session data integrity and the common pool of sessions in the event of a system failure in one or more of the clustered JVMs running servlets within a group of servers.

The session clustering implementation also allows load balancing, whereby the session workload is distributed among the JVMs that comprise the cluster.

Session clustering requires an affinity mechanism so that all requests for a particular session are directed to the same Java Virtual Machine (JVM) in the cluster. This conforms to the Servlet 2.2 Specification in that multiple requests for a session cannot coexist in multiple JVMs. One such solution provided by IBM WebSphere Application Server is Session Affinity in a server group; this solution is available as part of the WebSphere plug-ins for Web servers. If one of the servers in the cluster fails, it is possible for the request to be rerouted to another server in the cluster. The new server can access session data from the common SESSIONS table. This is transparent to the servlet, browser, and user.

The same Web application must be present on each of the servers that can access the session. This can be accomplished by installing a Web module into a server group. Each of the servers in the group can then access the Web application; if a persistence mechanism is used, sessions can fail over between servers.

Manually cloned environments (that is, those not in WebSphere server groups) can share session data between servers if the identical Web application is installed with the same virtual host name on each of the servers. These environments also require an affinity mechanism to ensure that the session is active in only one JVM at any given time.

If the JVM fails during the writing of session information in the session database, the update to the database does not get committed. Still, the common pool of sessions continues to function, including the session being processed at the time of failure.

For non-catastrophic failures (such as when the JVM remains functional), any session changes that cannot be completed are rolled back. The session reverts to its state prior to the start of the persistence operation. If instead the write operation is completed successfully and the changes are committed, the session is still accessible, regardless of the failure.

 

<톰캣 5>

http://tomcat.apache.org/tomcat-5.0-doc/cluster-howto.html

 

serialization을 이용하여 클러스터링을 할 수 있다.

·         All your session attributes must implement java.io.Serializable

·         Uncomment the Cluster element in server.xml

·         Uncomment the Valve(ReplicationValve) element in server.xml

·         If your Tomcat instances are running on the same machine, make sure the tcpListenPort attribute is unique for each instance.

·         Make sure your web.xml has the <distributable/> element

Cluster Architecture

Component Levels:

        Server

          |

        Service

          |

        Engine

       /     \

   Cluster ReplicationValve

      |

   Manager

      |

  Session

 

 

TODO

현재 이 것을 사용할 여부를 테스트를 해봐야 한다.

 

쿠키 베이스 단위로 우리는 진행중이지만, 클러스터링을 통해서 jvm단에서 공유하는 common session table을 넘겨주고 처리하는 작업이 부하를 많이 줄 수 있는 상황인데..

좀 더 생각해보면, 중간에 cache server를 두어서 common session Table을 여러 jvm에서 같이 보는 것은 어떨까??

그러면, 쿠키 베이스로 가지 않고도 할 수 있지 않을까??

Posted by '김용환'
,