Skip Headers

Oracle9iAS Reports Services Publishing Reports to the Web
Release 2 (9.0.2)

Part Number A92102-01
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
Reports Server Clusters

A cluster is a virtual grouping of servers into a community for the purpose of sharing request processing efficiently across members of the cluster. Clustering in Oracle9iAS Reports Services is peer-level, which means that all members of the cluster take equal responsibility for sharing and processing incoming requests. If one member is shut down, the other members carry on managing the request load. If the output is present in one member's cache, another member can use it. There is no single-point-of-failure, where one machine's malfunction brings the whole system down.

This chapter contains information about enrolling a server in a cluster and benefits of clustering servers together. It contains the following sections:

6.1 Cluster Overview

Assume you have the following servers:

                                 
serverA.cluster1
                                 
serverB
                                 
serverC.cluster1
                                 

                              

ServerA.cluster1 and serverC.cluster1 are members of the same cluster called cluster1. They cooperate to process requests from a client. If a client sends a synchronous request to serverA.cluster1 and it does not have an idle engine of the specific job type, then it checks to see if serverC.cluster1 does. If serverC.cluster1 does have an idle engine, then serverA.cluster1 passes the request to serverC.cluster1 for processing.

In this example, ServerB is a stand-alone server and cannot receive processing requests from other servers, nor can it send processing requests to other servers.

You can have an unlimited number of servers in a cluster. If a cluster member is shut down, then it redistributes its pending synchronous jobs to another server in the cluster. As long as one server in the cluster is running, the cluster is working.

When the cluster is making its decision as to where an upcoming scheduled or immediate request should be processed, it prioritizes according to the following criteria:

  1. Does any server in the cluster have information in cache that matches the request?

  2. Is there a current, similar job in the queue?

  3. Is an idle engine of the particular job type available?

  4. Is the number of currently active engines less then the MAXENGINE number specified for the server for that job type?

Both stand-alone and clustered servers share the same, basic configuration. The cluster has no special configuration requirements, beyond needing to share a common cluster name and common public and private keys. There are no limitations on the platform used, the number of servers in the cluster, or the location of the server. There is no requirement to share resources within the cluster servers.

Engine output is locally cached in a particular Reports Server within the cluster, but it is also known and available to the entire cluster. If a server is down, that server's cached files are no longer available for reuse. This means that another server within the cluster must rerun the request to obtain the output. When the server is running again, all of the cached files become available due to the persistent state of the cache.

6.2 Setting Up a Cluster

Clustering in Oracle9iAS Reports Services is as easy as naming all member servers with the same "dot extension," for example < server_name>.cluster or < server_name>.xyz, and ensuring that all member clusters share the same public and private key.

This section covers renaming your Reports Server, creating and specifying public and private keys, and submitting requests to a cluster. It contains the following sections:

6.2.1 Renaming a Reports Server

It is likely that you are reading this material after you've already set up at least one Reports Server. If this is the case, you'll need to change the name of your server to add the cluster name to the server name.

To rename a Reports Server:

  1. If the server is running, shut it down:

The keywords used with the rwserver command are described in Appendix A, "Command Line Arguments".

  1. If you have custom configuration settings in your Reports Server configuration file (< server_name>.conf), rename this file to the new cluster name (< server_name>.< cluster_name>.conf).

    You'll find the configuration file in the following path on UNIX and Windows:

                                         
                                        
    ORACLE_HOME\reports\conf\<
                                        
    server_name>.conf
                                         
    
                                      

    If you don't have custom configuration settings in your Reports Server configuration file, a new configuration file with the new name will be generated automatically when you restart the renamed server(s).

  2. Rename the Reports Server in all affected files, giving each cluster member the same cluster name.

    Before you restart your Reports Server(s), you may generate server public and private keys and enter the resulting information in each member server's configuration file. How to do this is discussed in the next sections.

    6.2.2 Generating New Public and Private Keys

    The server public and private key files aid with message encryption and authentication between cluster members. The default files are stored in the rwrun.jar file in the following path (on both UNIX and Windows):

                                         
                                        
    ORACLE_HOME\reports\jlib\rwrun.jar
                                         
    
                                      

    Each member of a cluster must have the same public and private key files specified in their configuration files (< server_name>.< cluster_name>.conf). To ensure that your cluster members share exclusive public and private key files, generate new versions of them when you set up your cluster. Servers that will not be members of the cluster can go on using the default keys provided with Oracle9iAS Reports Services.

    To generate new public and private key files, at the command prompt, enter the following command:

                                         
    java oracle.report.utility.KeyManager <
                                        
    public_key_file_name> <
                                        
    private_key_file_
    name>
                                         
    
                                      

    You can generate these files to specific directories by specifying the desired path in the command line along with the new public and private key file names. If you just specify the file name in the command line, the key files will be generated in the current directory.

    6.2.3 Entering Public and Private Keys in the Server Configuration File

    Once you generate new public and private key files, you must enter that information into all cluster members' Reports Server configuration files. You'll find each cluster member's version of this file in the following path for both UNIX and Windows on each server's host machine:

                                         
                                        
    ORACLE_HOME\reports\conf\<server_name>.<cluster_name>.conf
                                         
    
                                      

    To change public and private key files, go to the connection element in the server configuration file, and change (or add) entries for the cluster sub-element as follows:

                                         
    <cluster publicKeyFile="
                                        
    path and filename of new public key" 
    privateKeyFile="
                                        
    path and filename of new private key">
                                         
    
                                      

    You'll find more information about the connection element in Chapter 3, "Configuring Oracle9iAS Reports Services".

    6.2.4 Restarting the Reports Server

    Once you have renamed your cluster members and respecified a common public and private key for each, you may start up your Reports Servers to activate the cluster.

    To start up a Reports Server:

    Once you've renamed your cluster members, respecified your public and private keys, and restarted your Reports Servers, you've completed the process of setting up your cluster.

    6.2.5 Submitting a Request to a Cluster

    To submit a request to a cluster:

    In the Reports Servlet or JSP, specify:

                                         
    server=<
                                        
    cluster_name>
                                         
    
                                      

    For example, if you have two cluster members--one named mercury.cluster1, the other named venus.cluster1--then your server entry would be:

                                         
    server=cluster1
                                         
    
                                      

    The Reports Servlet or JSP will find a running Reports Server in the cluster and send the request to that Reports Server. Depending on the cache match or the server load, that Reports Server will either handle the request or redirect it to another server in the cluster.