A WebLogic Server cluster consists of multiple WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. Server instances in a cluster can run on the same machine or different machines. Clusters provide high availability through application failover and scalability by adding additional server instances. Key capabilities of clusters include application failover, cluster migration, and load balancing.

1. Weblogic Cluster

2. What is Cluster
A WebLogicServer cluster consistsof multipleWebLogicServer server instances
runningsimultaneously andworkingtogether toprovideincreasedscalability and
reliability. A cluster appearstoclientstobeasingleWebLogicServer instance.
Theserver instancesthatconstituteacluster canrunonthesamemachine, or belocated
ondifferentmachines. Youcanincreaseacluster'scapacity by addingadditional server
instancestothecluster onanexistingmachine, or youcanaddmachinestothecluster to
hosttheincremental server instances. Eachserver instanceinacluster mustrunthesame
versionof WebLogicServer.

3. Cluster-Domain Relation
● Cluster is part of Domain
● Domain contains server which can be clustered
● Domain can have multiple domain
● Each Domain has one Administration Server
● One Administration Server is shared by all clusters
in the domain
● All server instances in a cluster are part of a single
domain
● Clustered Server instances provide failover and
load-balancing

4. Benifits of Clustering
● High Availability
● Scalability

5. Cluster Capabilities
● Application Failover
● Cluster Migration
● Load Balancing

6. Cluster Supported Objects
● Servlets
● JSPs
● EJBs
● RemoteMethodInvocation(RMI) objects
● JavaMessagingService(JMS) destinations
● JavaDatabaseConnectivity (JDBC) connections

7. Cluster Unsupported Objects
■ Fileservicesincludingfileshares
■ Timeservices

8. WebLogic Server Communication
In a Cluster
■ IP sockets, whicharetheconduitsfor peer-to-peer
communicationbetweenclusteredserver instances.
■ IP unicastor multicast, whichserver instancesuse
tobroadcastavailability of services and heartbeats that
indicate continued availability.
Whencreatinganew cluster, Oraclerecommendsthat
youuseunicastfor messagingwithinacluster.

9. Using IP Multicast for Backward
Compatibility
IP multicastisasimplebroadcasttechnology thatenablesmultipleapplicationsto"subscribe" toagivenIP
addressandportnumber andlistenfor messages.
IP multicastbroadcastsmessagestoapplications, butitdoesnotguaranteethatmessagesareactuallyreceived.
If anapplication'slocal multicastbuffer isfull, newmulticastmessagescannotbewrittentothebuffer andthe
applicationisnotnotifiedwhenmessagesare"dropped." Becauseof thislimitation, WebLogicServer
instancesallow for thepossibility thatthey may occasionallymissmessagesthatwerebroadcastover IP
multicast.
WebLogicServer usesIP multicastfor all one-to-many communicationsamongserver instancesinacluster.
Thiscommunicationincludes:
■ Cluster-wideJNDI updates—EachWebLogicServer instanceinacluster usesmulticasttoannouncethe
availability of clusteredobjectsthataredeployedor removedlocally. Eachserver instanceinthecluster
monitorstheseannouncementsandupdatesitslocal JNDI treetoreflectcurrentdeploymentsof clustered
objects.
■ Cluster heartbeats—EachWebLogicServer instanceinacluster usesmulticasttobroadcastregular
"heartbeat" messagesthatadvertiseitsavailability. Bymonitoringheartbeatmessages, server instancesina
cluster determinewhenaserver instancehasfailed. (Clusteredserver instancesalsomonitor IP socketsasa
moreimmediatemethodof determiningwhenaserver instancehasfailed.)
■ Clusterswithmanynodes—Multicastcommunicationistheoptionof choicefor clusterswithmany nodes.

10. One-to-Many Communication Using
Unicast
WebLogicServer providesanalternativetousing
multicasttohandlecluster messagingand
communications. Unicastconfigurationismucheasier
becauseitdoesnotrequirecrossnetwork configuration
thatmulticastrequires. Additionally, itreduces
potential network errorsthatcanoccur frommulticast
addressconflicts.

11. Peer-to-Peer Communication
Using IP Sockets
IP socketsprovideasimple, high-performancemechanismfor transferringmessagesanddata
betweentwoapplications. ClusteredWebLogic Server instancesuseIP socketsfor:
■ Accessingnon-clusteredobjectsdeployedtoanother clusteredserver instanceonadifferent
machine.
■ReplicatingHTTP sessionstatesandstateful sessionEJB statesbetweenaprimary and
secondary server instance.
■ Accessingclusteredobjectsthatresideonaremoteserver instance.
Proper socketconfigurationiscrucial totheperformanceof aWebLogic Server cluster. Two
factorsdeterminetheefficiency of socketcommunicationsinWebLogic Server:
■ Whether theserver instancehostsystemusesanativeor apure-Javasocketreader
implementation.
■ For systemsthatusepure-Javasocketreaders, whether theserver instanceisconfiguredtouse
enoughsocketreader threads.

12. Cluster-Wide JNDI Naming
Service
● Clientsof anon-clusteredWebLogicServer server instanceaccessobjectsand
servicesby usingaJNDI-compliantnamingservice. TheJNDI namingservice
containsalistof thepublic servicesthattheserver instanceoffers, organizedina
treestructure. A WebLogicServer instanceoffersanew serviceby bindingintothe
JNDI treeanamethatrepresentstheservice. Clientsobtaintheserviceby
connectingtotheserver instanceandlookinguptheboundnameof theservice.
● Server instancesinacluster utilizeacluster-wideJNDI tree. A cluster-wideJNDI
treeissimilar toasingleserver instanceJNDI tree, insofar asthetreecontainsalist
of availableservices. Inadditiontostoringthenamesof local services, however, the
cluster-wideJNDI treestorestheservicesofferedby clusteredobjects(EJBsand
RMI classes) fromother server instancesinthecluster.
● EachWebLogicServer instanceinacluster createsandmaintainsalocal copy of
thelogical cluster-wideJNDI tree. Thefollow sectionsdescribehow thecluster-
wideJNDI treeismaintained, andhow toavoidnamingconflictsthatcanoccur ina
clusteredenvironment.

13. Cluster Configuration
● Theconfig.xml fileisanXML documentthatdescribestheconfigurationof a
WebLogicServer domain. config.xml consistsof aseriesof XML elements.
TheDomainelementisthetop-level element, andall elementsintheDomain
descendfromtheDomainelement. TheDomainelementincludeschildelements,
suchastheServer, Cluster, andApplicationelements. Thesechildelementsmay
havechildrenof their own. For example, theServer elementincludesthechild
elementsWebServer, SSL andLog. TheApplicationelementincludesthechild
elementsEJBComponentandWebAppComponent.
● Eachelementhasoneor moreconfigurableattributes. Anattributedefinedin
config.dtd hasacorrespondingattributeintheconfigurationAPI. For
example, theServer elementhasaListenPort attribute, andlikewise, the
weblogic.management.configuration.ServerMBean hasa
ListenPort attribute. Configurableattributesarereadableandwritable, thatis,
ServerMBean hasagetListenPort andasetListenPort method.

14. Role of the Administration Server
TheAdministrationServer istheWebLogicServer instancethatconfiguresand
managestheWebLogicServer instancesinitsdomain.

15. Dynamic Configuration
● WebLogicServer allowsyoutochangetheconfigurationattributesof domain
resourcesdynamically—whileserver instancesarerunning. Inmostcasesyoudo
notneedtorestarttheserver instancefor your changestotakeeffect. Whenan
attributeisreconfigured, thenew valueisimmediately reflectedinboththecurrent
run-timevalueof theattributeandthepersistentvaluestoredinconfig.xml.
● Notall configurationchangesareapplieddynamically. For example, if youchangea
ManagedServer'sListenPort value, thenew portwill notbeuseduntil thenext
timeyoustarttheManagedServer. Theupdatedvalueisstoredinconfig.xml,
buttheruntimevalueisnotaffected.
● TheAdministrationConsolevalidatesattributechanges, checkingfor out-of-range
errorsanddatatypemismatcherrors, anddisplaysanerror messagefor erroneous
entries. OncetheAdministrationConsolehasbeenstarted, if another process
capturesthelistenportassignedtotheAdministrationServer, youshouldstopthe
processthatcapturedtheport. If youarenotabletoremovetheprocessthat
capturedthelistenport, edittheconfig.xml filetochangetheListenPort
value.

16. Application Deployment in Cluster
● Weblogic.Deployer
● WSLT
● Admin Console

17. Two Phase Deployment
First Phase of Deployment
Duringthefirstphaseof deployment,
applicationcomponentsaredistributedtothe
targetserver instances, andtheplanned
deploymentisvalidatedtoensurethatthe
applicationcomponentscanbesuccessfully
deployed. Duringthisphase, user requeststo
theapplicationbeingdeployedarenotallowed.
Failuresencounteredduringthedistributionand
validationprocesswill resultinthedeployment
beingabortedonall server instances—
includingthoseuponwhichthevalidation
succeeded. Filesthathavebeenstagedwill not
beremoved; however, container-sidechanges
performedduringthepreparationwill be
reverted.
Second Phase of Deployment
After theapplicationcomponentshavebeen
distributedtotargetsandvalidated, they are
fully deployedonthetargetserver instances,
andthedeployedapplicationismadeavailable
toclients.
Whenafailureisencounteredduringthe
secondphaseof deployment, theserver starts
withoneof thefollowingbehaviors:
■ If afailureoccurswhiledeployingtothe
targetserver instances, theserver instancewill
startinADMIN state.
■ If cluster member failstodeploy an
application, theapplicationthatfailedto
deploy is made unavailable.

18. Guidelines for Deploying to a
Cluster
● Ideally, all ManagedServersinacluster shouldberunningandavailableduringthe
deploymentprocess. Deployingapplicationswhilesomemembersof thecluster are
unavailableisnotrecommended. Beforedeployingapplicationstoacluster, ensure,
if possible, thatall ManagedServersinthecluster arerunningandreachableby the
AdministrationServer.
● Cluster membershipshouldnotchangeduringthedeploymentprocess. After
initiatingdeployment, donot:
■ addor removeManagedServerstothetargetcluster
■ shutdownManagedServersinthetargetcluster

19. Load Balancing in a Cluster
■ "LoadBalancingfor ServletsandJSPs"
■ "LoadBalancingfor EJBsandRMI Objects"
■ "LoadBalancingfor JMS"
■ "LoadBalancingfor JDBC Connections"

20. LoadBalancingfor ServletsandJSPs
Load Balancing with a Proxy Plug-in
● The WebLogic proxy plug-in maintains a list of WebLogic Server
instances that host a clustered servlet or JSP, and forwards HTTP
requests to those instances on a round-robin basis.
● The plug-in also provides the logic necessary to locate the replica of a
client's HTTP session state if a WebLogic Server instance should fail.
● WebLogic Server supports the following Web servers and associated
proxy plug-ins:
■ WebLogic Server with the HttpClusterServlet
■ Netscape Enterprise Server with the Netscape
(proxy) plug-in
■ Apache with the Apache Server (proxy) plug-in
■ Microsoft Internet Information Server with the
Microsoft-IIS (proxy) plug-in

21. LoadBalancingfor ServletsandJSPs
Load Balancing HTTP Sessions with an External Load Balancer
· Passive Cookie Persistence
Passive cookie persistence enables WebLogic Server to write a cookie containing session parameter
information through the load balancer to the client. For information about the session cookie and how a
load balancer uses session parameter data to maintain the relationship between the client and the
primary WebLogic Server hosting a HTTP session state,
· Active Cookie Persistence
You can use certain active cookie persistence mechanisms with WebLogic Server clusters, provided the
load balancer does not modify the WebLogic Server cookie. WebLogic Server clusters do not support
active cookie persistence mechanisms that overwrite or modify the WebLogic HTTP session cookie. If
the load balancer's active cookie persistence mechanism works by adding its own cookie to the client
session, no additional configuration is required to use the load balancer with a WebLogic Server
cluster.
· SSL Persistence
When SSL persistence is used, the load balancer performs all encryption and decryption of data
between clients and the WebLogic Server cluster. The load balancer then uses the plain text cookie that
WebLogic Server inserts on the client to maintain an association between the client and a particular
server in the cluster.

22. Load Balancing for EJBs and RMI
Objects
Round-Robin Load Balancing● WebLogicServer usestheround-robinalgorithmasthedefaultloadbalancing
strategy for clusteredobjectstubswhennoalgorithmisspecified. Thisalgorithmis
supportedfor RMI objectsandEJBs. Itisalsothemethodusedby WebLogic proxy
plug-ins.
● Theround-robinalgorithmcyclesthroughalistof WebLogicServer instancesin
order.
● For clusteredobjects, theserver listconsistsof WebLogicServer instancesthathost
theclusteredobject. For proxy plug-ins, thelistconsistsof all WebLogicServer
instancesthathosttheclusteredservletor JSP.
● Theadvantagesof theround-robinalgorithmarethatitissimple, cheapandvery
predictable. Theprimary disadvantageisthatthereissomechanceof convoying.
● Convoyingoccurswhenoneserver issignificantly slower thantheothers. Because
replica-awarestubsor proxy plug-insaccesstheserversinthesameorder, aslow
server cancauserequeststo"synchronize" ontheserver, thenfollow other servers
inorder for futurerequests.

23. Load Balancing for EJBs and RMI
Objects
Weight-Based Load BalancingThisalgorithmappliesonly toEJB andRMI objectclustering.
Weight-basedloadbalancingimprovesontheround-robinalgorithmby takingintoaccountapre-
assignedweightfor eachserver. YoucanusetheServer >Configuration >Cluster pageinthe
AdministrationConsoletoassigneachserver inthecluster anumerical weightbetween1and100,
intheCluster Weight field. Thisvaluedetermineswhatproportionof theloadtheserver
will bear relativetoother servers. If all servershavethesameweight, they will eachbear anequal
proportionof theload. If oneserver hasweight50andall other servershaveweight100, the50-
weightserver will bear half asmuchasany other server. Thisalgorithmmakesitpossibletoapply
theadvantagesof theround-robinalgorithmtoclustersthatarenothomogeneous.
If youusetheweight-basedalgorithm, carefully determinetherelativeweightstoassigntoeach
server instance. Factorstoconsider include:
■ Theprocessingcapacity of theserver'shardwareinrelationshiptoother servers(for example,
thenumber andperformanceof CPUsdedicatedtoWebLogic Server).
■ Thenumber of non-clustered("pinned") objectseachserver hosts. If youchangethespecified
weightof aserver andrebootit, thenew weightinginformationispropagatedthroughoutthe
cluster viathereplica-awarestubs.

24. Load Balancing for EJBs and RMI
Objects
Random Load Balancing● Therandommethodof loadbalancingappliesonly toEJB andRMI object
clustering.
● Inrandomloadbalancing, requestsareroutedtoserversatrandom. Randomload
balancingisrecommendedonly for homogeneouscluster deployments, whereeach
server instancerunsonasimilarly configuredmachine. A randomallocationof
requestsdoesnotallow for differencesinprocessingpower amongthemachines
upon
● whichserver instancesrun. If amachinehostingserversinacluster hassignificantly
lessprocessingpower thanother machinesinthecluster, randomloadbalancing
will givethelesspowerful machineasmany requestsasitgivesmorepowerful
machines.
● Randomloadbalancingdistributesrequestsevenly acrossserver instancesinthe
cluster, increasingly soasthecumulativenumber of requestsincreases. Over asmall
number of requeststheloadmay notbebalancedexactly evenly.
● Disadvantagesof randomloadbalancingincludetheslightprocessingoverhead
incurredby generatingarandomnumber for eachrequest, andthepossibility that
theloadmay notbeevenly balancedover asmall number of requests.

25. Load Balancing for EJBs and RMI
Objects
Server Affinity Load Balancing Algorithms
● WebLogicServer providesthreeloadbalancingalgorithmsfor RMI objectsthat
provideserver affinity. Server affinity turnsoff loadbalancingfor external client
connections; instead, theclientconsidersitsexistingconnectionstoWebLogic
Server instanceswhenchoosingtheserver instanceonwhichtoaccessanobject. If
anobjectisconfiguredfor server affinity, theclient-sidestubattemptstochoosea
server instancetowhichitisalready connected, andcontinuestousethesame
server instancefor methodcalls. All stubsonthatclientattempttousethatserver
instance. If theserver instancebecomesunavailable, thestubsfail over, if possible,
toaserver instancetowhichtheclientisalready connected.
● Thepurposeof server affinity istominimizethenumber IP socketsopenedbetween
external Javaclientsandserver instancesinacluster. WebLogicServer
accomplishesthisby causingmethodcallsonobjectsto"stick" toanexisting
connection, insteadof beingloadbalancedamongtheavailableserver instances.
Withserver affinity algorithms, thelesscostly server-to-server connectionsarestill
load-balancedaccordingtotheconfiguredloadbalancingalgorithm—load
balancingisdisabledonly for external clientconnections.

26. Load Balancing for EJBs and RMI
Objects
Parameter-Based Routing for Clustered Objects
Parameter-basedroutingallowsyoutocontrol loadbalancingbehavior at
alower level. Any clusteredobjectcanbeassignedaCallRouter. This
isaclassthatiscalledbeforeeachinvocationwiththeparametersof the
call. TheCallRouter isfreetoexaminetheparametersandreturnthe
nameserver towhichthecall shouldberouted.

27. Load Balancing for EJBs and RMI
Objects
Optimization for Collocated Objects
WebLogicServer doesnotalwaysloadbalanceanobject'smethodcalls. Inmostcases,
itismoreefficienttouseareplicathatiscollocatedwiththestubitself, rather thanusing
areplicathatresidesonaremoteserver.

28. Load Balancing for JMS
Server Affinity for Distributed JMS Destinations
Server affinity issupportedfor JMS applicationsthatusethedistributeddestination
feature; thisfeatureisnotsupportedfor standalonedestinations. If youconfigureserver
affinity for JMS connectionfactories, aserver instancethatisloadbalancingconsumers
or producersacrossmultiplemembersof adistributeddestinationwill firstattemptto
loadbalanceacrossany destinationmembersthatarealsorunningonthesameserver
instance.

29. Load Balancing for JMS
Initial Context Affinity and Server Affinity for Client
Connections
● A systemadministrator canestablishloadbalancingof JMS destinationsacross
multipleserversinacluster by configuringmultipleJMS serversandusingtargets
toassignthemtothedefinedWebLogicServers. EachJMS server isdeployedon
exactly oneWebLogicServer andhandlesrequestsfor asetof destinations. During
theconfigurationphase, thesystemadministrator enablesloadbalancingby
specifyingtargetsfor JMS servers.
● A systemadministrator canestablishcluster-wide, transparentaccesstodestinations
fromany server inthecluster by configuringmultipleconnectionfactoriesand
usingtargetstoassignthemtoWebLogicServers. Eachconnectionfactory canbe
deployedonmultipleWebLogicServers.

30. Load Balancing for JMS
Initial Context Affinity and Server Affinity for Client
Connections
● TheapplicationusestheJavaNamingandDirectory Interface(JNDI) tolook upa
connectionfactory andcreateaconnectiontoestablishcommunicationwithaJMS
server. EachJMS server handlesrequestsfor asetof destinations. Requestsfor
destinationsnothandledby aJMS server areforwardedtotheappropriateserver.
● WebLogicServer providesserver affinity for clientconnections. If anapplication
hasaconnectiontoagivenserver instance, JMS will attempttoestablishnew JMS
connectionstothesameserver instance.
● Whencreatingaconnection, JMS will try firsttoachieveinitial contextaffinity. It
will attempttoconnecttothesameserver or serverstowhichaclientconnectedfor
itsinitial context, assumingthattheserver instanceisconfiguredfor thatconnection
factory. For example, if theconnectionfactory isconfiguredfor serversA andB,
buttheclienthasanInitialContextonserver C, thentheconnectionfactory will not
establishthenew connectionwithA, butwill choosebetweenserversB andC.

31. Load Balancing for JDBC
Connections
● Loadbalancingof JDBC connectionrequirestheuseof amulti datasource
configuredfor loadbalancing. Loadbalancingsupportisanoptionyoucanchoose
whenconfiguringamulti datasource.
● A loadbalancingmulti datasourceprovidesthehighavailablebehavior and, in
addition, balancestheloadamongthedatasourcesinthemulti datasource. A multi
datasourcehasanorderedlistof datasourcesitcontains. If youdonotconfigure
themulti datasourcefor loadbalancing, italwaysattemptstoobtainaconnection
fromthefirstdatasourceinthelist. Inaload-balancingmulti datasource, thedata
sourcesitcontainsareaccessedusingaround-robinscheme. Ineachsuccessive
clientrequestfor amulti datasourceconnection, thelistisrotatedsothefirstpool
tappedcyclesaroundthelist.

32. Load Balancing and Replication
■ "LoadBalancingfor ServletsandJSPs"
■ "LoadBalancingfor EJBsandRMI Objects"
■ "LoadBalancingfor JMS"
■ "LoadBalancingfor JDBC Connections"