What is session?
————————–
* A Session is a series of requests to a servlet, originating from the same user at the same browser
How session works?
——————————
* session ID Allows to keep track of individual users
* Session ID generated on first request and send back to browser with first response.
* Session ID then arrives with each subsequent request
* Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs
Distributed sessions
——————————
Session management can store session-related information in …
* In application server memory (the default). This storage options is knows as in-memory sessions.
* In a database. This storage option is known as database persistent sessions.
* In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.
* Distributed sessions are essential for using HTTP sessions for the failover facility
* Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
* On the failure of cluster member, plug-in routes requests to other members
* When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory).
Memory-Memory replication
—————————————–
* In Memory-to-Memory session replication, session data from owner server replicates (copies) in one or more other application server using Data Replication Service
=>Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. You can configure DRS by creating a replication domain. Replication Domain can be created either manually from Environment page of admin console or automatically at cluster create time.
* This requires creation of a data replication service instance in owner server that communicates to other data replication service instances in remote application servers
* This can be achieved by creating a replication domain and configuring the session manager of cluster members to use memory-to-memory replication.
* A server can run in one of the following three modes:
* Client mode: server only sends copies of sessions it owns
* Server mode: server only stores backup copies of other servers
* Both mode: server sends copies of session it owns and acts as a backup table for sessions owned by other application server
* Two different topologies are possible based on above three modes
* Peer-to-Peer topology
* Client/Server topology
=> Peer-to-Peer topology
* Each server stores a session in it’s own memory and also stores sessions to, and retrieves from, other application servers.
* Each application server acts as client by retrieving session from other servers and acts as server by providing sessions to other application servers
* This is the default configuration and each application server can:
* Host the Web Application leveraging the HTTP Session
* Send Changes to the HTTP Session that it owns
* Receive backup copies of the HTTP session from all of the other servers in the cluster
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. Select the replication domain created in first step
4. Select “Both Client and Server” as replication mode
5. Click Ok and Save to master configuration
6. Repeat above steps for all the cluster members
7. Once done, restart the cluster
=>Advantages
* No additional processes and products are required to avoid a single point of failure.
* Reduce the time and cost required to configure and maintain additional processes or products
=>Disadvantages
* It can consume large amounts of memory with many users. This can cause a performance impact
* Does not provide stable configuration for cluster with only 2 members, because of two way replication?
=>Client/Server topology
* Application Servers act as either a replication Client or a Server
* Replication servers store sessions in there own memory and provide session info to clients.
* Dedicated replication servers just store session but do not respond to users’ requests
* Client application servers send session information to replication servers and retrieve as needed. Clients respond to user requests
* Application servers configured as Server can not host any applications. They act as pure data store for backup sessions and receive updates from Clients
* Backup data is isolated into a separate JVM
* Client replicas will contain only local session data
* Application servers configured as Servers must be started before starting Clients
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. configure cluster1 members as client
4. configure cluster2 members as Server
5. start cluster2 first and then cluster1
=>Advantages
* Clearly distinguishes the role of client and server.
* Reduces the consumption of memory on each application server
* Better performance
* Allows recycle of a backup server without affecting the servers running applications
* Better choice if your hardware varies across the cluster
=>Disadvantages
* Additional application servers have to be configured and maintained over and above those that interact with the user
* Need multiple replication servers to avoid a single point of failure
————————–
* A Session is a series of requests to a servlet, originating from the same user at the same browser
How session works?
——————————
* session ID Allows to keep track of individual users
* Session ID generated on first request and send back to browser with first response.
* Session ID then arrives with each subsequent request
* Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs
Distributed sessions
——————————
Session management can store session-related information in …
* In application server memory (the default). This storage options is knows as in-memory sessions.
* In a database. This storage option is known as database persistent sessions.
* In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.
* Distributed sessions are essential for using HTTP sessions for the failover facility
* Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
* On the failure of cluster member, plug-in routes requests to other members
* When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory).
Memory-Memory replication
—————————————–
* In Memory-to-Memory session replication, session data from owner server replicates (copies) in one or more other application server using Data Replication Service
=>Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. You can configure DRS by creating a replication domain. Replication Domain can be created either manually from Environment page of admin console or automatically at cluster create time.
* This requires creation of a data replication service instance in owner server that communicates to other data replication service instances in remote application servers
* This can be achieved by creating a replication domain and configuring the session manager of cluster members to use memory-to-memory replication.
* A server can run in one of the following three modes:
* Client mode: server only sends copies of sessions it owns
* Server mode: server only stores backup copies of other servers
* Both mode: server sends copies of session it owns and acts as a backup table for sessions owned by other application server
* Two different topologies are possible based on above three modes
* Peer-to-Peer topology
* Client/Server topology
=> Peer-to-Peer topology
* Each server stores a session in it’s own memory and also stores sessions to, and retrieves from, other application servers.
* Each application server acts as client by retrieving session from other servers and acts as server by providing sessions to other application servers
* This is the default configuration and each application server can:
* Host the Web Application leveraging the HTTP Session
* Send Changes to the HTTP Session that it owns
* Receive backup copies of the HTTP session from all of the other servers in the cluster
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. Select the replication domain created in first step
4. Select “Both Client and Server” as replication mode
5. Click Ok and Save to master configuration
6. Repeat above steps for all the cluster members
7. Once done, restart the cluster
=>Advantages
* No additional processes and products are required to avoid a single point of failure.
* Reduce the time and cost required to configure and maintain additional processes or products
=>Disadvantages
* It can consume large amounts of memory with many users. This can cause a performance impact
* Does not provide stable configuration for cluster with only 2 members, because of two way replication?
=>Client/Server topology
* Application Servers act as either a replication Client or a Server
* Replication servers store sessions in there own memory and provide session info to clients.
* Dedicated replication servers just store session but do not respond to users’ requests
* Client application servers send session information to replication servers and retrieve as needed. Clients respond to user requests
* Application servers configured as Server can not host any applications. They act as pure data store for backup sessions and receive updates from Clients
* Backup data is isolated into a separate JVM
* Client replicas will contain only local session data
* Application servers configured as Servers must be started before starting Clients
=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. configure cluster1 members as client
4. configure cluster2 members as Server
5. start cluster2 first and then cluster1
=>Advantages
* Clearly distinguishes the role of client and server.
* Reduces the consumption of memory on each application server
* Better performance
* Allows recycle of a backup server without affecting the servers running applications
* Better choice if your hardware varies across the cluster
=>Disadvantages
* Additional application servers have to be configured and maintained over and above those that interact with the user
* Need multiple replication servers to avoid a single point of failure
No comments:
Post a Comment