Scaling out Oracle BI 12c

There are several reasons why an organization may wish to expand their Oracle BI footprint. This can range anywhere from requiring a highly available environment to achieving high levels of concurrent usage over time. The number of total end users, the number of total concurrent end users, the volume of queries, the size of the underlying data warehouse, and cross-network latency are even more factors to consider. Scaling out an environment has the potential to solve performance issues and stabilize the environment. When scoping out the infrastructure for an Oracle BI deployment, there are several crucial decisions to be made. These decisions can be greatly assisted by preparing properly, using Oracle's recommended guides for clustering and deploying Oracle BI on an enterprise scale.

Pre-configuration run-down

Configuring the Oracle BI product suite, specifically when involving scaling out or setting up high-availability (HA), takes preparation. Proactively taking steps to understand what it takes to correctly establish or pre-configure the infrastructure required to support any level of fault tolerance and high-availability is critical. Even if the decision to scale-out from the initial Oracle BI deployment hasn't been made, if the potential exists, proper planning is recommended.

Shared storage

We would be remiss not to highlight one of the most important concepts of scaling out Oracle BI, specifically for high-availability: shared storage. The idea of shared storage is that in a fault-tolerance environment, there are binary files and other configuration metadata that need to be shared across the nodes. If these common elements were not shared, if one node were to fail, there is a potential loss of data. Most importantly is that in a highly available Oracle BI environment, there can be only one WebLogic Administration Server running for that environment at any one time. A HA configuration makes one Administration Server active while the other is passive. If the appropriate pre-configuration steps for shared storage (as well as other items in the high-availability guide) are not properly completed, one should not expect accurate results from their environment.

OBIEE 12c requires you to modify the Singleton Data Directory (SDD) for your Oracle BI configuration found at ORACLE_HOME/user_projects/domains/bi/data, so that the files within that path are moved to a shared storage location that would be mounted to the scaled-out servers on which a HA configuration would be implemented. To change this, one would need to modify the ORACLE_HOME/user_projects/domains/bi/config/fmwconfig/bienv/core/bi-environment.xml file to set the path of the bi:singleton-data-directory element to the full path of the shared mounted file location that contains a copy of the bi data folder, which will be referenced by one ore more scaled-out HA Oracle 12c servers.

For example, change the XML file element:

<bi:singleton-data-directory>/oraclehome/user_projects/domains/bi/bidata/</bi:singleton-data-directory>

To reflect a shared NAS or SAN mount whose folder names and structure are inline with the IT team's standard naming conventions, where the /bidata folder is the folder from the main Oracle BI 12c instance that gets copied to the shared directory:

<bi:singleton-data-directory>/mount02/obiee_shared_settings/bidata/</bi:singleton-data-directory>

Clustering

A major benefit of Oracle BI's ability to leverage WebLogic Server as the Java application server tier is that, per the default installation, Oracle BI gets established in a clustered architecture. There is no additional configuration necessary to set this architecture in motion. Clearly, installing Oracle BI on a single server only provides a single server with which to interface; however, upon doing so, Oracle BI is installed into a single-node clustered-application-server environment. Additional clustered nodes of Oracle BI can then be configured to establish and expand the server, either horizontally or vertically.

Vertical versus horizontal

In respect to the enterprise architecture and infrastructure of the Oracle BI environment, a clustered environment can be expanded in one of two ways: horizontally (scale-out) and vertically (scale-up). A horizontal expansion is the typical expansion type when clustering. It is represented by installing and configuring the application on a separate physical server, with reference to the main server application. A vertical expansion is usually represented by expanding the application on the same physical server under which the main server application resides. A horizontally expanded system can then, additionally, be vertically expanded.

There are benefits to both scaling options. The decision to scale the system one way or the other is usually predicated on the cost of additional physical servers, server limitations, peripherals such as memory or processors, or an increase in usage activity by end users. Some considerations that may be used to assess which approach is the best for your specific implementation might be as follows:

• Load-balancing capabilities and need for an Active-Active versus Active-Passive architecture
• Need for failover or high availability
• Costs for processor and memory enhancements versus the cost of new servers
• Anticipated increase in concurrent user queries
• Realized decrease in performance due to increase in user activity

Oracle BI Server Cluster Controller

When discussing scaling out the Oracle BI Server cluster, it is a common mistake to confuse the WebLogic Server application clustering with the Oracle BI Server Cluster Controller. Currently, Oracle BI can only have a single metadata repository (RPD) reference associated with an Oracle BI Server deployment instance at any single point in time. Because of this, the Oracle BI Server engine leverages a failover concept, to ensure some level of high-availability exists when the environment is scaled. In an Oracle BI scaled-out clustered environment, a secondary node, which has an instance of Oracle BI installed, will contain a secondary Oracle BI Server engine. From the main Oracle BI Managed Server containing the primary Oracle BI Server instance, the secondary Oracle BI Server instance gets established as the failover server engine using the Oracle BI Server Cluster Controller. This configuration takes place in the Enterprise Manager Fusion Control console. Based on this configuration, the scaled-out Oracle BI Server engine acts in an active-passive mode. That is to say that when the main Oracle BI server engine instance fails, the secondary, or passive, Oracle BI Server engine then becomes active to route requests and field queries.

Failover and high-availability

High-availability of the Oracle BI system can be difficult to achieve, but may be necessary based on increased system demands on concurrent usage or other factors. Providing a 24x7 up-time of server operations for some organizations is a must. High Availability is the type of architecture associated with an environment when attempting to maintain a high-level of application availability and minimal downtime.

Failover is the process that takes place when a server node in a cluster fails, and application traffic otherwise intended for the downed server flows to the other active clustered server nodes. Failover also requires some level of load balancing, and the concept can vary depending on desired architecture within an organization, but the general concept should be roughly the same in most topologies. As part of an enterprise deployment strategy, taking failover and high-availability into consideration is usually part of the architecture-planning process. Step-by-step configuration instructions for a high-availability or failover environment are an advanced infrastructure topic and beyond the scope of this book. However, it is important to note that because Oracle BI is part of the Fusion Middleware stack, it has the ability to capitalize on all fault-tolerance features offered by that common architecture.