The customers who are looking to embark on Oracle SOA for the first time especially on a high available mode are mostly daunted looking at various deployment topologies and administrative tasks involved with in. While the Oracle Enterprise Deployment Guide ( EDG) is very popular and is used as a reference to setup the high availability there would be still a lot of questions lingering around like why certain things are being setup or setup in a particular way. In fact, sometimes,its not clear why we are doing somethings in the entire process. This post attempts to help resolve those vague concepts.
Question : What is the use of external load balancer(software or hardware) when we plan to implement a web logic cluster that does load balancing anyway.?
Answer : External Load balancers provide an additional layer of security and more reliability of load balancing as they are not affected by the internal systems performances but are used only to load balance across Http servers or some cases ( not suggested) application servers using well defined algortihms. The need for load balancing at cluster level is for clustered object stubs when no algorithm is specified at the object level. The algorithm at weblogic cluster level supports load balancing for RMI objects and EJBs.
Question : Can Managed servers continue to run in case admin server comes down ?
Answer : Yes of course they do. They try to contact admin server at a particular frequency that is setup int he configurations, but then will continue on their own. Another point to note is that managed servers can also start by themselves ( with help of node manager) with out Admin server being up. This is called as MSI mode or Managed Server Independence mode.The problem with this mode is that managed servers can not get the latest update on the configurations done in the domain as it runs with its own copy of the configuration which is collected upon its start when admin was up and running.
Question : What is whole server migration ? Why do I need it when my cluster is performing a "fail over" of various services when one of its members is down ?
Answer : In a WebLogic Server cluster, most services are deployed homogeneously on all server instances in the cluster, enabling transparent failover from one server to another. In contrast, "pinned services" such as JMS and the JTA transaction recovery system are targeted at individual server instances within a cluster—for these services, WebLogic Server supports failure recovery with migration, as opposed to failover.
Question : Why does JMS and JTA are targeted to single server ?
Answer : Weblogic services are divided into two categories , one Clustered Services and two Singleton Services. The JMS,JTA services come under the Singleton services that can be targeted only to a single instance in a cluster and more importantly will be managed by a single persistent store ( Note : single persistent store is the key).
The reason for this setup is that it offers high QOS by ensuring message consistency and reliability. For example a JMS message on a topic or a queue should not be stored in multiple places for data consistency. Also the information related to the message like transactions, acknowledgement etc should not be shared across.
Question : Is Whole Server migration the only way to ensure JMS and JTA "Singleton" services are recovered in case of failures?
Answer : No. We can do service migration too. ie., migration of individual JMS and JTA services to other server. The problem is that only JTA service migration supports the migration to other server using the default persistent store. Other services such as JMS needs to use custom persistent stores for them to be able to migrate to other servers.
Question : Would the problem be same for any other Singleton services in my server?
Answer : Yes. The singleton services as the name indicates, means that they are meant to be targeted to a single server instance and will use one persistent store allocated for those services in that server instance.
Question : What is the impact if Server/Service migration is not setup ?
Answer : Your instances that was running crashes and it may be retried based on various parameters. If its an asynchronous instance that is dehydrated by the time it crashed, the server may try to recover it. Manual recovery sometimes is still the option in certain cases.
This still sounds theoretical although it clears a cloud of vagueness regarding some important concepts of HA architecture. Understanding of the above in more practical way with examples will be done my upcoming blog.