There are benefits to placing artifacts in a common location that multiple hosts or servers share. This common location typically resides in a shared file system, which is mounted on each server with standard operating system protocols such as NFS and CIFS.
Shared storage allows sharing of dynamic state and server configuration. It simplifies administration, configuration, failover, and backup/recovery.
In a highly available environment, shared storage is required when you use file based persistent stores (for JMS and JTA logs) and certain Oracle products. Shared storage is optional for product binaries and domain directories.
The following artifacts are typical candidates to place on a shared file system:
Product binaries: All files and directories related to product executables, JAR files, and scripts that install during product installation.
Domain directory: Directory containing WebLogic Server domains and their configuration.
File-based persistent stores: File-based persistent stores for JMS persistence and JTA transaction logs.
Table 4-1 has more information about shared storage.
Table 4-1 Shared Storage Topics
|Topic/Task||For More Information|
Structure and contents of an Oracle home
Understanding the Oracle Fusion Middleware Infrastructure Directory Structure in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure
Saving JMS and JTA information in a file store
The WebLogic Persistent Store in Administering the WebLogic Server Persistent Store.
Persistent Store High Availability in Administering JMS Resources for Oracle WebLogic Server.
Default File Store Availability for JTA in Administering Clusters for Oracle WebLogic Server.
There are shared storage prerequisites that apply only when you use file-based persistent stores.
For proper recovery in the event of a failure, you must store both JMS and JTA transaction logs in a location that is accessible to all nodes that can resume operations after a failure. This setup requires a shared storage location that multiple nodes can reference. See Directory Structure and Configurations for the recommended directory structure.
Oracle recommends that you use a shared storage device that is network-attached storage (NAS) or storage area network (SAN).
If you use NFS-mounted systems, issues related to file locking and abrupt node failures have been detected. See Using File Stores on NFS and check with your storage vendor for the main recommended parameters for mount options.
The following example command is based on a NAS device. Note: your options may be different from those in this example; see UNIX/Linux documentation for more on the mount command.
mount nasfiler:/vol/vol1/u01/oracle /u01/oracle -t nfs -o rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
For maximum availability, Oracle recommends a highly available NAS or SAN device for shared storage. Shared storage devices that are not highly available can be a single point of failure. Check with your storage provider for options to achieve this.
For more information about saving JMS and JTA information in a file store, see The WebLogic Persistent Store in Administering the WebLogic Server Persistent Store.
Oracle has guidelines for using shared storage for your Oracle home directories.
When you install any Oracle Fusion Middleware product, you install product binaries into an Oracle home (ORACLE_HOME). The binary files are read-only and don't change unless you patch or upgrade the Oracle home to a newer version
In a typical production environment, you save Oracle home files in a separate location from domain configuration files, which you create using the Configuration Wizard.
The Oracle home for an Oracle Fusion Middleware installation contains binaries for Oracle WebLogic Server, Oracle Fusion Middleware infrastructure files, and any Oracle Fusion Middleware product-specific directories.
The Configuration Wizard writes its logs to the
logs directory in Oracle home. If you use a read-only Oracle home, you must specify the
-log option to redirect logs to a different directory.
For more on the Oracle home structure and contents, see "What are the Key Oracle Fusion Middleware Directories?" in Oracle Fusion Middleware Understanding Oracle Fusion Middleware Concepts.
You can configure multiple servers from one Oracle home. The benefit is that you can install the Oracle home in one location on a shared volume and reuse the Oracle home for multiple servers.
If multiple servers on different hosts share an Oracle home, there are some best practices to keep in mind. For example, because the Oracle inventory directory (
oraInventory) is updated only on the host from which the Oracle home was originally installed, Oracle recommends that you perform all subsequent operations on the Oracle home (such as patching and upgrade) from that original host. If that host is unavailable, ensure that the Oracle inventory is updated on another host before you apply patches or upgrades to the Oracle home from the other host.
For more information about
oraInventory, see Oracle Universal Installer Inventory.
For maximum availability, Oracle recommends using redundant binary installations on shared storage.
In this model:
Each Oracle home has the same mount point, so the Oracle home always has the same path, regardless of which Oracle home the server is using.
If one Oracle home becomes corrupted or unavailable, only half your servers are affected. For additional protection, Oracle recommends that you disk mirror these volumes. To restore affected servers to full functionality, you can simply remount the surviving Oracle Home.
If separate volumes are not available on shared storage, Oracle recommends simulating separate volumes using different directories within the same volume and mounting these to the same mount location on the host side. Although this doesn't guarantee the protection that multiple volumes provide, it does protect from user deletions and individual file corruption.
For maximum protection, Oracle recommends that you evenly distribute the members of a cluster across redundant binary Oracle homes. This is particularly important if cluster members are not running on all available servers.
There are guidelines for using shared storage for the Oracle WebLogic Server domain configuration files that you create when you configure Oracle Fusion Middleware products in an enterprise deployment.
When you configure an Oracle Fusion Middleware product, you create or extend an Oracle WebLogic Server domain. Each domain consists of a single Administration Server and one or more Managed Servers.
WebLogic uses a replication protocol to push persisted changes on the Administration Server to all s. This gives redundancy to the s so that you can start them without the Administration Server running. This mode is called independence.
For more information about Oracle WebLogic Server domains, see Understanding Oracle WebLogic Server Domains.
Oracle doesn't require you to store domain configuration files in shared storage. However, to support Administration Server recovery, you must place the Administration Server configuration directory on shared storage and mount it on the host that the Administration Server runs on.
If that host fails, you can mount the directory on a different host and bring up the failed Administration Server on the other host. See Administration Server High Availability.
Oracle recommends that you keep Managed Server configuration files in local, or, host private, storage.
You can keep Managed Server configuration files on shared storage. However, doing so can affect performance because multiple servers concurrently access the same storage volume.
When you use file-based persistence in a high availability setup, you must configure the JMS persistent stores and JTA transaction log directories to reside in shared storage.
For more information, see Using File Persistence (WebLogic JMS).
When you use shared storage, there are multiple ways to lay out storage elements. Oracle recommends certain best practices.
Table 4-2 Shared Storage Elements Directory Structure
Share in read-only mode by all servers.
JMS file stores and Transaction logs
Place on shared storage if you use file-based persistence.
Administration Server domain configuration directory
Place in shared storage to facilitate failing over the Administration Server to a different host.
Place domain configuration directories on storage that is local to the corresponding host. See Shared Storage Considerations for Administration Server Configuration Directory for more information.
Figure 4-1 illustrates the directory structure.
Figure 4-1 Shared Storage Directory Structure