5 Creating a Domain with the Administration Server and First Managed Server

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.

5.1 Creating a Domain and the bi_server1 Managed Server on APPHOST1

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.

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.3, "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.

5.3 Starting the Administration Server on APPHOST1

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:

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.

5.4 Enabling Administration Server High Availability

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.

5.4.1 Enabling ADMINVHN on APPHOST1

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:

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

5.6.1 Updating the Oracle BI Publisher Scheduler Configuration

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.

5.7 Disabling Host Name Verification for the bi_server1 Managed Server

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:

5.8.1 Starting the bi_server1 Managed Server

Start the bi_server1 Managed Server using the Administration Console, as follows:

Expand the Environment node in the Domain Structure window.

Click Servers. The Summary of Servers page is displayed.

Click the Control tab.

Select bi_server1 and then click Start.

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.

5.8.2 Starting the Oracle Business Intelligence System Components

You can control Oracle Business Intelligence system components using opmnctl commands.

To start the Oracle Business Intelligence system components using the opmnctl command-line tool:

Go to the directory that contains the OPMN command-line tool, located in ORACLE_INSTANCE/bin.

Run the opmnctl command to start the Oracle Business Intelligence system components:

opmnctl startall

Starts OPMN and all Oracle Business Intelligence system components.

opmnctl start

Starts OPMN only.

opmnctl startproc ias-component=component_name

Starts a particular system component. For example, where coreapplication_obips1 is the Presentation Services component:

opmnctl startproc ias-component=coreapplication_obips1

Check the status of the Oracle Business Intelligence system components:

opmnctl status

5.8.3 Validating Oracle Business Intelligence URLs

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 Office application.

5.9 Configuring Oracle HTTP Server

This section covers how to configure Oracle HTTP Server for the Administration Server and for the bi_server1 Managed Server.

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.

5.10 Registering Oracle HTTP Server with Oracle WebLogic 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:

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.

5.11 Setting the Frontend URL for the Administration Console

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.

5.12 Validating Access Through Oracle HTTP Server

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.

5.12.1 Validating the Administration Console and Fusion Middleware Control

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.

5.13Manually Failing Over the Administration Server to APPHOST2

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:

5.13.1 Assumptions and Procedure

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:indexIP_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.

5.14 Backing Up the Installation

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 "Recovery of Components" and "Recovery After Loss of Component" 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 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 Home on the Web tier using the following command:

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 Administration Server domain directory 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

Scripting on this page enhances content navigation, but does not change the content in any way.