7 - OBIEE 11g Scaleout and Clustering

7: OBIEE 11g Scaleout & Clustering Rittman Mead Training - Cognizant Technology Solutions

T : +44 (0) 8446 697 995 or (888) or (888) 631 1410 (USA) E : [email protected] W: www.rittmanmead.com

What this Session Will Answer • • • •

•

How does it all fit together? How and why does it use WebLogic Server? What are the key k ey architectural differences between OBIEE 10g and 11g 11g How does it use Fusion Middleware Control to unify management across the platform? What are typical topologies for desktop, deparmental and enterprise deployments?


OBIEE 11g Single-Node Architecture •

•

•

•

Overall stack is an Oracle BI Domain Made up of three areas ‣ WLS Admin Server + FMW Control (EM) ‣ System Components ‣ WLS Managed Server with Java Components Initial (11.1.1.3) version only supports WLS 11g (10.3) Same fundamental components as 10g, but now integrated with FMW WLS stack


OBIEE 11g System Components, Java Components and OPMN • •

•

OBIEE components divided into System and Java components System components are still C/C++ executables, are controlled by OPMN, and are managed by Fusion Middlewar e Control Java Components are JEE applications, are installed in the managed server, and are controlled by FMW Control


Administration and Manageme Management nt •

• • •

WLS Admin Server used for controlling WLS platform security, non-OBIEE specific tasks task s ‣ Startup, shutdown, security, Fusion Middleware Control (EM) used for managing OBIEE OPMN used for starting, stopping system components Node Manager used for starting, stopping managed servers


11g Architecture Compared to 10g Architecture • •

•

•

Main difference is wrapping components in WLS platform and EM management Individual servers, components are still the same (BI Server, Presentation Server, BI Publisher J2EE application etc) Some reworking has taken t aken place in 11gR1 (unified logging, management of config files using EM etc) Basic concepts, plus clustering (OBIEE), scheduling etc are the same as in 10g Web Server

(IIS, Tomcat, Websphere, iPlanet)

Oracle BI Publisher

Oracle BI Presentation Services

Delivery Server

TCP/IP (SSL)

SOAP Web Services, XML and URL Interface

Layout Interfaces XSL

Oracle Interactive Dashboards

Data Logic

Web Browser

SAW Bridge(J2EE/ISAPI)

Oracle Answers

User Profiling, Security and Session Mngmt

XML, HTML, XLS, PDF, TXT over HTTP/HTTPS

Javascript for Usability & Interactivity

Web Catalog Service XML Framework

Cache Services (Web) & Connection Mngmt

HTML, SOAP over HTTP/HTTPS

External Applications and Portals

ODBC over TCP/IP (SSL)

Oracle Delivers Server Scheduling/Eventt Services Scheduling/Even

TCP/IP (SSL)

Oracle BI Server Logical SQL ODBC/JDBC (Logical Business Model)

Load Balancer

Agent Execution Lo Logic gic Device Adaptive Content

Session Management Intelligent Request Generation

Oracle BI Cluster Controller

Externalized Authentication LDAP

Logical Request Generation S e c u r i t y S e r v i c e s

Q u e r y G o v e r n .

Cache Cache Services

Navigator Multi-Pass / Sub-RequestLogic Fragmentation Optimization Aggregate Navigator

DB Authentication CustomAuthenticator

Optimized Query Rewrites ExecutionEngine

e g n a h c r e t n I a t a d a t e M g n i r o t i n o M f r e P / m e t s y S

Oracle BI Administration

vs.

MetadataManagementServices Services Multi-User Development Services MetadataDocumentationServices Server Management Services

Data Source Adapters ODBC, CLI, OCI, XML, MDX Analytical and Operational Data Sources


The Role of Fusion Middleware Control (EM) • • • •

• •

Unified, system-wide management of all nodes across BI domain Performance monitoring and tuning 1-click scale-out and online clustering Management of RPDs, web catalogs etc Patching & upgrades Replaces (in part, initially) hand-editing of config files (NQSConfig.INI etc)


Default Use of Clustering •

•

During installation, Cluster Controller is automatically installed and configured to create a default 1-node cluster Makes it easier to add cluster nodes af ter ter install ‣ Vertical clustering and horizontal clustering


What Hasn’t Changed Since OBIEE 10g • • • • • • •

All configuration data is still held in text files (NQSConfig.INI, instanceconfig.xml) System components still need restart after config change Still single default RPD per BI Server Clustering, caching still the same basic technology RPD is still held in a binary file Web Catalog still a filesystem directory Logging still to files (though now centralized to diagnostics directory)


OBIEE 11g Default Filesystem Layout • •

•

•

•

Binaries in the BI Oracle Home Configuration files (RPD, config files, diagnostics, WebCat) in the BI Instance Home WLS binaries in the WL Home WLS domain files in Domain Home Separation of binaries from configuration/instance files


Leveraging Oracle Fusion Middleware Technologies •

OBIEE 11g leverages many Fusion Middleware 11g 11g technologies ebL Logic Server) ‣ WLS (Web ‣ OPMN (Oracle Process Manager and Notification Server) ‣ OPSS (Oracle Platform Security Services) ‣ DMS (Dynamic Monitoring System) ‣ ODL (Oracle Diagnostic Logging) ‣ JPS (Java Platform Security) ‣ CSF (Credential Store Framework) ‣ OPATCH / OPACK ‣ UA (Upgrade Assistant) ‣ RCU (Repository Creation Assistant)


OPMN •

•

•

•

•

•

Used for distributed process start/stop/restart Process recovery (optional), process “ping” Managed via EM, or from command line Can also be used for performance collection (DMS) Required on every OBIEE server Standard FMW process control tool

C:\Middleware\Oracle_BI1\opmn\bin>opmnctl status Processes in Instance: instance1 ---------------------------------+--------------------+---------+--------ias-component | process-type | pid | status ---------------------------------+--------------------+---------+- -------coreapplicati on_obiccs1 | OracleBICluste rCo~ | 3364 | Alive coreapplicati on_obisch1 | OracleBISchedu ler~ | 1012 | Alive coreapplicati on_obijh1 | OracleBIJavaHo stC~ | 4400 | Alive coreapplicati on_obips1 | OracleBIPresen tat~ | 2092 | Alive coreapplicati on_obis1 | OracleBIServer Com~ | 5040 | Alive


DMS and Oracle Diagnostic Logging • •

•

Most logs now searchable from Fusion Middleware Control Those that do now include an ECID (Execution Context ID) that ties together entries across logs relating to a single transaction transaction DMS (Dynamic Monitoring System) records performance data across system (similar to Perfmon, JMX Counters)


Three Sample Deployments 1. Deskto Desktop p / Laptop Laptop Inst Install all • Quick installation, smallest footprint Failover,, Resilence etc • No contingency for HA, Failover 2. Departmenta Departmentall Install Install with Horizona Horizonall Scaleout Scaleout • Production installation, needs element of resilience / scalability • not overcomplicated installation, simple maintenance DEV, TEST etc environments • Ability to create DEV, 3. Enterprise Enterprise Install (optional (optional Vertical Vertical/Horizo /Horizontal ntal Scaleout) Scaleout) • As with Departmental install, plus... • Highly secure - use of firewalls, DMZ etc c omponents • Highly resilient, failover for all components • Failover extends to RDBMS level 11g • Suitable for enterprise-wide deployment of OBIEE 11g T : +44 (0) 8446 697 995 or (888) or (888) 631 1410 (USA) E : [email protected] W: www.rittmanmead.com

Deployment Topology 1 : Desktop / Laptop


Desktop / Laptop Deployment Considerations • • • •

•

Can be installed using either the Simple S imple or Enterprise install options Requires a machine with (minimum) 3-4Gb or (recommended) 8GB RAM 20Gb disk space for OBIEE 11g files, 500MB for supporting schemas Currently Windows or Linux, 32/64 bit (Linux also requires Windows for BI Administration tool) Browser must be Firefox 3+ or IE7+ (Safari not yet certified)


Deployment Topology 2 : Departmental w/Horizonal Scaleout


Definition: Domains and Instances • •

•

•

Oracle BI Domain : The overall OBIEE system WebLogic Domain : Admin Server, plus Managed Server(s), across n hosts ‣ Java components, optionally scaled out across nodes (managed servers) BI Instance : BI Servers, Presentation Servers etc, across n hosts ‣ System components, optionally scaled up and out across nodes Each Oracle BI Domain (in 11.1.1.3) has a single WebLogic Domain and BI Instance ‣ Logical containers, can span n physical hosts


Departmental Deployment Considerations • •

• • •

•

Database separated out into its own host Scale-out option has been used, to add an additional managed server ‣ Mainly addresses capacity, but some availability benefits HTTP server runs from within BIHOST System components are clustered across BIHOST1 and BIHOST2 Typical system for team of developers, and departmental deployment capacity, some redundancy redundancy,, simple to adminster ‣ Reasonable capacity, Note: current version (11.1.1.3) (11.1.1.3) does not have ability to do client-only install, so will need to perform full (Simple) install for developers and disable services


Vertical Scaleout of System Components •

• •

Spare capacity on an individual host can be used by adding additional system components Can add additional BI Servers, Presentation Present ation Servers and Java Java Hosts Useful for resilience, and usage of spare capacity ‣ Doesn’t protect against the whole server failing though


Vertical Clustering Step 1 : View Scalout Recommendations • •

View Potential Points of Failure report on Capacity Management > Availability Recommends scaling-out BI Server, BI Presentation Server and BI JavaHost


Vertical Clustering Step 2 : Add New System Components •

•

Use Capacity Management > Scalability to add additional BI Servers, Servers, Presentation Servers and Java Hosts Set Port Range From (usually can leave leave at default)


Vertical Clustering Step 3 : Check Components Provisioned •

• •

View System Components Availability from Capacity Management > Availability Components should be provisioned, but bu t not started up Press Restart All to proceed


Vertical Clustering Step 4 : Start New System Components • •

Check Capacity Management > Availability to check all components running Clustering will now ensure that if one fails, the other will take over (active-active clustering)

Text Text


7: OBIEE 11g Scaleout & Clustering


Horizonal Scaleout of System Components •

• • •

Used for adding additional managed servers (Java components) and system components to an existing cluster Used for scalability and failover Set up via the Universal Installer > Scale Out BI System option Automatic process, no need to edit configuration files 1. Create share shared d area for RPD, RPD, catalog, catalog, cache cache 2. Instal Installl OBIEE on to new node, node, select Enterpris Enterprise e Install > Scale Out Out 3. Provid Provide e details details for WLS WLS Admin Server Server 4. Node is configure configured d to be new managed managed server within within cluster cluster 5. Use EM to add add system system components components to to the new new server server 6. Designate secondary secondary controllers controllers for scheduler scheduler,, cluster controler 7. New server server is now available available,, and part part of the cluster cluster


Horizontal Clustering Step 1 : Create Shared Areas Areas • • •

Create folders on network share for RPD, RP D, Web Catalog and Global Cache Share needs to be accessible to all hosts Copy the web catalog across manually, manually, the others will be populated automatically


Horizontal Clustering Step 2 : Prepare Installation •

•

Start the Oracle Universal Installer on the new host, select Enterprise Install > Scale Out BI System option Enter connection details to the WLS Admin Admin Server


Horizontal Clustering Step 3 : Install and Configure • •

Allow installation to complete, and then post-install configuration steps This should then complete the scale-out sc ale-out of the managed server and java components


Horizontal Clustering Step 4 : Add New System Components • •

Add new BI Servers, Presentation Servers and JavaHosts on new host Once provisioned, Capacity Management > Scalability > Start Selected to make them available for use


Horizontal Clustering Step 5 : Define Secondary Controllers • • •

Final step is to define secondary BI Cluster Controllers + BI Schedulers Capacity Management > Availability > Primary / Secondary Configuration Use in active/passive failover situation


Horizontal Clustering Step 6 : Check Failover Recommendations Recommendations •

•

Fusion Middleware Control should now report that all system components have active/active, and active/passive backups No remaining Single Points of Failure


Use of Hardware Load Balancer •

•

•

Load balancer required to route incoming requests to WEBHOST1 and WEBHOST2 virtual host names Load balancer needs to be able to perf orm orm following functions functions ‣ Ability to route to virtual host names in a pool ‣ Perform port number translation ‣ Monitor ports on the servers in the pool to determine availability Ability lity to detect node failures, and reroute traffic away from from failed node ‣ Abi ‣ Sticky-routing capability S SL requests to non-SSL) ‣ SSL Acceleration (convert SSL List of validated load balances available on OTN ‣ http://www.oracle.com/technology/products/ias/hi_av/ Tested_LBR_FW_SSLAccel.html


Managing Failover and Failback • •

•

In a clustered OBIEE 11g environment, failover is possible BI Server, BI Presentation Server and JavaHost are active/active ‣ For BI Server, if one fails and session is active, query will fail but browser refresh will re-run the analysis activ e, user will ‣ For BI Presentation server, if one fails and session is active, need to log in again (start new session) ‣ For JavaHost, if one fails, refresh of browser will use alternative ‣ Automatic failback once component is online again BI Cluster Controller and BI Scheduler are active/passive ‣ For both components, if one fails, clients will detect primary component unavailability and connect to secondary component instead ‣ Automatic failback to primary component once online again


Creating Additional Additional TEST and PROD Environments •

•

•

•

OBIEE 11g 11g supports multiple, separate, standalone installations (BI Domains) on a single host instances within a BI Domain Domain ‣ Does not yet support multiple instances RCU supports creating multiple BIPLA BIP LATFORM TFORM schemas on one database (DEV_BIPLATFORM, (DEV_BIPLATFORM, PROD_BIPLATFORM etc) It is therefore possible in OBIEE 11g to install multiple DEV, DEV, PROD, TEST etc environments on one host, as long as each installation is standalone Or install onto separate hosts, if full isolation is required


Deployment Topology 3 : Enterprise


Enterprise Deployment Considerations •

• •

•

•

• • •

WebLogic clustering, with WLS + OBIEE software soft ware installed on two redundant hosts (APPHOST1, APPHOST2) HTTP Servers moved to seperate WEBHOST1 WEB HOST1 and WEBHOS WEBHOST2 T2 hosts WLS and OBIEE binaries installed onto two t wo volumes on shared storage t he volumes ‣ Protects against corruptions in one of the Admin Server accessed through VIP and ADMINHVN ‣ Provides manual/automatic failover for Admin Server RAC + Dataguard used for repository database ‣ Resilience and HA for database Firewall zones used to separate out web + application tiers from database Still open to horizontal and vertical OBIEE clustering Documented in the Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Business Intelligence 11g 11g Release 1 (11.1.1) (11.1.1)


Separation of HTTP Servers into DMZ • •

•

Recommended for security, as moves public-facing servers into public DMZ Two hosts, WEBHOST1 and WEBHOST2, running Oracle HTTP Server, Oracle WebGate and mod_wl_ohs ‣ Oracle WebGate used when implementing Oracle Access Manager ‣ mod_wl_ohs proxies Oracle HTTP Server requests to WLS External hardware load balancer is the public-facing component ‣ Sends requests on port 80 to WEBHOST VIPs using port 443


Duplication of Application Servers •

•

WLS Admin Server is a singleton application, so needs secondary location for active/passive failover WLS and OBIEE 11gR1 software is installed installed twice, on two host hosts, s, for redundancy ‣ Manual or automatic failover in the event of first host failing ‣ Admin server reached through virtual host ADMINHVN


Use of Shared Storage for FMW Files •

• •

WLS and OBIEE software (WL_HOME, ORACLE_HOME) are installed onto shared disk using SAN or NAS u se same ‣ Ideally install into separate volumes (VOL1, VOL2) and use install directory (ORACLE_BASE/product/fmw) ‣ If not, install into separate directories ( ORACLE_BASE/product/fmw1|2) Protects binaries from corruption Installs use alternate volumes/directories on round-robin basis


Recommended Recommende d Directory Structure for Enterprise Deployment •

In addition, separate domain directory for the Admin Server and Managed Server(s) ‣ Symmetric configuration for managed servers ‣ Isolates the failover of the Admin Server ‣ Admin Server domain directory should be on shared storage ‣ Managed servers can be shared or local storage


RAC / DataGuard for DB Resilience •

•

For full resilience, database holding BIPLATFORM BIPLATFORM schema should be protected as well For Oracle RDBMS, RAC (Real Application Application Clusters) and Data DataGuard Guard recommended f or scaleout and (some) resilience ‣ RAC supports multiple nodes, used for ‣ DataGuard replicates data to standby (failover) database


Horizontal and Vertical Scaleout of Enterprise Deployment • •

Deployment can be vertically or horizontally scaled out as normal ADMINVHN used as hostname for Admin Server


SSO and SSL • • • •

OBIEE can be configured to work w ork with multiple Single Sign-On (SSO) providers Can also be configured to communicate securely s ecurely (SSL) SSO enabled through coreapplication Fusion Middleware Control pages SSL enabled through MBeans screens


7: OBIEE 11g Scaleout & Clustering Rittman Mead Training - Cognizant Technology Solutions


7 - OBIEE 11g Scaleout and Clustering

Recommend Documents