*********
Let us understand the High Availability
in simple terms and go deep into it:
First Availability (A) is a
measure of time that a server is functioning normally, as well a measure of time the recovery process requires after system fails. Normal def. Availability is the description of the system’s ability to
respond to requests no matter the circumstances.
MTBF is the mean time between the failure and MTTR is
the maximum time for the recovery.
A = MTBF / ( MTBF + MTTR) which means if we can reduce the MTTR to zero,
availability is 100%.
A Websphere production system contains many
components such as Firewalls, Load balancer, Web Servers, Application Servers,
Database, LDAP and Administrative Servers. System Availability is determined by
the weakest point in the system. Every component has different MTBF and MTTR.
In order to make MTTR = 0, we use , redundant
hardware and clustering software .
Levels of Availability:
- Basic: No spl. Measures, incase of failure system is restored using backup.
- Redundant Data: Full disk mirroring instead of RAID 5 provides more data protection.
- Component Fail Over: As explained about there are many components in WAS and failure of one of the component like firewall might result in outage or make server vulnerable. We should ensure to use HA h/w and s/w at each level.
WAS 6 provides HA for servers using Vertical
Clustering and HA for Node agents using Horizontal Clustering.
- System Fail Over: Use a backup system in case of primary system fails, the clustering s/w will detect the failure and switches to healthy host so that the service is not interrupted. Most of the systems support system fail over unless the s/w is dependent on physical host variables.
- Disaster Recovery: This refers to maintaining sites in different geographical location, in case of failure in the primary location, system switches to backup system.
Possible single
points of failure in the WebSphere system
|
Web server
|
Multiple Web
servers with network sprayer, hardware-based clustering.
|
|
WebSphere master
repository data, log files
|
HA shared file system, Network File System
(NFS), hardware based clustering.
|
|
WebSphere
Application Server
|
Network Deployment - application server
clustering:
-> Horizontal
-> Vertical
-- Combination of
both additionally for EJB's : Backup Cluster
|
|
WebSphere Node
Agent
|
Multiple Node
Agents in the cluster, OS service,
hardware-based
clustering.
|
|
WebSphere
Deployment Manager
|
OS service,
hardware-based clustering,
backup WebSphere
cell.
|
|
Entity EJBs,
application DB
|
HA DBs, parallel
DBs.
|
|
Default messaging
provider
|
WebSphere application server clustering:
HAManager provides failover.
|
|
Default messaging
provider data store
|
Clustering, data
replication, parallel database.
|
|
Application
database
|
Clustering, data replication, parallel
database.
|
|
Session database
|
Memory-to-memory
replication, DB clustering, parallel database. (DRS - Data Replication
Service in WAS)
|
|
Transaction logs
|
WebSphere application server
clustering: HAManager provides
failover, shared file system with horizontal clustering.
|
|
WebSphere MQ
|
WebSphere MQ cluster, combination of
WebSphere MQ cluster and clustering.
|
*********
WebSphere Application Server failover and recovery is
realized through the workload management (WLM) mechanism that are provided by
WAS ND.
The only single point of failure using WAS ND is Dmgr.
However, it only impacts the ability to change cell configuration or view TPV or to perform failover of EJB's.
There are many mechanism such as External H/W based cluster to avoid this.
********
Work Load Management (WLM):
WAS ND WLM optimizes the distribution of incoming
requests to application servers based on the configuration. WLM configuration involves providing weight to
each cluster member based on the machine configuration, higher configuration will be configured with higher
weight which result in receiving more requests.
WLM also provides
the ability of failover by directing existing clients to other, still available
servers also it directs the new requests only to the available servers.
Failover can also
some times referred as fault tolerance, in that it allows the system to survive
various faults or failures. Failover is the only technique in the broad field
of Fault Tolerance and there is no technique to assure 100% safe guard. We can
only reduce system failure but, cannot be eliminated.
HA Manager:
It is advanced
failover concept, HAManager will enhance the availability of single ton
services such as Messaging and transaction services.
A cluster is a set of logical group of application servers that are
managed together and participate in workload managementCluster Members or
servers might be from different node agents.
Session Management:
Maintaining state
for the client requests using session is a unavoidable. WAS has two mechanisms
to ensure HA of sessions. 1) Persist the session using DB (When you have HA DB)
2) Memory to Memory Replication which is good if you don't have HA DB or clustered
DB
Session Management
can be performed at Application Server level, Application Level or at the Web
Module Level.
Two types of
requests can be work load managed in WAS ND:
- HTTP Requests: HTTP requests are received by HTTP Server. If they are static requests it can be served by HTTP Server if it is dynamic HTTP Server it will be forwarded to web container in Application Server. HTTP Plugin module decides whether it should be forwarded or it should be served by HTTP Server itself.
- EJB Requests: EJB Requests can be distributed across multiple servers. Whether the request comes from the web container or outside if the server fails it can be forwarded to the other active server.
Managing session state among servers:
If the information provided by the client is all required
to process a request then it is Stateless
session. In which case there is no need for the subsequent request of
the client to go to the same server.
However, if the information provided by the client is NOT
enough and require information of the
previous request is a stateful
session. In which case the subsequent request should be processed by the same
server.
HTTP Requests:
HTTP
client interacting with a servlet, the state information associated with a
series of client requests is represented as an HTTP session,
and
identified by a session ID.
Plugin
uses the Session identifiers - which
will allow the plug-in to pick the correct cluster member and Web container to
retrieve the current session object.
The
session manager module that is part of each Web container is responsible for
managing HTTP sessions, providing storage for session data, allocating session
IDs, and tracking the session ID associated with each client request.
Two
types of HTTP Fail overs available:
Database
persistence: Storing session information in a database which is available to
all servers.
Memory
to Memory replication: DRS (Data Replication Service) is used to share the
session information between Application Servers.
There
are three methods of identifying a user’s session to the application server:
Cookies,
URL rewriting, and SSL ID. Below is exampl JSESSIONID cookie
JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0
which
consists of four parts:
Cache ID (0000)
Session ID (A2MB4IJozU_VM8IffsMNfdR)
Separator (:)
Clone ID (v544d0o0 = application server ID)
Example of a session identifier - JSESSIONID
cookie
In
case of a failover, the Clone ID of the failover server is appended at the end,
also separated by a colon. When the original server becomes available again,
the request falls back and is handled by the original server.
session affinity, where the load distribution
facility recognizes the existence of a session and attempts to direct all
requests within that session to the same server
Example
User request from plugin log when set to debug:
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: ws_common:
websphereBeginRequest: Beginning a client request
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DETAIL: ws_common:
websphereBeginRequest: Request is: host='dlp.deloitteresources.com';
uri='/Saba/loginAsGuest.jsp'
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: ws_common:
websphereVhostMatch: Found a match '*:443' to 'dlp.deloitteresources.com:443'
in VhostGroup: default_host with score 1, exact match 0
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: ws_common: websphereUriMatch:
Found a match '/Saba/*' to '/Saba/loginAsGuest.jsp' in UriGroup:
default_host_dlpProdcluster_URIs with score 6, exact match 6
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DETAIL: ws_common:
websphereFindServerGroup: Setting the server group: dlpProdcluster; highScore:
7; highExactMatch: 6; affinityCookie: JSESSIONID; affinityURL: jsessionid
....
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: ws_common:
websphereParseCloneID: Parsing clone ids from
'0000t38n9LshJG0GOEqynT8BkXb:16qjggb28'
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: ws_server:
serverHasReachedMaxConnections: server dlpProdAppSrv1node_dlpProdmember1 -
currentConnectionsCount 0, maxConnectionsCount -1.
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DETAIL: ws_common:
websphereFindTransport: Setting the transport(case 3): usatrame2914 on port
9981
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DEBUG: lib_htrequest: htrequestWrite:
Writing the request reqInfo is OK:
....
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DETAIL: Cookie: userLoggedIn=true;
BIGipServerdlp.deloitteresources.com=1271985930.47873.0000;
sourceApp=deloitteresources; AppNameCookie=https://dlpdelc.deloitteresources.com/;
WebSSOUsername=; ASPSESSIONIDAUQQCRTC=JEDNFBHCOOOMPBECCELGHPDC;
WebSSOPassword=ASPSESSIONIDAUQQCRTC%3DJEDNFBHCOOOMPBECCELGHPDC%7Cdlp.deloitteresources.com%7C;
JSESSIONID=0000t38n9LshJG0GOEqynT8BkXb:16qjggb28;
WASReqURL=https:///Saba/Web/Main
.....
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - DETAIL: HTTP/1.1 200 OK
....
[Wed
Oct 03 22:18:41 2012] 00000b60 00000b94 - STATS: ws_server:
serverSetFailoverStatus: Server dlpProdAppSrv1node_dlpProdmember1 :
pendingRequests 0 failedRequests 0
affinityRequests 3 totalRequests 4.
Best Practices:
Some
of the settings in the Plugin (Plugin-cfg.xml) file affects the work load
management.
Retry interval:
Value
is for connecting to a cluster member
marked as down.
Servers
→ Web Servers → WebServer_Name → Plug-in properties → Request Routing.
Connection Timeout setting:
Is
between the plug-in and each Application Server. The default value is 0 which means, no
timeout value. Without this field it
takes the time out value of TCP/IP Timeout from OS, which result in slowness.
Application
servers →<AppServer_Name> → Web Server plug-in properties
Primary and backup servers:
There
is an option of tag Backup Server along with Primary. Requests are sent only if
all the primary servers are unavailable.
Maximum number of connections:
Number
of concurrent connections depend on the number of threads available. ( 10 conn
req. 10 Thrds) If it is zero which means
unlimited.
The
Maximum number of connections attribute is used to specify the maximum number
of pending connections to an application server.
MaxConnections
attribute is set to 10, then each application server could potentially get up
to 20 pending connections.
EJB Requests:
Stateless Session Bean:
Which
maintains no information on the state of the request. Every EJB Container
maintains a pool of stateless session bean and provides arbitrary instance.
Requests can be handled by any EJB Container in the cluster members regardless
of the previous request.
Message Driven Bean:
The
MDB is a stateless component that is invoked by a J2EE container when a JMS
message arrives at a particular JMS destination (either a queue or topic).
Loosely, the MDB is triggered by the arrival of a message.
Stateful Session Bean:
Which
captures state information and should be shared across the other EJB Containers
in the cluster. From V6 stateful session replication is supported in WAS using
DRS.
Entity Bean:
Entity
bean is persistent bean which can be contacted by multiple sources and
subsequent accesses require us to manitain the state .The concept of session,
session affinity is replaced with
transaction and transaction affinity.
For the duration of transaction all the requests should be forwarded to the
same instance.
Stateful session bean failover at three levels:
EJB container -Server level
Enterprise application - Application Level
EJB module - Module Level
Each
EJB container provides a method for stateful session beans to fail over to
other servers. This section enables you to specify whether failover occurs for
the stateful session beans in this EJB module. You can also override the
default replication settings that are configured for this application or the
EJB container on the server with values that are specific to this EJB module.
Generally
the Stateful session replication is managed at the EJB Module level, in the
below case replication is enabled at Saba_EJB.jar module.
Also
you can observe that it is not enabled at the server level. Or at the
application level.
No comments:
Post a Comment