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.

Enterprise deployments rarely run a single OBIEE instance, and interviewers ask about clustering to see whether you understand OBIEE as a distributed system with real failure modes, not just a single desktop-like install.

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
An OBIEE cluster consists of multiple BI Server instances (each running nqsserver) and multiple Presentation Services instances, coordinated by a Cluster Controller and sitting behind a hardware or software load balancer. All instances in a cluster share the same RPD (deployed identically to each node, typically via the shared BI Server Metadata Repository file or synchronized deployment) and the same web catalog (usually placed on shared storage, or in more modern deployments, the catalog and configuration can live in a shared database-backed repository). WebLogic Server itself typically runs as a domain with multiple managed servers, often across multiple physical or virtual hosts, with an Admin Server managing configuration centrally.
clusterBI Server instancesPresentation Services instancesCluster Controllerload balancer
2
High availability means that if one BI Server node fails, the Cluster Controller detects it and the load balancer routes new requests to healthy nodes; in-flight queries on the failed node are lost and must be retried by the client, but the overall service stays up. Session state in Presentation Services (open dashboards, in-progress prompts) is generally not failed over transparently — a user whose Presentation Services node dies will need to re-authenticate and reopen their session, which is an important nuance to mention rather than overselling seamless failover.
not failed over transparently
3
Scaling horizontally (adding more nodes) helps with concurrent user load and query throughput but does not, by itself, speed up any single expensive query — that's still bounded by the underlying database and the RPD's navigation/aggregation design. This distinction (scaling for concurrency vs. scaling for single-query speed) is exactly the kind of nuance that separates a strong systems answer from a superficial one.