| Oracle® Collaboration Suite High Availability Configuration Release 2 (9.0.4) for UNIX and Linux Part Number B15612-01 |
|
|
View PDF |
| Oracle® Collaboration Suite High Availability Configuration Release 2 (9.0.4) for UNIX and Linux Part Number B15612-01 |
|
|
View PDF |
This chapter provides an overview of the high-availability architecture for deploying Oracle Collaboration Suite. It contains the following sections:
Section 2.1, "Sample High-Availability Oracle Collaboration Suite Architecture"
Section 2.2, "Infrastructure Database and Oracle Internet Directory Tier"
Section 2.3, "Oracle Calendar Server and Oracle Files Domain Controller Tier"
Section 2.4, "Oracle9iAS Single Sign-On and Oracle Delegated Administration Services Tier"
Section 2.7, "Network Planning for Oracle Collaboration Suite"
Figure 2-1 displays a sample high-availability architecture for deploying Oracle Collaboration Suite. In the rest of this document, this sample architecture has been used to describe the instructions for achieving high-availability deployment.
Figure 2-1 Sample High-Availability Oracle Collaboration Suite Architecture
In this document, the Oracle domain name, oracle.com, has been used as an example. Where required, you must change the Oracle domain name to the domain name of your organization.
The Infrastructure database and Oracle Internet Directory components are deployed on a two-node, hardware, active/passive, cold failover cluster on the intranet. The node on which these components are installed has a virtual host name. In Figure 2-1, this virtual host name is infraha. The setup of the Infrastructure database and Oracle Internet Directory tier is based on the instructions given in Oracle9i Application Server Infrastructure: Improved Availability with Hardware Clusters. This document provides information about implementing Oracle9i Application Server Cold Failover Clusters release 9.0.2 on Solaris. It can be accessed at
http://www.oracle.com/technology/products/ias/hi_av/9ias_cfc.pdf
In this setup, one node is active and the other is passive. A passive node is a node on which the operating system is running but no Oracle application has been started. There is one Oracle home directory, which is on a shared disk system along with the data files of the database. If a failover is necessary, then the database instance and Oracle Internet Directory processes will fail over to the surviving node. The Infrastructure database and Oracle Internet Directory passive node is the active node for Oracle Calendar Server and Oracle Files Domain Controller. This node has its own virtual host name.
When both nodes are available, one node will be active with the Infrastructure and Oracle Internet Directory components and the other node will be active with the Oracle Calendar Server and Oracle Files Domain Controller components. If either node fails, then the other node will have the Infrastructure, Oracle Internet Directory, Oracle Calendar Server, and Oracle Files Domain Controller running on it. This surviving node will have two virtual host names assigned to it.
To set up cold failover for Oracle Calendar Server, when you install the Oracle Calendar Server and Oracle Files Domain Controller components, follow the same setup as that used for the Infrastructure. Like the Infrastructure, there is one Oracle home that is on a shared disk system. Because the Oracle Calendar Server database is on the Oracle home directory tree, it will be accessible to the surviving node in the event of a failover.
In normal mode, the Oracle Calendar Server and Oracle Files Domain Controller tier will run on the same cluster as the Infrastructure, but on the other node. In Figure 2-1, if the Infrastructure is running on infra1 using infraha as the virtual host name, then Oracle Calendar Server and Oracle Files Domain Controller will run on infra2 using caldcha as the virtual host name. This strategy puts both nodes of the cluster to optimal use. You must ensure that each node has the resources required to simultaneously handle Oracle Calendar Server, Oracle Files Domain Controller, the Infrastructure, and Oracle Internet Directory at the same time in the event of a failover. If a failover occurs, then both virtual host names, infraha and caldcha, will be assigned to the surviving node. The Oracle Files Domain Controller process controls and manages the nodes that constitute the Oracle Files domain.
Alternatively, the Oracle Files Domain Controller can be placed on a Middle Tier node.
To install the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services tier, you must perform a single-node, Oracle Identity Management-only installation for the Infrastructure. During the installation, select only Oracle9iAS Single Sign-On and Oracle Delegated Administration Services as the components to be installed. Typically, this tier is installed in the demilitarized zone (DMZ).
To ensure availability, this tier has a minimum of two servers. Typically, these servers are not part of a hardware cluster. Both servers provide Oracle Delegated Administration Services and Oracle9iAS Single Sign-On services and are, therefore, functionally equivalent. If one server fails, then the other server continues to provide service.
In this architecture, a load balancer virtual server forms the front end of the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services tier. Middle Tier-access or end-user access to Oracle9iAS Single Sign-On and Oracle Delegated Administration Services is through the virtual server name of this Oracle9iAS Single Sign-On load-balancing server, which is ssolb in Figure 2-1. In this figure, incoming HTTP traffic for the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services is distributed between the servers ssomt1 and ssomt2.
Alternatives to deploying the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components to individual nodes are:
Deploying the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components on the Middle Tier
In such a deployment, the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components are deployed on the same nodes as the Middle Tier components in the DMZ, rather than on individual nodes. This reduces the number of servers required by half. If the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components are used for the entire organization, then combining them with the Middle Tier applications may compromise enterprise Oracle9iAS Single Sign-On availability during certain outages. Therefore, this is not the optimal deployment for high availability.
Deploying the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components on the Infrastructure tier
In such a deployment, the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components are deployed on the intranet. They would need to be configured for Internet access.
|
See Also: For more information about configuring the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services components for Internet access, refer to MetaLink note 255976.1. |
Typically, the Information Storage tier is deployed behind a firewall on the intranet. This tier uses Oracle Real Application Clusters. The default installation also sets up Oracle Net connection-time failover and cross-instance registration. The details of how this is set up are given in the tnsnames.ora and listener.ora files, which are in the $ORACLE_HOME/network/admin directory.
Typically, the Middle Tiers are deployed in the DMZ. In the setup illustrated in Figure 2-1, the hosts ocsmt1 and ocsmt2 are used for the Middle Tiers. A load balancer virtual server, ocslb, forms the front end of both Middle Tiers.
This tier contains all the Oracle Collaboration Suite application components, except Oracle Calendar Server and Oracle Files Domain Controller. As mentioned earlier, these two components reside on their own tier on the intranet. This tier connects to the Information Storage database by using the service name str.
Network planning for Oracle Collaboration Suite is a key component of the procedure for setting up a high-availability Oracle Collaboration Suite solution. Features that are fundamental to such a solution include a properly planned network with sufficient bandwidth to support peak network traffic and alternate network paths to increase availability of the network.
|
See Also: Network Planning for Oracle Collaboration Suite, which you can access at |
For a distributed cold failover cluster, a typical installation involves deploying the servers and load balancer on the Oracle9iAS Single Sign-On and Oracle Delegated Administration Services tier in the DMZ, and deploying the Infrastructure database and Oracle Internet Directory tier on the intranet. The installation described in this document is based on such a deployment. In some deployments, there might not be any firewalls separating the components.
By using a load balancer, you can ensure that the failure of a single server does not result in the loss of a critical resource. If one server fails, then the load balancer routes new requests to the other servers. In addition, to prevent the creation of single points of failure, you must deploy a redundant pair of load balancers. In the environment described in this document, F5 BIG-IP Load Balancer Limited has been used for the load balancer pair.
|
See Also: For information about using firewalls and load balancers, refer to Oracle9i Application Server: Firewall and Load Balancer Architectures at
|
