WebLogic 10.3.5 Clustering Notes

Official Oracle Documentation on WebLogic Clustering is here

1. Click here for the recommended architecture
2. What means of cluster communications are considered ideal?
   The choice is between  Unicast and IP Sockets.  "When creating a new cluster, Oracle recommends that Unicast is used for messaging within a cluster.  Multicast is used only for backwards compatibility".
3. What about IP sockets?
   It seems that "IP sockets provide a simple, high-performance mechanism for transferring messages and data between two applications". Are IP sockets the best performance alternative? It seems to be.
4. We should use the native socket reader implementation
   "For best socket performance, configure the WebLogic Server host machine to use the native socket reader implementation for your operating system, rather than the pure-Java implementation." See here for instructions on how to configure native ip sockets
5. Deployment guidelines:
   1. Even though "partial" deployments are supported, it is better that all Servers in the cluster must are running during deployment
   2. Cluster membership should not change during the deployment process.
6. Load balancing, Software or Hardware?
   1. Software: use of HttpClusterServlet deployed as a front-end application.
   2. Hardware: Clusters that employ a hardware load balancing solution can use any load balancing algorithm supported by the hardware. These can include advanced load-based balancing strategies that monitor the utilization of individual machines. For load balancing hardware instead of a proxy plug-in, it must support a compatible passive or active cookie persistence mechanism, and SSL persistence.
   3. From this page, It seems that Round-Robin Load Balancing is the only method supported for Servlets/Jsps.  All other methods are for EJBs
7. Replication
   Coherence*Web seems to be a good option for Http session replication, particularly for large ADF applications that use jbo application modules.  See this page for more info.
8. Failover
1. Whole Server Migration: In the event of failure, the whole server is migrated to another web logic server in the cluster.  Used for failover of "pinned" services such as JMS and the JTA
2. Service Migration: In the event of failure of a service, the service is migrated to another web logic server in the cluster.

To be continued soon...

Copying a Weblogic 10.3.5 domain to another server.

It seems that it is possible to file copy a weblogic domain to another server.
In fact we tried xopy on a windows server the whole weblogic server installation and it worked like a charm. See this post
It is a little more complicated than a plain copy if your server uses SSL (read below)

You can file copy a weblogic domain to another server provided that:

1. The servers have identical directory structure for MIDDLEWARE_HOME.  In our case, it was /u01/app/oracle/product/middleware
2. The linux username is the same.  In our case, it was oracle.
3. The Fusion Middleware version is the same.  In our case it was 11.1.2.0
4. There is no cluster configured in the domain.  

Steps Involved:

1. Shutdown all weblogic servers and node manage in source server.
2. Go to the 'AdminServer' root directory (should be under  $MIDDLEWARE_HOME/user_projects/domains/domain name/servers/AdminServer ) and delete all sub-directories except the "security" directory. This includes tmp, data, cache, etc .  Do the same for all managed servers in the domain
3. Switch to domain root and execute command below to create a tar file with the domain contents.
   

   $ cd $MIDDLEWARE_HOME/user_projects/domains/
   $ tar -cvf mydomain.tar ./mydomain

4. Ftp / copy tar file to target server 
5. Login to target using weblogic server's user username and execute command below to extract tar file.
   

   $ cd $MIDDLEWARE_HOME/user_projects/domains
   $ tar -xvf domain.tar
   

6. After extraction of domain files:
   1. Update the domain registry of weblogic installation to include the new domain.
   2. You will have to search and replace the source machine's hostname with the targets machine's hostname inside any non binary file in the MIDDLEWARE_HOME. For our web logic installation it was only in 1 file. For the Middleware home, it was multiple files.
   3. ONLY for servers that utilize SSL:Generate a new DemoIdentity.jks file for use with nodemanager (The one copied over was for source host).

   $ cd $MIDDLEWARE_HOME/wlserver_10.3/server/lib/
   $ . ../bin/setWLSEnv.sh
   $ java utils.CertGen -cn targethost.com -keyfilepass
   $ java utils.CertGen -cn targethost.com -keyfilepass DemoIdentityPassPhrase -certfile testcert -keyfile testkey
   $ java utils.ImportPrivateKey newkeystore.jks DemoIdentityKeyStorePassPhrase demoidentity DemoIdentityPassPhrase testcert.pem testkey.pem
   $ keytool -v -list -keystore newkeystore.jks -storepass DemoIdentityKeyStorePassPhrase
   $ cp newkeystore.jks DemoIdentity.jks
   

7. Finally start the WebLogic nodemanager and servers on the target machine and verify that all is OK.

Yes, you can XCOPY a weblogic installation to another server

On Windows Servers (2003/2008), it is possible to xcopy the whole weblogic installation from one server to another, and it will actually work: All domains, servers and deployments work as expected. Even the Fusion Middleware worked as expected, with all the patches and megabytes of jars that Oracle shovels into the installation.

It goes without saying that: (1) the directory structure between the 2 servers should be identical, ie if on source Server weblogic was installed on c:\oracle\middleware, then on Server 2 it should be the same, (2) The Java jdk is installed at exactly the same path and (3) You will have to search and replace the hostnames inside configuration files in the installation.
While on destination server and assuming the source server is available over the network, the xcopy command is this:

xcopy \\server1\c$\oracle\middleware c:\oracle\middleware /E/ H

It is even a better approach to tar and compress the directory and then copy it. Just be sure to include any hidden files.

This is useful in cases where:

• You need to transfer an installation to another server, for example a failover server
• You need to transfer an installation from a staging virtual machine to production
• You need to restore a corrupted weblogic domain from backup.