Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence 11g Release 1 (11.1.1) Part Number E15722-03 |
|
|
PDF · Mobi · ePub |
This chapter describes how to create a domain and the first Oracle Business Intelligence Managed Server using the Oracle Business Intelligence Configuration Assistant, Oracle WebLogic Server Administration Console, and Oracle Enterprise Manager Fusion Middleware Control. Later, you will scale out the domain to add additional components. This is addressed in later chapters in this document.
Important:
Oracle strongly recommends that you read Oracle Fusion Middleware Release Notes for any additional installation and deployment considerations before starting the setup process.This chapter contains the following topics:
Section 5.1, "Creating a Domain and the bi_server1 Managed Server on APPHOST1"
Section 5.3, "Creating boot.properties for the Administration Server on APPHOST1"
Section 5.4, "Starting the Administration Server on APPHOST1"
Section 5.5, "Enabling Administration Server High Availability"
Section 5.7, "Setting the Listen Address for bi_server1 Managed Server"
Section 5.8, "Disabling Host Name Verification for the bi_server1 Managed Server"
Section 5.9, "Validating Oracle Business Intelligence on APPHOST1"
Section 5.11, "Registering Oracle HTTP Server with Oracle WebLogic Server"
Section 5.12, "Setting the Frontend URL for the Administration Console"
Section 5.13, "Validating Access Through Oracle HTTP Server"
Section 5.14, "Manually Failing Over the Administration Server to APPHOST2"
Run the Oracle Business Intelligence Configuration Assistant from the Oracle home directory to create a domain containing the Administration Server and the first Managed Server with Oracle Business Intelligence components.
Ensure that the database where you installed the Business Intelligence Platform schemas is running. For an Oracle RAC database, it is recommended that you ensure that all instances are running, so that the validation check that is performed in later steps is more reliable.
Change the directory to the location of the Configuration Assistant (created in Chapter 3, "Installing the Software"):
APPHOST1> cd ORACLE_HOME/bin
Start the Configuration Assistant:
APPHOST1> ./config.sh
In the Welcome screen, click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and then click Next.
The Create, Scale Out or Extend screen is displayed. In this screen, select Create New BI System, then enter the following:
User Name: weblogic
User Password: your_password
Domain Name: bifoundation_domain
Click Next.
In the Specify Installation Location screen, enter:
Middleware Home: ORACLE_BASE/product/fmw (dimmed)
Oracle Home: ORACLE_BASE/product/fmw/Oracle_BI1 (dimmed)
WebLogic Server Home: ORACLE_BASE/product/fmw/wlserver_10.3 (dimmed)
Domain Home: ORACLE_BASE/admin/domain_name/aserver/domain_name
The Domain Home must end with the domain name.
Instance Home: ORACLE_BASE/admin/instance1
Instance Name: instance1
Click Next.
In the Configure Components screen, select the following:
Oracle Business Intelligence
Business Intelligence Enterprise Edition
Business Intelligence Publisher
Real-Time Decisions
Click Next.
In the RPD Encryption Password screen, provide the following information:
RPD Password
Confirm RPD Password
This password is used for the sample repository called SampleAppLite.rpd that is included with the installed files.
Click Next.
In the BIPLATFORM Schema screen, provide the following information:
Database Type: Oracle Database
Connect String: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@BIEDG.MYCOMPANY.COM
BIPLATFORM Schema Username: prefix_BIPLATFORM
BIPLATFORM Schema Password: your_password
Click Next.
In the MDS Schema screen, verify the information. For example:
Database Type: Oracle Database
Connect String: CUSTDBHOST1:1521:CUSTDB1^CUSTDBHOST2:1521:CUSTDB2@BIEDG.MYCOMPANY.COM
MDS Schema Username: prefix_MDS
MDS Password: your_password
Click Next.
In the Configure Ports screen, select one the following:
Auto Port Configuration
Specify Ports using Configuration File
Click Next.
In the Specify Security Updates screen, choose whether you want to receive security updates from Oracle support and if you do, enter your e-mail address.
Click Next.
In the Summary screen, click Configure.
In the Configuration Progress screen, verify that all the Configuration Tools have completed successfully and click Next.
In the Complete screen, click Finish.
Usually, Node Manager is started automatically when config.sh completes. If Node Manager is not running for some reason, run these commands to start it on APPHOST1:
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
You must configure the location for all persistence stores to a directory visible from both nodes. Change all persistent stores to use this shared base directory.
Log into the Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistent Stores node. The Summary of Persistent Stores page is displayed.
In the Change Center, click Lock & Edit.
Click BipJmsStore and enter a directory that is located in the shared storage. This shared storage is accessible from both APPHOST1 and APPHOST2:
ORACLE_BASE/admin/domain_name/bi_cluster/jms
Click Save and then click Activate Changes.
The changes will not take effect until the Managed Server is restarted. Restart the Managed Server.
Create a boot.properties file for the Administration Server on APPHOST1. This file enables the Administration Server to start without prompting you for the administrator username and password.
Go to the following directory:
ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
In this directory, create a file called boot.properties using a text editor and enter the following lines in the file:
username=Admin_Username password=Admin_Password
Note:
When you start the Administration Server, the username and password entries in the file get encrypted. You start the Administration Server in Section 5.4, "Starting the Administration Server on APPHOST1." For security reasons, you want to minimize the time the entries in the file are left unencrypted. After you edit the file, you should start the server as soon as possible so that the entries get encrypted.Save the file and close the editor.
The Administration Server is started and stopped using Node Manager. However, the first start of the Administration Server with Node Manager requires changing the default username and password that the Configuration Assistant set for Node Manager. Follow these steps to start the Administration Server using Node Manager:
Use the Administration Console to update the Node Manager credentials:
Open a Web browser and go to http://APPHOST1:7001/console.
Log in as the administrator.
In the Change Center, click Lock & Edit to enable configuration changes.
Click domain_name, then Security, then General, and then expand the Advanced options at the bottom.
Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.
Click Save.
Click Activate Changes.
Stop the Administration Server process using one of the following methods:
Use Ctrl+C in the shell where it was started
Use the standard process identification and kill commands in the operating system
Log in to the Administration Console and click Servers under the Environment heading, then click the Control tab. Select AdminServer(admin) and click Shutdown.
Stop and restart Node Manager and enable dynamic registration, as follows:
Stop the running NodeManager process.
Run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to 'true' before starting Node Manager:
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh
Note:
You must use the StartScriptEnabled property to avoid class loading failures.Restart Node Manager and enable dynamic registration using the following commands:
APPHOST1> cd WL_HOME/server/bin
APPHOST1> export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
APPHOST1> ./startNodeManager.sh
Note:
It is important that you set -DDomainRegistrationEnabled=true whenever you start a Node Manager which must manage the Administration Server. If there is no Administration Server on this computer, and if this computer is not an Administration Server failover node, then Node Manager can be started as follows:APPHOST1> ./startNodeManager.sh
Start the Oracle WebLogic Scripting Tool (WLST) and connect to Node Manager with nmconnect
and the credentials set in step 1, and start the Administration Server using nmstart
:
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./wlst.sh
In the WLST shell, execute the following command:
wls:/offline>nmConnect('Admin_User','Admin_Pasword', 'APPHOST1','9556','domain_name','Domain_Home') wls:/nm/domain_name> nmStart('AdminServer')
For example:
wls:/offline>nmConnect('weblogic', 'my_password', 'APPHOST1' , '9556', 'bifoundation_domain' ,'/u01/app/oracle/admin/bifoundation_domain/aserver/ bifoundation_domain') wls:/nm/bifoundation_domain> nmStart('AdminServer')
Note:
APPHOST1 is the address of the node where the domain was created, not the listen address of the Administration Server. Also, the username and password are only used to authenticate connections between Node Manager and clients. They are independent from the server admin ID and password, and are stored in the ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager/nm_password.properties file.The Oracle WebLogic Server Administration Server is a singleton application, so it cannot be deployed in an active-active configuration. By default, the Administration Server is only available on the first installed node, and for this enterprise topology, it is available only on APPHOST1. If this node becomes unavailable, then the Administration Console and Fusion Middleware Control also become unavailable. To avoid this scenario, the Administration Server and the applications deployed to it must be enabled for high availability. The enterprise deployment architecture in this guide calls for the deploying the Administration Server on a disk shared between APPHOST1 and APPHOST2.
The process described in this guide initially deploys the Administration Server and the bi_server1 Managed Server on the shared disk mounted on APPHOST1, and then manually migrates the bi_server1 Managed Server domain information to the local file system. This process is necessary to overcome certain design constraints in the Oracle Universal Installer.
This section contains the following topics:
Section 5.5.2, "Create a Machine for the Administration Server"
Section 5.5.3, "Enabling the Administration Server to Listen on the Virtual IP Address"
Section 5.5.4, "Creating a Separate Domain Directory for the bi_server1 Managed Server"
Section 5.5.5, "Enabling Fusion Middleware Control Failover"
The Administration Server must be configured to listen on a virtual IP Address to enable it to seamlessly failover from one host to another. In case of a failure, the Administration Server, along with the virtual IP Address, can be migrated from one host to another.
However, before the Administration Server can be configured to listen on a virtual IP Address, one of the network interface cards on the host running the Administration Server must be configured to listen on this virtual IP Address. The steps to enable a virtual IP Address are completely dependent on the operating system.
Follow the steps in this section to enable a virtual IP Address on APPHOST1. In a UNIX environment, the command must be run as the root user:
On APPHOST1, run the ifconfig
command to get the value of the netmask. In a UNIX environment, run this command as the root user. For example:
[root@APPHOST1 ~] # /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:11:43:D7:5B:06 inet addr:139.185.140.51 Bcast:139.185.140.255 Mask:255.255.255.0 inet6 addr: fe80::211:43ff:fed7:5b06/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10626133 errors:0 dropped:0 overruns:0 frame:0 TX packets:10951629 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4036851474 (3.7 GiB) TX bytes:2770209798 (2.5 GiB) Base address:0xecc0 Memory:dfae0000-dfb00000
On APPHOST1, bind the virtual IP Address to the network interface card using ifconfig
. In a UNIX environment, run this command as the root user. Use a netmask value that was obtained in Step 1.
The syntax and usage for the ifconfig
command is as follows:
/sbin/ifconfig networkCardInterface Virtual_IP_Address netmask netMask
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Update the routing table using arping
. In a UNIX environment, run this command as the root user.
/sbin/arping -q -U -c 3 -I networkCardInterface Virtual_IP_Address
For example:
/sbin/arping -q -U -c 3 -I eth0 100.200.140.206
See also Section 2.2.3.1, "Enabling Virtual IPs for the Managed Servers" for information about enabling VIP2 and VIP3 for the Managed Servers on APPHOST1 and APPHOST2.
Create a new machine and assign the Administration Server to the new machine using the Administration Console.
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
In the Environment section of the Home page, click Machines.
On the Summary of Machines page, select the Machine that is associated with the Administration Server from under the Machines table and click Clone. For example: APPHOST1.MYCOMPANY.COM.
On the Clone a Machine page, enter the Name of the Machine under the Machine Identity section and click OK. For example, enter ADMINHOST as the machine name.
On the Summary of Machines page, click the newly created Machine link.
On the Settings page for the ADMINHOST machine, select the Servers tab.
Click Add under the Servers table.
On the Add a Server to Machine page, choose Select an existing server, and associate it with this machine option.
Choose the AdminServer from the drop-down menu.
Click Finish to associate the Administration Server with the Machine.
In the Change Center, click Activate Changes.
Ensure that you have performed the steps described in Section 5.5.1, "Enabling ADMINVHN on APPHOST1" before setting the Administration Server listen address.
Perform these steps to set the Administration Server listen address:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select AdminServer(admin) in the Names column of the table. The Setting page for AdminServer(admin) is displayed.
Set the Listen Address to ADMINVHN.
Click Save.
Click Activate Changes.
The changes will not take effect until the Administration Server is restarted. Follow these steps to restart the Administration Server:
In the Summary of Servers page, select the Control tab.
Select AdminServer(admin) in the table and then click Shutdown.
Start the Administration Server again from the command line, as follows:
APPHOST1> cd ORACLE_COMMON_HOME/common/bin APPHOST1> ./wlst.sh wls:/offline> nmConnect ('Admin_User','Admin_Password','APPHOST1','9556','domain_name','DOMAIN home') wls:/nm/domain_name> nmStart ('AdminServer')
Use the pack and unpack commands to separate the domain directory used by the Administration Server from the domain directory used by the bi_server1 Managed Server in APPHOST1.
Run the pack command on APPHOST1 to create a template pack using the following command. Make sure to pass managed=true to pack just the bi_server1 Managed Server domain information.
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain=path_to_installer_created_domain -template=templateName.jar -template_name=templateName
For example:
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain= ORACLE_BASE/admin/bifoundation_domain/aserver/bifoundation_domain -template=/tmp/managedServer.jar -template_name=ManagedServer_Template
Run the unpack command on APPHOST1 to unpack the template to the domain directory of the Managed Server using the following command:
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1> ./unpack.sh -domain=path_to_domain_on_LocalFileSystem -template=templateName.jar -app_dir=path_to_applications_dir_on_LocalFileSystem
For example:
APPHOST1> cd ORACLE_HOME/common/bin APPHOST1>./unpack.sh -domain= ORACLE_BASE/admin/bifoundation_domain/mserver/bifoundation_domain -template=/tmp/managedServer.jar -app_dir= ORACLE_BASE/admin/bifoundation_domain/mserver/applications
Restart the bi_server1 Managed Server on APPHOST1, as follows (ensure that Node Manager is up and running):
Log in to the Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Start.
To enable Fusion Middleware Control failover, copy the em.ear file from the MW_HOME/user_projects/applications/bifoundation_domain directory to the equivalent directory on all nodes where Administration Server HA might be performed. In some cases, you might need to create the MW_HOME/user_projects/applications/bifoundation_domain directory on the other nodes.
Perform these steps to ensure that the Administration Server is properly configured:
Open a Web browser and go to http://ADMINVHN:7001/console.
Log in as the administrator.
Check that you can access Fusion Middleware Control at:
http://ADMINVHN:7001/em
Log in to Fusion Middleware Control with the username and password you specified in Section 5.3, "Creating boot.properties for the Administration Server on APPHOST1."
Ensure that you have performed the steps described in Section 2.2.3.1, "Enabling Virtual IPs for the Managed Servers" before setting the bi_server1 listen address.
Perform these steps to set the listen address for the Managed Server:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server1 in the Names column of the table. The Setting page for bi_server1 is displayed.
Set the Listen Address to APPHOST1VHN1.
Click Save.
Click Activate Changes.
The changes will not take effect until the bi_server1 Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
After the server has shut down, select bi_server1 in the table and then click Start.
Restart the Oracle Business Intelligence system components, as follows:
cd ORACLE_BASE/admin/instances/instance1/bin
./opmnctl restartproc
Follow the steps in this section to update the WebLogic JNDI URL for the Oracle BI Publisher Scheduler.
To update the Oracle BI Publisher Scheduler configuration:
Log in to Oracle BI Publisher at the following URL:
http://APPHOST1VHN1:9704/xmlpserver
Click the Administration link.
Click Scheduler Configuration under System Maintenance. The Scheduler Configuration screen is displayed.
Update the WebLogic JNDI URL under JMS Configuration, as follows:
t3://APPHOST1VHN1:9704
Click Test JMS.
You should receive a confirmation message that JMS tested successfully.
Click Apply. The changes are sent to the cluster to be applied at run time.
Check the Scheduler status from the Scheduler Diagnostics tab.
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 7, "Setting Up Node Manager"). If you have not configured the server certificates, you will receive errors when managing the different Oracle WebLogic Server. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again after the EDG topology configuration is complete as described in Chapter 7, "Setting Up Node Manager."
Perform these steps to disable host name verification:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server1 in the Names column of the table. The settings page for the server is displayed.
Open the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to 'None'.
Click Save.
Click Activate Changes.
The change will not take effect until the bi_server1 Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
Select bi_server1 in the table and then click Start.
Restart the Oracle Business Intelligence system components, as follows:
cd ORACLE_BASE/admin/instance1/bin
./opmnctl stopall
./opmnctl startall
Access the following URLs:
Access http://APPHOST1VHN1:9704/analytics
to verify the status of bi_server1.
Access http://APPHOST1VHN1:9704/wsm-pm
to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.
Note: The configuration is incorrect if no policies or assertion templates appear.
Access http://APPHOST1VHN1:9704/xmlpserver
to verify the status of the Oracle BI Publisher application.
Access http://APPHOST1VHN1:9704/ui
to verify the status of the Oracle Real-Time Decisions application.
Access http://APPHOST1VHN1:9704/bioffice/about.jsp
to verify the status of the Oracle BI for Microsoft Office application.
This section covers how to configure Oracle HTTP Server for the Administration Server and for the bi_server1 Managed Server.
This section contains the following topics:
Section 5.10.1, "Configuring Oracle HTTP Server for the Administration Server"
Section 5.10.2, "Configuring Oracle HTTP Server for the bi_servern Managed Servers"
To enable Oracle HTTP Server to route to the Administration Server, you must set the corresponding mount points in your HTTP server configuration:
For each of the Web servers on WEBHOST1 and WEBHOST2, create a file called admin.conf in the following directory:
ORACLE_INSTANCE/config/OHS/component/moduleconf
Then, add the following lines to this file:
NameVirtualHost *:80 <VirtualHost *:80> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # Admin Server and EM <Location /console> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /consolehelp> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /em> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost>
Note that the value for the VirtualHost parameters depends on how the LBR virtual host was set up. You might need to use a different value than the one shown, such as 7777.
Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2, as follows:
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
To enable Oracle HTTP Server to route to bi_cluster, which contains the bi_servern Managed Servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster:
On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:
#redirect browser requests that omit document/dir RedirectMatch 301 /analytics$ /analytics/ RedirectMatch 301 /bimiddleware$ /bimiddleware/ RedirectMatch 301 /xmlpserver$ /xmlpserver/ RedirectMatch 301 /ui$ /ui/ # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BIEE Analytics <Location /analytics> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /analytics-ws> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /bimiddleware> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # MapViewer <Location /mapviewer> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BI Publisher <Location /xmlpserver> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Oracle RTD <Location /ui> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /rtis> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /schema> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /ws> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> # BI Office <Location /bioffice> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location> <Location /biofficeclient> SetHandler weblogic-handler WebLogicCluster APPHOST1VHN1:9704,APPHOST2VHN1:9704 WLProxySSL ON WLProxySSLPassThrough ON </Location>
Note:
Add other resources as appropriate (such as analyticsRes or ActionSamples to support functionality in SampleApp.rpd).Make sure the httpd.conf file located in the same directory as the mod_wl_ohs file contains the following lines:
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName https://bi.mycompany.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost> NameVirtualHost *:7777 <VirtualHost *:7777> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost>
Note:
Values such as bi.mycompany.com:443, admin.mycompany.com:80 and you@your.address that are noted in this document serve as examples only. Enter values based on the actual environment.Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2, as follows:
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
The servers specified in the WebLogicCluster parameters are only important at startup time for the plug-in. The list must provide at least one running cluster member for the plug-in to discover other members in the cluster. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.
Sample scenarios include:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered dynamically at run time.
Example 2: You have a three-node cluster, but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all the members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started. For more information on configuring the WebLogic Server plug-in, see Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server.
For security purposes, and because the load balancer terminates SSL requests (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), after SSL is configured for the load balancer, turn on the WebLogic Plugin Enabled flag for the domain. To do this, follow these steps:
Log in to the Administration Console.
Click the domain name in the navigation tree on the left.
Click the Web Applications tab.
In the Change Center, click Lock & Edit.
Select WebLogic Plugin Enabled.
Click Save, then click Activate Changes.
Restart the Administration Server and Managed Server.
For Fusion Middleware Control to be able to manage and monitor Oracle HTTP Server instances, they must be registered with the domain. To do this, you must register Oracle HTTP Server with Oracle WebLogic Server using the following command:
WEBHOST1> cd ORACLE_INSTANCE/bin
WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic
You must also run this command from WEBHOST2 for OHS2.
Note:
After registering Oracle HTTP Server, it should appear as a manageable target in Fusion Middleware Control. To verify this, log in to Fusion Middleware Control. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.The Administration Console application tracks changes made to ports, channels and security using the console. When changes made through the console are activated, the console validates its current listen address, port, and protocol. If the listen address, port, and protocol are still valid, the console redirects the HTTP request replacing the host and port information with the Administration Server's listen address and port. When the Administration Console is accessed using a load balancing router (LBR), it is required to change the Administration Server's frontend URL so that the user's Web browser is redirected to the appropriate LBR address. To do this, follow these steps:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select AdminServer(admin) in the Names column of the table. The settings page for AdminServer(admin) is displayed.
Click the Protocols tab.
Click the HTTP tab.
Set the Frontend Host field to admin.mycompany.com
(your LBR address).
Set the Frontend HTTP Port to 80.
Click Save, then click Activate Changes.
To eliminate redirections, it is recommended that you disable the Administration Console's "Follow changes" feature. To do this, log in to the Administration Console and click Preferences, and then Shared Preferences. Clear the Follow Configuration Changes option, and then click Save.
Verify that the server status is reported as 'Running' in the Administration Console. If the server is shown as 'Starting' or 'Resuming,' wait for the server status to change to 'Started.' If another status is reported (such as 'Admin' or 'Failed'), check the server output log files for errors.
This section contains the following topics:
Validate the Administration Console and Fusion Middleware Control through both Oracle HTTP Server instances using the following URLs:
http://WEBHOSTn:7777/console
http://WEBHOSTn:7777/em
Note:
After setting the frontend URL to the LBR address, the access to the console through the WEBHOSTn addresses will be redirected by the console to the frontend URL, thus validating the correct configuration of both Oracle HTTP Server and the LBR device.http://admin.mycompany.com/console
http://admin.mycompany.com/em
For information on configuring system access through the load balancer, see Section 2.2.2, "Load Balancers."
Validate bi_cluster through Oracle HTTP Server using the following URLs (for both WEBHOST1 and WEBHOST2):
http://WEBHOSTn:7777/analytics
http://WEBHOSTn:7777/mapviewer
http://WEBHOSTn:7777/xmlpserver
http://WEBHOSTn:7777/ui
http://WEBHOSTn:7777/wsm-pm
http://WEBHOSTn:7777/bioffice/about.jsp
For information on configuring system access through the load balancer, see Section 2.2.2, "Load Balancers."
In case a node fails, you can fail over the Administration Server to another node. This section describes how to fail over the Administration Server from APPHOST1 to APPHOST2, and contains the following topics:
Section 5.14.2, "Validating Access to APPHOST2 Through Oracle HTTP Server"
Section 5.14.3, "Failing the Administration Server Back to APPHOST1"
Note the following assumptions:
The Administration Server is configured to listen on ADMINVHN, and not on ANY address.
The Administration Server is failed over from APPHOST1 to APPHOST2, and the two nodes have these IP addresses:
APPHOST1: 100.200.140.165
APPHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206. This is the VIP where the Administration Server is running, assigned to ethX:Y, available in APPHOST1 and APPHOST2.
The domain directory where the administration server is running in APPHOST1 is on a shared storage and is mounted also from APPHOST2.
Oracle WebLogic Server and Oracle Fusion Middleware components have been installed in APPHOST2 (that is, the same paths for ORACLE_HOME and MW_HOME that exist on APPHOST1 are also available on APPHOST2).
Procedure
The following procedure shows how to fail over the Administration Server to a different node (APPHOST2):
Stop the Administration Server, if it is running.
Migrate the IP address to the second node:
Run the following command as root on APPHOST1 (where X:Y is the current interface used by ADMINVHN):
APPHOST1> /sbin/ifconfig ethX:Y down
Run the following command on APPHOST2:
APPHOST2> /sbin/ifconfig interface:index IP_address netmask netmask
For example:
APPHOST2> /sbin/ifconfig eth0:1 10.200.140.206 netmask 255.255.255.0
Note:
Make sure that the netmask and interface to be used match the available network configuration in APPHOST2.Update the routing tables using arping
. For example:
APPHOST2> /sbin/arping -b -A -c 3 -I eth0 100.200.140.206
Start Node Manager in APPHOST2, using the instructions given in Step 3 of Section 5.4, "Starting the Administration Server on APPHOST1."
Start the Administration Server on APPHOST2, using the instructions given in Step 4 of Section 5.4, "Starting the Administration Server on APPHOST1."
Test that you can access the Administration Server on APPHOST2, as follows:
Ensure that you can access the Administration Console at http://ADMINVHN:7001/console.
Check that you can access and verify the status of components in Fusion Middleware Control at http://ADMINVHN:7001/em.
Perform the steps described in Section 5.13, "Validating Access Through Oracle HTTP Server" to check that you can access the Administration Server when it is running on APPHOST2.
This step checks that you can fail back the Administration Server; that is, stop it on APPHOST2 and run it on APPHOST1 again. To do this, migrate ADMINVHN back to the APPHOST1 node as follows:
Make sure the Administration Server is not running.
Run the following command as root on APPHOST2.
APPHOST2> /sbin/ifconfig ethX:Y down
Run the following command on APPHOST1:
APPHOST1> /sbin/ifconfig interface:index IP_Address netmask netmask
For example:
APPHOST1> /sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Note:
Make sure that the netmask and interface you use matches the available network configuration in APPHOST1.Update the routing tables using arping
. For example:
APPHOST1> /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
Start the Administration Server again on APPHOST1, as described in Step 4 of Section 5.4, "Starting the Administration Server on APPHOST1."
Test that you can access the Administration Console at http://ADMINVHN:7001/console.
Check that you can access and verify the status of components in Fusion Middleware Control at http://ADMINVHN:7001/em.
If you encounter problems with Administration Server failover, see Section 10.6.2, "Administration Server Fails to Start After a Manual Failover" for additional information.
After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded after the enterprise deployment setup is complete. At that point, the regular deployment-specific backup and recovery process can be initiated. Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in that guide. For information on how to recover components, see the "Recovering Components" and "Recovering After Loss of Component Host" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" section in the guide. Also refer to Oracle Database Backup and Recovery User's Guide for information on database backup.
Perform these steps to back up the installation at this point:
Back up the Web tier:
Shut down the instance using opmnctl
:
WEBHOSTn> ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
Back up the Middleware home on the Web tier using the following command (as root):
WEBHOSTn> tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
Back up the Oracle instance on the Web tier using the following command:
WEBHOSTn> tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
Start the instance using opmnctl
:
WEBHOSTn> cd ORACLE_BASE/admin/instance_name/bin WEBHOSTn> opmnctl startall
Repeat this step for WEBHOST2.
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.
Back up the BI Instance in the application tier, as follows:
Shut down the instance using opmnctl:
APPHOST1> ORACLE_INSTANCE/bin/opmnctl stopall
Back up the Middleware home on the application tier using the following command (as root):
APPHOST1> tar -cvpf BACKUP_LOCATION/bi.tar MW_HOME
Back up the Oracle instance on the application tier using the following command:
APPHOST1> tar -cvpf BACKUP_LOCATION/bi_instance_name.tar ORACLE_INSTANCE
Start the instance using opmnctl:
APPHOST1> ORACLE_INSTANCE/bin/opmnctl startall
Back up the Administration Server and Managed Server domain directories to save your domain configuration. The configuration files all exist in the ORACLE_BASE/admin/ domain_name directory. Run the following command to create the backup:
APPHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name