This recipe will identify the steps required to prepare the operating system for installation and configuration of an SOA Suite cluster. This recipe uses Linux as the operating system, the actual commands required vary between operating systems. These steps are required because SOA Suite high availability makes use of whole server migration.
Certain tasks mentioned in this recipe must be performed by a system administrator. As the installer of the SOA Suite does not necessarily have system administrator privileges for the operating system, it is a good idea to get all the tasks that require administrator privileges completed before starting the installation and configuration of the SOA Suite.
Grant sudo privileges to the Oracle user.
As root on each machine that will be hosting WebLogic servers, run the
visudocommand and add the following lines to the end of the file:# Node Manager Grants oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
oracleshould be replaced with the user you will be running SOA Suite under.Set up a shared mount point for use by the domain.
Write a file to the mount point from each machine and ensure that the files are readable and writable from all the other machines.
Set up a shared mount point for use by the Admin server.
Write a file to the Admin server mount point from each machine that will run the Admin server and ensure that the files are readable and writable from all the other machines that can run the Admin server.
Capture the mount points that will be used by the Admin server and by all other managed servers in a worksheet similar to the one as shown next:
Servers
Mount point
Admin server
/share/aserverManaged servers
/share/cluster
The granting of sudo privileges is used to allow the non-root user executing the WebLogic NodeManager to execute a limited subset of commands. These commands are used by the node manager to assign and register the virtual IP addresses used by the SOA managed servers and the BAM server. These commands are also used to unregister and release the virtual IP addresses.
Floating or virtual IP addresses are used by the SOA, Admin, and BAM servers to allow these servers to have the same IP address when they migrate from one machine to another.
When we run the configuration wizard to create our cluster, we will need to have a shared file location in which to create the domain. The Admin server shared file location is used to hold the domain configuration for the Admin server. The domain wide shared mount point is used to hold managed server domain directories as well as configuration plans. The EDG currently recommends using a shared filesystem for both server transaction logs (TLogs) and for JMS Queue storage. When migrating an Admin server, the shared storage for the Admin Server can be unmounted from the original machine and mounted on the new machine hosting the Admin server.
The shared filesystem may use a number of technologies, including SMB, NFS, NAS, and SAN technologies. The key is that the filesystem supports shared access.
It is possible to place the SOA Suite software onto shared storage. When doing this, Oracle recommends having at least two copies of the installed software to make it easier to patch and to reduce the risk of corruption.
Tip
Shared software installations
Certain shared storage configurations can cause very slow startup when the software is placed in shared storage because the classloader reads just a small amount from the disk for each class loaded. When the software disk is shared, it may not be able to cache reads and so classloading can introduce a lot of latency into the startup process. This can more than double the startup time for WebLogic servers. Once started and in the RUNNING state then they will not suffer a performance impact from having shared software storage.
Instead of using shared storage for TLogs and Queue stores, it is possible to place these in the database. This imposes a small performance overhead but simplifies fail over to a DR site because all the transaction logs and queues are replicated as part of the database replication to the DR site.
The Enterprise Deployment Guide, Chapter 14, Configuring Server Migration for an Enterprise Deployment, Section 14.6, Setting Environment and Superuser Privileges for the wlsifconfig.sh script (http://docs.oracle.com/cd/E23943_01/core.1111/e12036/server_migration.htm)
The Enterprise Deployment Guide, Chapter 4, Preparing the File System for an Enterprise Deployment, Section 4.3, About Recommended Locations for the Different Directories (http://docs.oracle.com/cd/E23943_01/core.1111/e12036/file_sys.htm)