Weblogic cluster
0 likes162 views
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.
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"