All topics
10 / 55
OBIEEadvanced

High Availability & Clustering

Explain how OBIEE scales horizontally and achieves high availability through clustered BI Server and Presentation Services instances behind a load balancer.

A production OBIEE deployment runs several instances. Clustering is what makes that work, and the components do not all cluster the same way.

It's like a call center with multiple identical branches sharing the same script and customer database: if one branch's phone line goes down, new calls route to another branch automatically, but anyone already mid-call there has to call back and start over.

Key Concepts

1
The shape.
    load balancer
       |
    +--+--+
    |     |
    PS1   PS2          Presentation Services, several instances
    |     |
    Cluster Controller  routes to a BI Server
    |     |
    BIS1  BIS2         BI Server instances
2
What must be identical across nodes.
    the RPD          deployed to every node, the same version
    the web catalog  on shared storage, or shared through the
                     deployment mechanism
3
An RPD that differs between nodes is the classic cluster fault: a user's report works or fails depending on which node served them, which looks intermittent and is deterministic per node.
4
Sessions are the second consideration. Presentation Services holds session state, so a user's requests should reach the same node — sticky sessions on the load balancer — or their session is lost when they are routed elsewhere.
5
The Cluster Controller tracks which BI Servers are up and distributes requests. There is a primary and a secondary, which is itself a failover pair.
6
What clustering gives you, stated separately because they are different goals:
7
    availability   a node fails and users continue on the others
    scalability    more concurrent users, spread across nodes
8
More nodes do not make one query faster. A single analysis runs on one BI Server, so clustering addresses concurrency, not the speed of an individual report.
9
The parts that are not redundant by adding nodes.
    the database         its own HA problem
    shared storage       a single point of failure unless it is
                         itself redundant
    the load balancer    likewise
10
A cluster on shared storage with no redundancy has moved the single point of failure rather than removed it, which is worth saying because it is a common design.
11
Deployment across a cluster means every node gets the new RPD, and there is a window during which nodes differ. Rolling deployment handles that; deploying to one node and forgetting another produces the intermittent behaviour above.
12
Caching is per node. Each BI Server has its own cache, so a purge must reach all of them. A purge applied to one node leaves the others serving stale results — which, again, looks intermittent.
13
What the interviewer is probing.1. "How is OBIEE made highly available?" Probing: the architecture. Stalls: "Two servers." Moves up: a cluster of BI Server and Presentation Services instances across nodes, shared catalog and RPD storage, and a load balancer in front.
14
2. "What must be shared between nodes?" Probing: the detail. Stalls: "Nothing." Moves up: the catalog and global cache on shared storage, so a user session landing on either node sees the same content.
15
3. "What about session state on failover?" Probing: honesty. Stalls: "It is seamless." Moves up: in-flight queries are lost and the user re-authenticates or retries — availability here means the service survives, not the session.
16
4. "What is often the real single point of failure?" Probing: the insight. Stalls: "The server." Moves up: the data source — a clustered BI tier in front of one database instance has not removed the outage risk.
Use cases:high-availabilityclusteringscalability