01.02.2013 Views

Publishing Reports to the Web - Downloads - Oracle

Publishing Reports to the Web - Downloads - Oracle

Publishing Reports to the Web - Downloads - Oracle

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

12<br />

Clustering <strong>Reports</strong> Servers<br />

A cluster is a virtual grouping of servers in<strong>to</strong> a community for <strong>the</strong> purpose of sharing<br />

request processing efficiently across members of <strong>the</strong> cluster. Clustering in <strong>Oracle</strong>AS<br />

<strong>Reports</strong> Services is peer-level, which means that all members of <strong>the</strong> cluster take equal<br />

responsibility for sharing and processing incoming requests. If one member is shut<br />

down, <strong>the</strong> o<strong>the</strong>r members carry on managing <strong>the</strong> request load. If <strong>the</strong> output is present<br />

in one member’s cache, ano<strong>the</strong>r member can use it. There is no single-point-of-failure,<br />

where one machine's malfunction brings <strong>the</strong> whole system down.<br />

This chapter contains information about enrolling a server in a cluster and benefits of<br />

clustering servers <strong>to</strong>ge<strong>the</strong>r. It contains <strong>the</strong> following sections:<br />

■ Cluster Overview<br />

■ Setting Up a Cluster<br />

12.1 Cluster Overview<br />

Assume you have <strong>the</strong> following servers:<br />

serverA.cluster1<br />

serverB<br />

serverC.cluster1<br />

ServerA.cluster1 and serverC.cluster1 are members of <strong>the</strong> same cluster<br />

called cluster1. They cooperate <strong>to</strong> process requests from a client. If a client sends a<br />

synchronous request <strong>to</strong> serverA.cluster1 and it does not have an idle engine of<br />

<strong>the</strong> specific job type, <strong>the</strong>n it checks <strong>to</strong> see if serverC.cluster1 does. If<br />

serverC.cluster1 does have an idle engine, <strong>the</strong>n serverA.cluster1 passes <strong>the</strong><br />

request <strong>to</strong> serverC.cluster1 for processing.<br />

In this example, ServerB is a stand-alone server and cannot receive processing<br />

requests from o<strong>the</strong>r servers, nor can it send processing requests <strong>to</strong> o<strong>the</strong>r servers.<br />

You can have an unlimited number of servers in a cluster. If a cluster member is shut<br />

down, <strong>the</strong>n it redistributes its pending synchronous jobs <strong>to</strong> ano<strong>the</strong>r server in <strong>the</strong><br />

cluster. As long as one server in <strong>the</strong> cluster is running, <strong>the</strong> cluster is working.<br />

When <strong>the</strong> cluster is making its decision as <strong>to</strong> where an upcoming scheduled or<br />

immediate request should be processed, it prioritizes according <strong>to</strong> <strong>the</strong> following<br />

criteria:<br />

1. Does any server in <strong>the</strong> cluster have information in cache that matches <strong>the</strong> request?<br />

2. Is <strong>the</strong>re a current, similar job in <strong>the</strong> queue?<br />

3. Is an idle engine of <strong>the</strong> particular job type available?<br />

Clustering <strong>Reports</strong> Servers 12-1

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!