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.
As root on each machine that will be hosting WebLogic servers, run the visudo
command and add the following lines to the end of the file:
# Node Manager Grants oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
oracle
should be replaced with the user you will be running SOA Suite under.
Servers |
Mount point |
---|---|
Admin server |
|
Managed servers |
|
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.
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.
18.223.206.69