Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

8. Configuring High Availability for BAM > Preparing your HA environment

Preparing your HA environment

Preparing your HA environment Setting up your environment, such as operating systems, databases, networking, storages, and so on, is the prerequisite for configuring your HA environment for BAM. In this section, you will learn how to perform these tasks to complete the setup of your environment. Configuring databases Oracle BAM stores its metadata and business transactional data in a repository, which requires a relational database (Oracle Database, IBM DB2, or Microsoft SQL Server). However, using Oracle Database is a common practice, especially in an HA environment. Throughout this chapter, Oracle Database will be used to illustrate the HA configuration details. Installing database schemas for SOA/BAM To install database schemas for SOA/BAM in an existing database, perform the following steps: Ensure that your Oracle database meets the following requirements before continuing to the next step: Oracle Database 10.2.0.4 or aboveOracle Database 11.1.0.7 or aboveOracle Database 11.2.0.1 or above To install the BAM schema, run the Repository Creation Utility (RCU) , which can be found in the SOA (BAM) installation package. RCU_HOME/bin/rcu In the Database Connection Details screen, provide the connection details.In the Select Components screen, select SOA and BPM Infrastructure, and click on Next.Complete the rest of the steps to set up passwords, and map table spaces. Setting up database parameters The processes parameter on an Oracle database instance represents the maximal number of open sessions (active database connections) allowed at the database side. As Oracle SOA Suite and Oracle BAM use their dedicated data sources to connect to the backend database, it is important to set the processes parameter to an appropriate value, so that SOA/BAM can always obtain database connections if needed. To set this parameter, perform the following steps: Connect to the database server as the sys user or a user with the DBA role.Run the following Oracle database command to determine the number of processes for the database instance: SQL> SHOW PARAMETER processes; Determine the appropriate value for the processes parameter. The recommended setting of the processes parameter is dependent on the Fusion Middleware components used in your system. For example, if you are using BAM, this parameter should be set to 100 or above. If you are using both SOA and BAM, it is recommended to set this parameter to 400 or above.To change the value of this parameter, run the following Oracle command, and then restart the database: SQL> ALTER SYSTEM SET processes=400 SCOPE=SPFILE Granting transactional recovery privileges You need to grant appropriate transaction recovery privileges to the BAM schema, so that the WebLogic Server transaction manager can handle transaction recoveries in case of WebLogic Server failure. To grant privileges to the BAM schema for the transaction recovery purpose, execute the following commands: SQL> Grant select on sys.dba_pending_transactions to <bam_schema>; Grant succeeded. SQL> Grant force any transaction to <bam_schema>; Grant succeeded. Grant these privileges to the SOA schema if SOA is used in your system. Choosing the recommended WebLogic Server topology A Weblogic Server topology represents a domain architecture that defines the deployment of WebLogic Server components, such as the Administration Server, Managed Servers, clusters, and machines. The following diagram depicts the recommended domain architecture for Oracle BAM: This domain architecture contains the following servers: AdminServer: This is the Administration Server assigned to ADMINHOST, which is the logical machine defined in the domain. The AdminServer instance runs on the bamhost1.mycompany.com host, while its listen address should be adminvhn.mycompany.com that resolves to VIP1.WLS_WSM1: This is the Managed Server that hosts the Web Service Manager. It listens on the physical IP (IP1).WLS_WSM2: This is the Managed Server that hosts the Web Service Manager. It listens on the physical IP (IP2).WLS_BAM1: This is the Managed Server that hosts both the BAM Server and the BAM web applications. WLS_BAM1 is assigned to the logical machine BAMHOST1, which runs on the bamhost1.mycompany.com host, and its listen address should be bamvhn.mycompany.com that resolves to VIP2.WLS_BAM2: This is the Managed Server that only hosts the BAM web applications. WLS_BAM2 is assigned to the logical machine BAMHOST2, which runs on the bamhost2.mycompany.com host, and its listen address should be set to bamhost2.mycompany.com that resolves to IP2. Note Oracle BAM uses a virtual hostname or Virtual IP (VIP) as the listen address for the Managed Server that hosts BAM Server components (for example, ADC, Report Cache, EMS, and so on). This virtual hostname and corresponding VIP are used for the server migration purpose, in case of server failure. For example, in the event of the bamhost1 server failure, the virtual IP (VIP2) enabled on bamhost1 can be switched on a different host (for example, bamhost2). After that, you can start WLS_BAM1 on bamhost2. Since the BAM Server still listens on VIP2, the failover is transparent from the client's perspective. The following table is an example of the hostname and IP mapping, which will be used throughout this chapter to demonstrate the BAM HA configuration:


Enabling IPs and VIPs In a single-node environment, the physical IP of the machine that hosts the BAM Server is used as the listen address. However, in an HA environment, VIPs are required to achieve the IP level virtualization, which is the key in the server migration process. Enabling IPs and VIPs is platform-specific. In this section, you will learn how to enable IPs and VIPs on Linux. Perform the following steps to enable IPs/VIPs on Linux: Edit the ifcfg-<interface:index> file in the /etc/sysconfig/network-scripts directory.<interface:index> is the variable that represents the network interface name and its index. For example, edit the ifcfg-eth0:0 for the first virtual IP, and ifcfg-eth0:1 for the second VIP on the same Network Interface Card (NIC).Add the following name value pairs to the configuration file. Modify the values to meet your requirements: DEVICE=eth0:0 IPADDR=10.0.0.2 GATEWAY=10.0.0.1 NETMASK=255.255.255.0 Log in as the root user, and run the following command to start the interface: /sbin/ifconfig <interface:index> up To learn more about IPs and VIPs, refer to the corresponding operating system administration guide. There are plenty of resources available on the web as well. For example, the following URL contains tutorials for Linux networking: http://www.yolinux.com/TUTORIALS/LinuxTutorialNetworking.html Configuring shared storage and domain structures Installing Fusion Middleware on a shared storage allows the same installation to be reused to create domains and the servers in different nodes. In this section, you will learn how to create a shared storage, and how to use the storage location to build domain structures. Understanding Fusion Middleware home directory structure The following diagram depicts the Fusion Middleware home directory structure: The following table depicts the description of these directories:


Managing the WebLogic Server domain directories It is recommended to separate the domain directory for the Administration Server from the domain directory of the Managed Servers. This topology allows a symmetric configuration for Managed Servers, so that you can easily duplicate the domain configurations for Managed Servers across the nodes. The domain directory for the Administration Server must reside in a shared storage to allow failover to another node with the same configuration. The domain directories for Managed Servers typically reside on a local disk. The following diagram depicts the recommended domain directory structure in an HA environment: See the following table for the description of the directory names:


Tip The dd and fadapter directories are specific to the Oracle SOA Suite. You do not need to create such directories if your domain only contains BAM components. Configuring a shared storage To meet the HA directory structure requirements, you need to configure a shared storage, which could be either a Network Attached Storage (NAS) or Storage Area Network (SAN) device, and then mount it to the host system using Network File System (NFS) protocol. NFS is a platform-independent technology created by Sun Microsystems that allows shared access to the files stored on computers through an interface called the Virtual File System (VFS) that runs on top of TCP/IP. Computers that share files are considered NFS servers, while those that access shared files are considered NFS clients. An individual computer can be an NFS server, an NFS client, or both. Even though it is highly recommended to use an NAS or SAN device as the shared storage solution in the production environment, you can create shared directories on a Linux server for testing purposes. In this section, we will demonstrate how to create the shared storage on Linux for a two-node cluster (bamhost1 and bamhost2). Creating the oracle user Perform the following steps to create the oracle user: On both bamhost1 and bamhost2, run the following commands to create the oracle user and the oinstall group, if they do not exist. Note that you must log in as root or a user with admin rights to run these commands: groupadd oinstall useradd g oinstall oracle On both bamhost1 and bamhost2, execute the id command to verify that the uid and gid attribute of the oracle user are identical on both nodes. Otherwise, use usermod to modify uid/gid. bamhost1> id oracle bamhost1> uid=1101(oracle) gid=1000(oinstall) groups=1000(oinstall) bamhost2> id oracle bamhost2> uid=1101(oracle) gid=1000(oinstall) groups=1000(oinstall) Creating NFS shares To create shared directories on Linux, perform the following steps: Log in to one of the compute nodes (for example,bamhost1) as oracle, and create the following directories: SHARED_DISK_BASE/product/fmw1 SHARED_DISK_BASE/product/fmw2 SHARED_DISK_BASE/admin/<domain_name>/aserver SHARED_DISK_BASE/admin/<domain_name>/aserver/applications SHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name> SHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name>/dd SHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name>/jms SHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name>/fadapter SHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs Note that SHARED_DISK_BASE is the root for all shared directories. The example code snippets use /u03 to replace SHARED_DISK_BASE. Edit the /etc/exports file as the super user (root), to export the following directories that you want to remotely access from multiple nodes in the cluster: SHARED_DISK_BASE/product/fmw1SHARED_DISK_BASE/product/fmw2SHARED_DISK_BASE/admin/<domain_name>/aserverSHARED_DISK_BASE/admin/<domain_name>/<soa_cluster_name> A sample configuration looks as follows: Log in as the root user, and run the following command on bamhost1 and bamhost2 to export these directories through NFS. chkconfig nfs on service nfs restart Mounting shared directories After these shared directories have been successfully exported, you need to mount them to the machine where BAM is to be installed. On bamhost1, mount the shared directories on a remote system to the following mount point:


On bamhost2, mount the shared directories on a remote system to the following mount points:


To mount these shared directories, perform the following steps: On both bamhost1 and bamhost2, create the following directories as the mount points: ORACLE_BASE/product/fmw ORACLE_BASE/admin/<domain_name>/aserver ORACLE_BASE/admin/<domain_name>/<soa_cluster_name> Edit /etc/fstab as the root user.Add the following shared locations and mount points to the /etc/fstab file. On bamhost1, mount SHARED_DISK_BASE/product/fmw1. On bamhost2, mount SHARED_DISK_BASE/product/fmw2. A sample fstab file looks as follows: Log in as the root user, and run the following command to mount NFS shares. mount ORACLE_BASE/product/fmw mount ORACLE_BASE/admin/<domain_name>/aserver mount ORACLE_BASE/admin/<domain_name>/<soa_cluster_name> Verifying NFS mounts Run the touch command to create a file under the following directories, and verify if these files can be viewed on bamhost1 and bamhost2: touch ORACLE_BASE/product/fmw/test.txt touch ORACLE_BASE/admin/<domain_name>/aserver/test.txt touch ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/test.txt

  

You are currently reading a PREVIEW of this book.

                                                                                                                    

Get instant access to over $1 million worth of books and videos.

  

Start a Free Trial


  
  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint