Skip Headers
Oracle® Communications Order and Service Management Installation Guide
Release 7.2.2

E35412-05
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 OSM Installation Overview

This chapter provides an overview of the Oracle Communications Order and Service Management (OSM) installation procedure.

Directory Placeholders Used in This Guide

The following placeholders are used in this guide:

Table 1-1 Placeholders Used in This Guide

Placeholder Directory Description

OSM_home

The directory in which the OSM software is installed. This directory contains the SDK directory (if the SDK was installed) and various installation-related files.

MW_home

The location where the Oracle Middleware product is installed. This directory contains the base directory for the WebLogic Server, a utils directory, and other files and directories.

WLS_home

The base directory for the WebLogic Server core files. It is located in the MW_home directory, for example, MW_home/wlserver_10.3.

domain_home

The directory which contains the configuration for the domain into which OSM is installed. The default location is MW_home/user_projects/domains/domain_name but it is frequently set to some other directory at installation.


Overview of the OSM Installation Procedure

You set up OSM in your environment by performing the following general tasks in the order specified below:

  1. Ensure your system meets the minimum system requirements. See Chapter 2, "OSM System Requirements" for system requirements and configuration information you need before installing OSM.

  2. Perform the pre-installation tasks, such as configuring the operating system kernel. See Chapter 3, "OSM Pre-Installation Tasks" for more information.

  3. Install and configure the Oracle Database Server. See Chapter 4, "Installing and Configuring the Oracle Database." Ensure that the information about the database instance is communicated to the person who will be installing OSM.

  4. Install the Oracle Data Access Components (ODAC) Client on a Windows machine if you want to install the OSM Administrator application.

    Ensure that you select the following components for installation when you install the ODAC:

    • Oracle Data Provider for OLE DB

    • Oracle Data Provider for .NET

    • Oracle Objects for OLE

    For more information, see OSM Administrator Application User's Guide.

  5. Download and install the Java version required for Oracle WebLogic Server. See "Software Requirements" for information about the correct version to install.

  6. Install and configure Oracle WebLogic Server. See Chapter 5, "Installing and Configuring WebLogic Server."

  7. If you are using clustering in OSM, configure the OSM WebLogic domain for clustering. See Chapter 7, "Installing OSM in a Clustered Environment".

  8. Install OSM. See Chapter 6, "Installing OSM in Interactive Mode."

  9. Perform post-installation tasks. See Chapter 9, "OSM Post-Installation Tasks."

You can use OSM with the default installation settings for product evaluation, development, demonstration, or process modeling. For your production system, you should tune the system to your specific requirements. See OSM System Administrator's Guide, or contact Oracle for more information.

Installation Options

There are many options you can choose during installation. This section discusses the most key options, or those that have the largest impact on the installation process.

Installation Modes

When installing OSM, you have the following two main options for installation mode:

Both of these installation methods provide all of the same options. Oracle recommends that you use the interactive mode for your first installation. If you intend to perform further installations in silent mode, ensure that when prompted during the interactive installation, you elect to Save Configuration. This will provide you with a configuration file that contains the settings you used in the interactive installation. You can use this file as a sample for your silent installations.

Components to Install

If you select a Custom installation, you must supply information about which components you wish to install. Some components can only be installed on a Windows-based computer. The OSM Windows-only components are the Database Utilities and the OSM Administrator application (used for managing users).

If you are installing OSM on a UNIX-based platform, it is recommended that you perform two separate installations (UNIX and Windows). The Windows installation should be a Custom installation of only the Database Utilities and Administrator components. See "Installing Windows-Only Components" for more information.

All of the OSM components can be installed on a Windows-based computer. However, the OSM Server is not supported on Windows-based machines for production environments. The OSM server should only be installed on a Windows-based computer for development, demonstration, and (non-performance) test systems.

High Availability

One of the most important options available in OSM is the support for high availability.

An OSM system that is deployed into a high-availability architecture consists of the following physical layers:

  • The application server layer, which hosts the WebLogic resources that manage the OSM application.

  • The database server layer, which hosts either a single-instance database or a highly-available Oracle RAC database.

  • A shared storage system that the database servers use to access the database files. Shared storage may also be required for the application servers.

  • An optional load balancer in fault-tolerant mode.

In an OSM deployment where high availability is required, redundancy is built-in at each layer of the system to ensure there is no single point of failure. See Appendix B, "OSM High-Availability Guidelines and Best Practices" for a full discussion of how high availability is achieved at each layer of the system and the components within.

High Availability at the Application Server Layer

At the application server layer, the physical servers host the Oracle WebLogic Server environment. This environment is typically a single WebLogic Server domain with one WebLogic Server cluster that runs the OSM application.

A physical server may host one or more managed servers. The managed servers (spread across the physical servers) form the WebLogic Server cluster. Each of the physical servers has a Node Manager which can start, shut down, and restart all managed servers in the physical server. If any of the managed server instances fail, requests to the failed instance will be sent to the surviving instances.

An administration server is the central control entity for the configuration of the entire domain. It can be deployed to a standalone machine that is separate from the physical servers running the managed servers or to the same physical server that is running the managed servers.

The capacity of OSM deployed on a WebLogic Server cluster can be resized dynamically to meet demand. Server instances can be added to or removed from a cluster. Server instances can also be migrated to any physical server that may be available, automatically upon failure or upon a scheduled maintenance activity.

See "OSM High-Availability Guidelines and Best Practices" for a discussion of how high availability is achieved at the application server layer.

High Availability at the Database Server Layer

At the database-server layer, OSM supports the following high-availability configurations:

  • Cold cluster failover (also known as cold standby), which consists of Oracle Clusterware and two Oracle single-instance databases running on separate physical servers sharing disk storage. Clusterware monitors the primary active database instance and provides the capability of failover to a cold standby database in case of failure, thus ensuring high availability. Clients on the network experience a period of lockout while the failover occurs and are then served by the other database instance after the instance has started.

    See "Configuring Oracle Database with Clusterware" for configuration details.

  • Active-passive Oracle RAC (also known as warm standby), which offers a higher level of availability than cold standby. In this configuration, two Oracle RAC database instances run on separate physical servers with shared disk storage. One database is configured as the primary instance and the other as the secondary instance. WebLogic monitors the database instance running on the primary server and, if a failure is detected, workload fails over to the secondary database instance. The advantage of warm standby over cold standby is minimal outage time. The backup database is always running, therefore no additional time is required to bring up the database.

    See "Configuring Oracle Database with Real Application Clusters (RAC)" for configuration details.

  • Active -active Oracle RAC, which offers the highest level of availability. In active-active Oracle RAC, all active instances simultaneously process database operations. In addition to load balancing, active-active Oracle RAC can also provide high availability if the physical database server of one Oracle RAC database instance is dimensioned to handle all of the database load upon failure of the other Oracle RAC database instance.

Note:

OSM supports only two nodes in all three configurations.

See "OSM High-Availability Guidelines and Best Practices" for a discussion on how high availability is achieved at the database server layer.

Sharable Storage System

OSM requires high levels of I/O throughput, primarily for the read/writes in the database servers. In a production deployment with high-performance demand, a high-performance storage system must be dimensioned, in terms of both I/O throughput and fault tolerance. It is recommended that the disk storage be configured as RAID type 1+0 with redundant controllers.

The storage system must be sharable across all database instances regardless of which database-redundancy configuration you employ.

Instances in the application server layer may also need shared storage due to availability requirements in WebLogic Server's persistent store.

Load Balancer

Client connection requests in front of the WebLogic Server cluster are load balanced to one or more distinct IP addresses. While a hardware balancer (in fault-tolerant mode) is recommended, you may also use the WebLogic proxy plug-in or another software-based load balancing solution.

Overview of OSM Installed Components

During the installation process, you install and configure the following components:

  • Oracle Database

  • Oracle WebLogic Server

  • Oracle Application Development Framework Runtime

  • JBoss Cache

  • Saxon

  • GraphViz (optional, to use with the modeldoc tool)

  • Ant

  • OSM Server Software

  • OSM Windows-only components

Ensuring a Successful OSM Installation

The OSM installation should be performed only by qualified personnel. You must be familiar with the operating system on which OSM is to be installed and with WebLogic Server. The installation and configuration of the Oracle database should be performed by an experienced database administrator.

Follow these guidelines:

  • As you install each component; for example, the Oracle database and WebLogic Server, verify that the component installed successfully before continuing the installation process.

  • Pay close attention to the system requirements. Before you begin installing the software, make sure your system has the required base software. In addition, make sure that you know all of the required configuration values, such as host names and port numbers.

  • As you create new configuration values, write them down. In some cases, you might need to re-enter configuration values later in the procedure. Also, some values will need to be communicated to any users of OSM.