Data replication service (DRS)
Replication is a service that transfers data, objects, or events among application servers. Data replication service (DRS) is the internal WebSphere Application Server component that replicates data.
Use data replication to make data for session manager, dynamic cache, and stateful session beans available across many application servers in a cluster.
The benefits of using replication vary depending on the component that you configure to use replication.
Session manager :
uses the data replication service when configured to do memory-to-memory replication. When memory-to-memory replication is configured, session manager maintains data about sessions across multiple application servers, preventing the loss of session data if a single application server fails. For more information about memory-to-memory replication, see Memory-to-memory replication.
Dynamic cache :
uses the data replication service to further improve performance by copying cache information across application servers in the cluster, preventing the need to repeatedly perform the same tasks and queries in different application servers. For more information about replication in the dynamic cache, see Configuring cache replication.
Stateful session beans :
uses the replication service so that applications using stateful session beans are not limited by unexpected server failures. For more information about stateful session bean failover, see Stateful session bean failover for the EJB container.
WAS provides session recovery support in the form of
Database session
Memory –to –memory replication
Memory –to –memory replication
Session recovery support is required in the following conditions :
When the user’s session data must be maintained across a server restart
When the user’s session details too valuable to lose through an unexpected server failure.
These replication settings can be configured in the following location in the admin console
Admin console -- > servers -- > application servers -- > [all servers] -- >webcontainer settings -- > session management -- > distributed environment settings
Options are :
None, Database and memory –to – memory replication
Memory-to-memory replication
WebSphere Application Server supports session replication to another WebSphere Application Server instance. This support is referred to as memory-to-memory session replication. In this mode, sessions can replicate to one or more WebSphere Application Server instances to address HTTP Session single point of failure (SPOF).
The WebSphere Application Server instance in which the session is currently processed is referred to as the owner of the session. In a clustered environment, session affinity in the WebSphere Application Server plug-in routes the requests for a given session to the same server. If the current owner server instance of the session fails, then the WebSphere Application Server plug-in routes the requests to another appropriate server in the cluster. In a peer-to-peer cluster, the hot failover feature causes the plug-in to failover to a server that already contains the backup copy of the session, avoiding the overhead of session retrieval from another server containing the backup. In a client/server cluster, the server retrieves the session from a server that has the backup copy of the session. The server now becomes the owner of the session and affinity is now maintained to this server.
There are three possible modes. You can set up a WebSphere Application Server instance to run in:
Server mode:
Only store backup copies of other WebSphere Application Server sessions and not to send out copies of any session created in that particular server
Client mode:
Only broadcast or send out copies of the sessions it owns and not to receive backup copies of sessions from other servers
Both mode:
Simultaneously broadcast or send out copies of the sessions it owns and act as a backup table for sessions owned by other WebSphere Application Server instances
You can select the replication mode of server, client, or both when configuring the session management facility for memory-to-memory replication. The default is both. This storage option is controlled by the mode parameter.
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that talks to other data replication service instances in remote application servers. You must configure this data replication service instance as a part of a replication domain.
Data replication service instances on disparate application servers that replicate to one another must be configured as a part of the same domain. You must configure all session managers connected to a replication domain to have the same topology. If one session manager instance in a domain is configured to use the client/server topology, then the rest of the session manager instances in that domain must be a combination of servers configured as Client only and Server only.
If one session manager instance is configured to use the peer-to-peer topology, then all session manager instances must be configured as Both client and server. For example, a server only data replication service instance and a both client and server data replication service instance cannot exist in the same replication domain.
Multiple data replication service instances that exist on the same application server due to session manager memory-to-memory configuration at various levels that are configured to be part of the same domain must have the same mode.
With respect to mode, the following are the primary examples of memory-to-memory replication configuration:
Peer-to-peer replication
Client/server replication
Memory-to-memory topology:
Peer-to-peer function
The basic peer-to-peer (both client and server function, or both mode) topology is the default configuration and has a single replica. However, you can also add additional replicas by configuring the replication domain.
In this basic peer-to-peer topology, each server Java Virtual Machine (JVM) can:
Host the Web application leveraging the HTTP session
Send out changes to the HTTP session that it owns
Receive backup copies of the HTTP session from all of the other servers in the cluster
This configuration represents the most consolidated topology, where the various system parts are collocated and requires the fewest server processes. When using this configuration, the most stable implementation is achieved when each node has equal capabilities (CPU, memory, and so on), and each handles the same amount of work.
Session hot failover
A new feature called session hot failover has been added to this release. This feature is only applicable to the peer-to-peer mode. In a clustered environment, session affinity in the WebSphere Application Server plug-in routes the requests for a given session to the same server. If the current owner server instance of the session fails, then the WebSphere Application Server plug-in routes the requests to another appropriate server in the cluster. For a cluster configured to run in the peer-to-peer mode this feature causes the plug-in to failover to a server that already contains the backup copy of the session, therefore avoiding the overhead of session retrieval from another server containing the backup.
You must upgrade all WebSphere Application Server plug-in instances that front the Application Server cluster to version 6.0 to ensure session affinity when using the peer-to-peer mode.
Memory-to-memory topology:
Client/server function
The following figure depicts the client/server mode. There is a tier of applications servers that host Web applications using HTTP sessions, and these sessions are replicated out as they are created and updated. There is a second tier of servers without a Web application installed, where the session manager receives updates from the replication clients.
Benefits of the client/server configuration include:
Isolation (for failure recovery)
In this case we are isolating the handling of backup data from local data; aside from isolating the moving parts in case of a catastrophic failure in one of them, you again free up memory and processing in the servers processing the Web application
Isolation for stopping and starting
You can recycle a backup server without affecting the servers running the application (when there are two or more backups, failure recovery is possible), and conversely recycle an application JVM without potentially losing that backup data for someone.
Consolidation
There is most likely no need to have a one-to-one correspondence between servers handling backups and those processing the applications; hence, you are again reducing the number of places to which you transfer the data.
Disparate hardware:
While you run your Web applications on cheaper hardware, you may have one or two more powerful computers in the back end of your enterprise that have the capacity to run a couple of session managers in replication server mode; allowing you to free up your cheaper Web application hardware to process the Web application.
Timing consideration:
Start the backup application servers first to avoid unexpected timing windows. The clients attempt to replicate information and HTTP sessions to the backup servers as soon as they come up. As a result, HTTP sessions that are created prior to the time at which the servers come up might not replicate successfully.
Database session
Database settings
Use this page to specify the settings for database session support.
To view this administrative console page, click Servers > Application servers > server_name > Web container settings > Session management > Distributed environment settings > Database.
Configuration tab
Datasource JNDI name
Specifies the datasource description.
The JNDI name of the non-XA enabled datasource from which session management obtains database connections. For example, if the JNDI name of the datasource is "jdbc/sessions", specify "jdbc/sessions." The datasource represents a pool of database connections and a configuration for that pool (such as the pool size). The datasource must already exist as a configured resource in the environment.
User ID
Specifies the user ID for database access.
Password
Specifies the password for database access.
DB2 row size
Specifies the table space page size configured for the sessions table, if using a DB2 database. Possible values are 4, 8, 16, and 32 kilobytes (KB). The default row size is 4KB.
The default row size is 4KB. In DB2, it can be updated to a larger value. This can help database performance in some environments. When this value is other than 4, you must specify table space name to use this property. For 4KB pages, the table space name is optional.
Table space name
Specifies that table space to be used for the sessions table.
This value is required when the DB2 page size is other than 4KB.
Use multi row schema
Specifies that each instance of application data be placed in a separate row in the database, allowing larger amounts of data to be stored for each session. This action can yield better performance in certain usage scenarios. If using multi row schema is not enabled, instances of application data can be placed in the same row.
Replication is a service that transfers data, objects, or events among application servers. Data replication service (DRS) is the internal WebSphere Application Server component that replicates data.
Use data replication to make data for session manager, dynamic cache, and stateful session beans available across many application servers in a cluster.
The benefits of using replication vary depending on the component that you configure to use replication.
Session manager :
uses the data replication service when configured to do memory-to-memory replication. When memory-to-memory replication is configured, session manager maintains data about sessions across multiple application servers, preventing the loss of session data if a single application server fails. For more information about memory-to-memory replication, see Memory-to-memory replication.
Dynamic cache :
uses the data replication service to further improve performance by copying cache information across application servers in the cluster, preventing the need to repeatedly perform the same tasks and queries in different application servers. For more information about replication in the dynamic cache, see Configuring cache replication.
Stateful session beans :
uses the replication service so that applications using stateful session beans are not limited by unexpected server failures. For more information about stateful session bean failover, see Stateful session bean failover for the EJB container.
WAS provides session recovery support in the form of
Database session
Memory –to –memory replication
Memory –to –memory replication
Session recovery support is required in the following conditions :
When the user’s session data must be maintained across a server restart
When the user’s session details too valuable to lose through an unexpected server failure.
These replication settings can be configured in the following location in the admin console
Admin console -- > servers -- > application servers -- > [all servers] -- >webcontainer settings -- > session management -- > distributed environment settings
Options are :
None, Database and memory –to – memory replication
Memory-to-memory replication
WebSphere Application Server supports session replication to another WebSphere Application Server instance. This support is referred to as memory-to-memory session replication. In this mode, sessions can replicate to one or more WebSphere Application Server instances to address HTTP Session single point of failure (SPOF).
The WebSphere Application Server instance in which the session is currently processed is referred to as the owner of the session. In a clustered environment, session affinity in the WebSphere Application Server plug-in routes the requests for a given session to the same server. If the current owner server instance of the session fails, then the WebSphere Application Server plug-in routes the requests to another appropriate server in the cluster. In a peer-to-peer cluster, the hot failover feature causes the plug-in to failover to a server that already contains the backup copy of the session, avoiding the overhead of session retrieval from another server containing the backup. In a client/server cluster, the server retrieves the session from a server that has the backup copy of the session. The server now becomes the owner of the session and affinity is now maintained to this server.
There are three possible modes. You can set up a WebSphere Application Server instance to run in:
Server mode:
Only store backup copies of other WebSphere Application Server sessions and not to send out copies of any session created in that particular server
Client mode:
Only broadcast or send out copies of the sessions it owns and not to receive backup copies of sessions from other servers
Both mode:
Simultaneously broadcast or send out copies of the sessions it owns and act as a backup table for sessions owned by other WebSphere Application Server instances
You can select the replication mode of server, client, or both when configuring the session management facility for memory-to-memory replication. The default is both. This storage option is controlled by the mode parameter.
The memory-to-memory replication function is accomplished by the creation of a data replication service instance in an application server that talks to other data replication service instances in remote application servers. You must configure this data replication service instance as a part of a replication domain.
Data replication service instances on disparate application servers that replicate to one another must be configured as a part of the same domain. You must configure all session managers connected to a replication domain to have the same topology. If one session manager instance in a domain is configured to use the client/server topology, then the rest of the session manager instances in that domain must be a combination of servers configured as Client only and Server only.
If one session manager instance is configured to use the peer-to-peer topology, then all session manager instances must be configured as Both client and server. For example, a server only data replication service instance and a both client and server data replication service instance cannot exist in the same replication domain.
Multiple data replication service instances that exist on the same application server due to session manager memory-to-memory configuration at various levels that are configured to be part of the same domain must have the same mode.
With respect to mode, the following are the primary examples of memory-to-memory replication configuration:
Peer-to-peer replication
Client/server replication
Memory-to-memory topology:
Peer-to-peer function
The basic peer-to-peer (both client and server function, or both mode) topology is the default configuration and has a single replica. However, you can also add additional replicas by configuring the replication domain.
In this basic peer-to-peer topology, each server Java Virtual Machine (JVM) can:
Host the Web application leveraging the HTTP session
Send out changes to the HTTP session that it owns
Receive backup copies of the HTTP session from all of the other servers in the cluster
This configuration represents the most consolidated topology, where the various system parts are collocated and requires the fewest server processes. When using this configuration, the most stable implementation is achieved when each node has equal capabilities (CPU, memory, and so on), and each handles the same amount of work.
Session hot failover
A new feature called session hot failover has been added to this release. This feature is only applicable to the peer-to-peer mode. In a clustered environment, session affinity in the WebSphere Application Server plug-in routes the requests for a given session to the same server. If the current owner server instance of the session fails, then the WebSphere Application Server plug-in routes the requests to another appropriate server in the cluster. For a cluster configured to run in the peer-to-peer mode this feature causes the plug-in to failover to a server that already contains the backup copy of the session, therefore avoiding the overhead of session retrieval from another server containing the backup.
You must upgrade all WebSphere Application Server plug-in instances that front the Application Server cluster to version 6.0 to ensure session affinity when using the peer-to-peer mode.
Memory-to-memory topology:
Client/server function
The following figure depicts the client/server mode. There is a tier of applications servers that host Web applications using HTTP sessions, and these sessions are replicated out as they are created and updated. There is a second tier of servers without a Web application installed, where the session manager receives updates from the replication clients.
Benefits of the client/server configuration include:
Isolation (for failure recovery)
In this case we are isolating the handling of backup data from local data; aside from isolating the moving parts in case of a catastrophic failure in one of them, you again free up memory and processing in the servers processing the Web application
Isolation for stopping and starting
You can recycle a backup server without affecting the servers running the application (when there are two or more backups, failure recovery is possible), and conversely recycle an application JVM without potentially losing that backup data for someone.
Consolidation
There is most likely no need to have a one-to-one correspondence between servers handling backups and those processing the applications; hence, you are again reducing the number of places to which you transfer the data.
Disparate hardware:
While you run your Web applications on cheaper hardware, you may have one or two more powerful computers in the back end of your enterprise that have the capacity to run a couple of session managers in replication server mode; allowing you to free up your cheaper Web application hardware to process the Web application.
Timing consideration:
Start the backup application servers first to avoid unexpected timing windows. The clients attempt to replicate information and HTTP sessions to the backup servers as soon as they come up. As a result, HTTP sessions that are created prior to the time at which the servers come up might not replicate successfully.
Database session
Database settings
Use this page to specify the settings for database session support.
To view this administrative console page, click Servers > Application servers > server_name > Web container settings > Session management > Distributed environment settings > Database.
Configuration tab
Datasource JNDI name
Specifies the datasource description.
The JNDI name of the non-XA enabled datasource from which session management obtains database connections. For example, if the JNDI name of the datasource is "jdbc/sessions", specify "jdbc/sessions." The datasource represents a pool of database connections and a configuration for that pool (such as the pool size). The datasource must already exist as a configured resource in the environment.
User ID
Specifies the user ID for database access.
Password
Specifies the password for database access.
DB2 row size
Specifies the table space page size configured for the sessions table, if using a DB2 database. Possible values are 4, 8, 16, and 32 kilobytes (KB). The default row size is 4KB.
The default row size is 4KB. In DB2, it can be updated to a larger value. This can help database performance in some environments. When this value is other than 4, you must specify table space name to use this property. For 4KB pages, the table space name is optional.
Table space name
Specifies that table space to be used for the sessions table.
This value is required when the DB2 page size is other than 4KB.
Use multi row schema
Specifies that each instance of application data be placed in a separate row in the database, allowing larger amounts of data to be stored for each session. This action can yield better performance in certain usage scenarios. If using multi row schema is not enabled, instances of application data can be placed in the same row.
Posts
0 comments:
Post a Comment