weblogic server & IT architecture
Weblogic server installation has a centralized Admin Server, that allows deployment and configuration of various resources such as adapters, jndi name configuration, connection pools etc. Each Weblogic Server can have manage multiple Managed Servers.
Managed Servers are associated with Admin Servers, for example SOA-BAM can run under one managed server, Webcenter can be second managed server, BAM can be 3rd Managed Server, Identity Management can be 4th Managed Server, Business Intelligence can be 5th Managed Server, Content Management can be 6th Managed Sever all these can run under one admin server. All other servers other than Admin Server are referred as Managed servers.
These managed server can co-exist individually or they can be clustered together.
Even if admin server fails or stops , managed server can run independently and continue to do their work, example Webcenter Managed Server can still be running even if its corresponding Admin Server is shutdown or failed .
Admin server can fail under multiple reasons it can be hardware related issue or it can be software related issue or simply out of memory exceptions making admin server go down.
Advantages of Clustering Managed Servers
- Increased Scalability ,Reliability and High Availability
- Increased Performance
- Support to Load Balancing
- Fail-over enablement
- Web Applications, EJBs, J2EE Connector
- JDBC Connections pools
- JMS Servers, start up and shut down classes.
Most JEE Applications have following Objects that can be clustered they are Servlets, JSPs, EJBs, RMI Objects, JDBC Connections, JMS Destinations.
JSP and Servlet under Cluster
Weblogic server replicates session data across various clustered servers, these session data can be persisted eighter in database or in file system or in memory cache
For example once a server X has heavy load , the load balancer helps the client to fetch session data and work with server Y. so user would not know that earlier he/she was accessing server X now the control is passed to server Y, where all his session data is made available
HTTP Session Replication
- In-memory replication : Weblogic server maintains session data of the user in which he first logged in (Primary Server), this data is replicated and updated in another Weblogic server (Secondary Server), incase primary server fails session data is made available in secondary data. so is the application deployed.
- JDBC based persistence : Session data of primary server is stored in database and is constantly updated, if primary server fails secondary server reads session data from database and user experience continues on secondary server
failover and load balancing
Application Fail-over Consider a real life example of shopping cart where user has signed in and browsed through a series of products and added them to his shopping cart, just before checkout , something goes wrong with this server (Primary Server) and stops responding.
if Weblogic server (secondary server) is configured in a cluster to handle such application Failover then the session information is made available to the next available managed server in the cluster. which ensures that the user experiance continues till the transaction of sales cycle is completed.
Weblogic server uses JNDI to maintain list of Objects available across the cluster
Load Balancing : Here all the objects are made available across all the managed servers in the cluster, when the load increases on one server , the load is automatically taken by another server that has lesser load. all of these severs work together to ensure that the transaction or job is completed for a given client request.
failover and replication in a cluster
There are 2 standard techniques that Weblogic uses to find out the status of failed servers in a cluster
- Socket Connection : try to establish server socket connection with another peer server in a regular interval say 10 secs, once there is no response back say for 30 says from one of the peers, its considered as failed server , and other server in the cluster takes over.
- Heart Beat : Here there will be a central monitoring server that keeps track of all the other peers in the cluster, each of these peers will send a message to central monitoring server every 10 secs, by any chance if one of the servers fail to send back response even after 30 secs its considered to be failed server. the monitoring server under such a case updates its JNDI to point to a live server which is similar to the failed one.