Cluster and configuration of WebLogic

Directory (?) [-]

Cluster of 1.Weblogic
2. Planning before creating a WebLogic cluster
3. Start creating our WebLogic Cluster
1.1 Creating the total control side of the cluster aminserver
2.2 Creating nodes in a cluster mycluster1 mycluster2
3.3 How to start a cluster
4.JDBC Cluster
5. Project deployment to a clustered environment
6. Using Apache with WebLogic cluster integration
7.JMS Cluster

Directory

This article is to be picked up; http://blog.csdn.net/liuqiwen0512/article/details/7739421

First, the WebLogic cluster

Remember the cluster of Tomcat we talked about in the fifth day tutorial?

Two tomcat do node namely TOMCAT1, TOMCAT2, use Apache httpserver to do request to distribute.

Now look at the WebLogic cluster, in fact, it is similar.

The difference is:

1. Tomcat's cluster is implemented as two physically different Tomcat, two node, no master, no console (only through relatively rudimentary http://localhost:8080/manager/html, or HTTP/ localhost:9090/manager/html) to monitor each Tomcat node (where only monitor has no control);

If we are going to put our web application in order, we need to manually copy the files to each Tomcat WebApp directory separately.

1. The WebLogic cluster must have a master control, which can be seen, and then this master terminal we call it adminserver, and then under which can hang WebLogic cluster node, this node is not physically different two weblogic, Instead of different domain, we assume that domain1, Domain2 is a node of two weblogic clusters.

If we are going to put our web application in order, we just need to do it in the master console, and then the nodes that hang in the master console will automatically publish our web app to each node.

Therefore, the cluster to implement WebLogic must:

• Installing WebLogic
• Create a AdminServer domain
• Set up the cluster master terminal on AdminServer
• Create each node that you want to add to this cluster master, and also the domain

Ii. planning before creating a WebLogic cluster

According to the first section, we plan the weblogic of our experiments into 3 domain, each containing the following essential attributes:

• Adminconsole (total control side)

Logical name

Physical name (domain's system path)

Port number

Meter name (IP)

Login information (Username/password)

• Cluster Node1 (cluster node 1)

Logical name

Physical name (domain's system path)

Port number

Meter name (IP)

Login information (Username/password)

• Cluster Node2 (cluster Node 2)

Logical name

Physical name (domain's system path)

Port number

Meter name (IP)

Login information (Username/password)

We use a table to list the total control and each node in the cluster we are going to create:

Physical name	Logical name	Port number	Host name (IP)	Login information
\bea\user_projects\domains\adminserver	AdminServer	7001	localhost	Weblogic/password_1
\bea\user_projects\domains\server1	Mycluster1	7011	localhost	Weblogic/password_1
Bea\user_projects\domains\server2	Mycluster2	7012	localhost	Weblogic/password_1

Planning, you can start to create our cluster.

Iii. start creating our WebLogic Cluster 3.1 Create the total control side of the cluster (aminserver)

Windows:

Under Windows, Start the wizard that created domain by using the menu->oracleweblogic->weblogic Server 11gr1->tools->configuration Wizard.

Unix/linux:

Unix/linux down through

Cd/bea/wlserver/common/bin ./config.sh

To start the wizard that created domain.

Select "Create a new WebLogic domain", choose Next ( all following my steps with the interface to fill the parameters to go, all the user name, password, port number, IP, please according to the table in the first section of the parameters fill )

Next after the interface is similar, but there is a difference, notice oh, don't start too fast

The above is called the interface of the cluster broadcast address.

Because the cluster is broadcast (with unicast and multicast two kinds) to synchronize the nodes in the cluster, and each node in the session through the broadcast address for replication and synchronization, that is, the main control domain constantly and the sub-nodes below it to maintain communication, Often ask about each child node.

• Name: can be any
• Cluster Information transfer mode: There are unitcast and multicast two kinds, before the 11G version is multicast10g after the beginning of support unicast protocol. If multicast is specified, a multicast address must be specified, and the address and port can be weblogic default.

If you are in a domain environment, you will also need to configure this "multicast address" and "Multicast port" in the firewall to be opened in the firewall, with a protocol of both of TCP and UDP.

Look, right this is what we call the "logical topology of a cluster."

This is to specify the corresponding "Computer name/IP" for each node in the cluster, since our experiment is built on the same machine as the vertical cluster, so this step does not need to fill, direct next .

When you are done, you can start AdminServer

Then use Http://localhost:7001/console to view our cluster planning, such as:

In this way, we have completed the creation of a new domain and will be expanded into a cluster of the total control server, and on this we made a "cluster topology", then the following is to do:

• Create the cluster node in the topology map 1
• Create the cluster node in the topology map 2

3.2 Creating nodes in a cluster (Mycluster1, Mycluster2)

Start the configuration Wizard for WebLogic

According to the ordinary domain, is an ordinary domain to create ( for the sake of experimentation convenient our user name and password all is Weblogic/password_1):

• User_projects\domains\server1 (logical name: Mycluster1, Port: 7011)
• User_projects\domains\server2 (logical name: Mycluster2, Port: 7012)

Next, Next, create, finish.

You can create your own server2 with the same steps as above (the logical name is Mycluster2, Port: 7012).

3.3 How to start a cluster

Physical name	Logical name	Port number	Host name (IP)	Login information
\bea\user_projects\domains\adminserver	AdminServer	7001	localhost	Weblogic/password_1
\bea\user_projects\domains\server1	Mycluster1	7011	localhost	Weblogic/password_1
Bea\user_projects\domains\server2	Mycluster2	7012	localhost	Weblogic/password_1

Let's look at the table above to enter the command:

1. Start the master domain (the master domain must always be started first)

2. Start Node 1 ( the boot order between points does not matter)

3. Start Node 2 ( the boot order between points does not matter)

After all, the cluster can be managed by the admin console of the main control domain http://localhost:7001/console.

Iv. JDBC Cluster

With the cluster, we can put our JDBC, but this JDBC deployment and the previous stand-alone JDBC deployment is slightly different, before we refer to the eighth day to establish the JDBC step:

Good, stop, to this side, not the same place to come.

Hey, do not put this JDBC connection pool "target" is the scope of the wrong ha, we are now a cluster, to the scope of this JDBC connection pool is located on our cluster ha!

Let's test the data source we created.

All data sources on the two cluster were successfully deployed.

Here's one more thing:

Cluster deployment Words AdminServer is just a controller, through which the war program is automatically synced to all the nodes that hang underneath it, so the JDBC data source, Either JMS or EJB is bound to set the target as the scope to cluster instead of the adminserver itself, because AdminServer itself will not be anything.

V. Project deployment to a clustered environment

• Make sure that the last line of Web. XML in our project will contain:

<distributable/>

• Create a new Weblogic.xml file under the Web-inf directory of the project to be completed, with the following contents:

<?xml version= "1.0" encoding= "UTF-8"?> <weblogic-web-app xmlns= "HTTP://WWW.BEA.COM/NS/WEBLOGIC/90" > <session-descriptor> <debug-enabled>true</debug-enabled> <persistent-store-type>replicated</persistent-store-type> <sharing-enabled>true</sharing-enabled> </session-descriptor> <context-root>/cbbs</context-root> </weblogic-web-app>

This content enables your project to replicate sessions in a WebLogic cluster environment.

And then we can start deployment.

Here comes the same as the deployment of JDBC in the cluster, see:

Next, the next step until the [Finish] button lights up, click [Finish].

Click [Save] and [activate changes].

Let's see if the two cluster, Mycluster1 and Mycluster2, are being engineered, which is the equivalent of manually copying our war project into the WebApps directory of two Tomcat nodes, and WebLogic only needs to go through the main control domain. Automatically put the war project in all the sub-nodes below it.

Yes, sure enough, it's automatic. Even if I have the following 10 sub-nodes, it will only need to be adminserver on the first time, automatic synchronization.

Let's start the project up.

When you "serve all requests, and then look at the two-byte backend console, you can start synchronously:

Deployment success

Open two ie:

One input: Http://localhost:7011/cbbs

One input: Http://localhost:7012/cbbs

WebLogic Cluster deployment was successful, and then it was distributed in Apache.

Vi. using Apache and WebLogic cluster integration

Open the httpd.conf, and the following is what we added in the "Nineth Day" to remove:

LoadModule Weblogic_module modules/mod_wl_22.so <ifmodule mod_weblogic.c> Weblogichost localhost Weblogicport 7001 Matchexpression/cbbs/web-inf Matchexpression/cbbs/*web-inf Matchexpression/cbbs/*.action matchexpression/cbbs/servlet/* matchexpression/cbbs/*.jsp Matchexpression/cbbs/*fckeditor/editor/filemanager/connectors/*.* matchexpression/cbbs/fckeditor/editor/filemanager/connectors/* Wllogfile Logs/wlproxy.log </IfModule>

Change to the following paragraph

LoadModule Weblogic_module modules/mod_wl_22.so <ifmodule mod_weblogic.c> Include conf/weblogic.conf </IfModule>

The weblogic.conf file is then manually created in the Apache-installed conf directory, which reads as follows:

Weblogiccluster localhost:7011,localhost:7012 Matchexpression/cbbs/web-inf Matchexpression/cbbs/*web-inf Matchexpression/cbbs/*.action matchexpression/cbbs/servlet/* matchexpression/cbbs/*.jsp Matchexpression/cbbs/*fckeditor/editor/filemanager/connectors/*.* matchexpression/cbbs/fckeditor/editor/filemanager/connectors/*

Restart your Apache, enter: http://localhost/cbbs/index.jsp

Apache plus WebLogic cluster, done!

Vii. JMS Cluster

This is the detailed steps that I use to weblogic the Pega Rulz of the cluster deployment for each reference. Because the online about JMS under WebLogic How to do the cluster is not too much, so the steps recorded down share to everyone.

The JMS cluster is not the same as the JDBC cluster, it is not able to directly create the JMS source and then target it to our myclusterbroadcast .

• Instead, you need to build a single JMS server for each cluster, for example.

• and build Jmsmodule.

The scope of the module is target to our cluster (myclusterbroadcast).

Set up the module you will build topic, queue and corresponding topic connection factory or queue connectionfactory, right? Because we give Pega rulz to do the cluster using the topic way to publish the cluster, so we take the topic as an example, the establishment of the queue is the same.

• Click the Ktjmsmodule we created just now.

Point [New]

First Build Connection Factory

• There is an [advanced positioning] button in the new ConnectionFactory interface

• Point [New sub-deployment]

After filling in the name of the sub-deployment, according to the Tathagata "target"

After the point is completed, jump out the following interface

Now we can start to actually build our topic or the queue.

as I said earlier, we could not create a JMS source directly and then target it to our myclusterbroadcast . So we're going to cluster JMS on the Topic or queue, but we can build a distribute Topic, and then build a Topic of two sides, A topic connected to jmsserver1 a topic to jmsserver2, and then put this distribute topic positioning (target) to the two topic is our "Cluster JMS topic".

Click the [New] button in the JMD module

Select Theme (not distributed theme)

Each child deployment (sub deployment) needs to be positioned (target) on a JMS server.

This establishes the following:

• Topic1 Subtop1->jmsserver1
• Topic2 Subtop2->jmsserver2

Now, the contents of our JMS module are as follows:

• Create a "distributed Theme" (Distributetopic)

Click the New button in the JMS module and select "Distributed Theme"

Be sure to remember to change "Destination Type" to "Weighted".

Here's the Jndi name for the distributed topic: what we really need to do with the JMS topic of the cluster or the Jndi name of the queue, such as my product Pega Rulz need to use Ramtopicjndi in a clustered environment, this Jndi Name must fill in the Product Manual of the topic or queue name OH.

Click Next to assign all two new topic to this distribute topic

Point [Finish] button

In this way, the JMS distributed Theme (Topic) in a clustered environment is all built up, so don't forget to click "Activate Changes" above the left menu to save all the changes you just made.

Reprint: http://www.cnblogs.com/HondaHsu/p/4267972.html

Cluster and configuration of WebLogic