| Oracle® Collaboration Suite Installation Guide 10g Release 1 (10.1.1) for Microsoft Windows Part Number B14484-01 |
|
|
View PDF |
| Oracle® Collaboration Suite Installation Guide 10g Release 1 (10.1.1) for Microsoft Windows Part Number B14484-01 |
|
|
View PDF |
Beta Draft
This chapter contains the following sections:
Section 10.1, "Understanding High Availability Configurations: Overview and Common Requirements"
Section 10.2, "Preparing to Install Oracle Collaboration Suite in High Availability Environments"
This section provides an overview of the high availability configurations supported by Oracle Collaboration Suite.
This section contains the following topics:
Section 10.1.1, "Understanding the Common High Availability Principles"
Section 10.1.3, "Installation Order for High Availability Configurations"
Section 10.1.4, "Requirements for High Availability Configurations"
Oracle Collaboration Suite High Availability Solutions installation includes the following primary components:
The Oracle Collaboration Suite Database tier is built on Oracle Database 10g that serves as the repository for the Oracle Collaboration Suite schema information and OracleAS 10g Release 10.1.2.0.1 Metadata Repository. The default version of the database when installed from Oracle Collaboration Suite is 10.1.0.4.2.
The processes in this tier are the database instance processes and the database listener.
For high availability, Oracle recommends that this database be deployed as an Oracle Real Application Clusters database in an active-active configuration.
An Oracle Collaboration Suite Database Oracle home is installed on each node of the hardware cluster. Each node has its own oraInventory which is shared by other Oracle homes on that node except for the Calendar Server Cold failover Cluster that has its own oraInventory.
The hardware requirements for the Oracle Collaboration Suite Database tier are as follows:
Hardware cluster with Oracle Cluster Ready Services
Shared storage for the Oracle Real Application Clusters database files and CRS registry and quorum device. Oracle Database files can be on RAW devices, Network Attached Storage (NAS), OCFS for Linux, or use Oracle Automatic Storage Management (ASM).
A virtual IP address for each cluster node
The Identity Management tier consists of the following:
Oracle Internet Directory tier
The Oracle Internet Directory tier may be colocated with the database tier or the OracleAS Single Sign-On tier or may be deployed separately. The colocation can be in terms of being on the same computer and in many cases, sharing the same Oracle home.
The main processes in this tier are the Oracle Internet Directory and Oracle Directory Integration and Provisioning processes.
For high availability, Oracle recommends that multiple instances of this tier be deployed or that the deployment be designed to fail over the service to any available computer. An active-active deployment of this tier requires a hardware load balancer.
OracleAS Single Sign-On tier
This tier is colocated with the Oracle Internet Directory tier or may be deployed separately. The colocation can be in terms of their being on the same computer and in many cases, sharing the same Oracle home. Also, typically the OracleAS Single Sign-On and Oracle Delegated Administration Services services are deployed together.
The main processes in this tier are the Oracle HTTP Server and the OC4J instances hosting the OracleAS Single Sign-On and Oracle Delegated Administration Services applications.
For high availability, Oracle recommends that multiple instances of this tier be deployed or that the deployment be designed to fail over the service to any available computer. An active-active deployment of this tier requires a hardware load balancer.
Oracle home is on each node of the hardware cluster. All Oracle homes use a single shared oraInventory on each node.
The hardware requirements for the Identity Management tier are as follows:
Single node
Local storage
A load balancer functions as a front-end of the nodes and routes requests to the Identity Management services on all nodes of the Oracle Identity Management cluster.
The Oracle Calendar server includes the file system-level database that stores all Calendar-related data. This database is not an Oracle Database, and therefore cannot provide the same high availability features of the Oracle Database. This Oracle Calendar installation includes only the Oracle Calendar server component and it does not include the Oracle Calendar Application System which will be deployed with the Oracle Collaboration Suite Applications Tier.
To ensure an Oracle Collaboration Suite high availability solution, the Oracle Calendar server (one server for each calendar node) is placed on a Cold Failover Cluster because it is a single point of failure. This Cold Failover Cluster installation requires shared storage for the Oracle home and oraInventory directory trees. The Oracle Calendar server file system database is contained under the Oracle home directory tree. To facilitate a cold failover cluster, a virtual IP address and host are required.
Oracle home and oraInventory are located on dedicated shared storage of the hardware cluster. This Oracle home should have a separate oraInventory from the Oracle home of other components so that when the shared file system is failed over, the oraInventory is also failed over with it using the same mount point.
The hardware requirements for the Oracle Calendar server are as follows:
Hardware cluster. In the case of Linux, Oracle Cluster Ready Services and any Linux Cluster Manager cannot coexist. As a result, the failover should be manual or the Oracle Calendar server should be put on a cluster separate from the Oracle Real Application Clusters database.
Shared storage for the Oracle Calendar server ORACLE_HOME and oraInventory directory.
A virtual IP address.
This tier contains all the Oracle Collaboration Suite Applications components, except the Oracle Calendar server, that are installed independently on multiple nodes. Typically, the applications tiers are deployed in the demilitarized zone (DMZ). DMZ is a part of the network, which is in between an intranet and the Internet, and is often referred as the neutral zone. It allows only certain services of the hosts in an intranet to be accessible to the hosts on the Internet. This sub network is specially used for public access servers such as web servers. A load balancer virtual server, forms the front end for multiple applications tiers. Client requests to the Oracle Collaboration Suite Applications tiers are load balanced across the Applications nodes by the load balancer using the load balancer virtual server.
Oracle home is installed on each node of the hardware cluster. All Oracle homes use a single shared oraInventory on each node.
The hardware requirements for Applications tier are as follows:
Single node
Local storage
A load balancer functions as a front-end to the Oracle Collaboration Suite Applications tier nodes and balances and routes requests to the active nodes of the cluster
This section explains the features of high availability configurations and provides a brief overview of the typical high availability configurations supported by Oracle Collaboration Suite. For a detailed description of the configurations, refer to the Oracle Collaboration Suite High Availability Guide.
Oracle Collaboration Suite supports the following types of high availability configurations:
The features of the high availability configurations of Oracle Collaboration Suite are as follows:
Shared storage: All nodes must have access to the shared storage. In the case of the Oracle Calendar server installation, only one node mounts the shared disk containing the ORACLE_HOME and oraInventory at any given time. All nodes running the Oracle Real Application Clusters database must have concurrent access to the shared storage which contains the Oracle Collaboration database. If the Oracle Mobile Data Sync feature is going to be used, then it also requires shared storage in the Oracle Collaboration Suite Applications tier.
Hardware cluster: A hardware cluster is a hardware architecture that enables multiple computers to share access to data, software, or peripheral devices. A hardware cluster is required for Oracle Real Application Clusters. Oracle Real Application Clusters takes advantage of such architecture by running multiple database instances that share a single physical database. The database instances on each node communicate with each other by means of a high speed network interconnect.
Nonclustered servers: You need multiple nonclustered servers for the Identity Management tier and the Oracle Collaboration Suite Applications tier. This does not apply to the minimal single cluster architecture as it is comprised of the hardware cluster nodes.
Load balancer: You need a load balancer to load-balance the requests to all the active nodes. The load balancer is required for Identity Management and Applications-related requests. The requests for the Identity Management and Applications tiers are routed through the load balancer virtual server names and ports.
This is a minimal configuration where all Oracle Collaboration Suite High Availability components, Oracle Collaboration Suite Database, Identity Management, Oracle Calendar server, and Applications, are installed on a single cluster. This architecture is not an out-of-box solution and requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration.
In this architecture, the Oracle Collaboration Suite database is installed on RAC and both Identity Management and Applications are configured as an active-active high availability configuration. The Oracle Calendar server is installed in a Cold Failover Cluster configuration as previously described.
A Single Cluster Architecture configuration has the following characteristics:
Active nodes: All the nodes in a Single Cluster Architecture configuration are active. This means that all the nodes can handle requests. If a node fails, the remaining nodes handle all the requests.
Shared disk: Typically, you install Oracle Collaboration Suite on the shared disk. All nodes have access to the shared disk, but only one node mounts the shared disk at any given time. However, Oracle Collaboration Suite Database is not on the shared disk that is mounted by a node at any given time. Also, all nodes running the Oracle Real Application Clusters database must have concurrent access to the shared disk.
Hardware cluster: This can be vendor-specific clusterware, Oracle Cluster Ready Services, or both.
Load balancer: You need a load balancer to load-balance the requests to all the active nodes. The load balancer is required for Identity Management and Applications-related requests. The requests for the Identity Management and Applications tiers are routed through the load balancer virtual server names and ports.
Figure 10-1 illustrates a typical Single Cluster Architecture configuration.
Figure 10-1 Typical Single Cluster Architecture Configuration
Refer to Chapter 11 for details on Single Cluster Architecture installation.
This architecture separates the different tiers on to multiple computers, by leaving the hardware cluster dependent tiers, the Oracle Real Application Clusters database and the Oracle Calendar Server Cold Failover Clusters installation on the hardware cluster in the secured intranet, rather than sharing nodes for all tiers as in the Single Cluster architecture. The Identity Management and Oracle Collaboration Suite Applications tiers are separated to a set of nonclustered computers residing in the DMZ. The "colocated" term refers to the fact the the Identity Management tier contains both the Oracle Internet Directory and Oracle Single Sign-On tiers in a single ORACLE_HOME. This architecture is not an out-of-box solution and requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration.
In this architecture, both Identity Management and Oracle Collaboration Suite Database are configured as an active-active high availability configuration.
Figure 10-2 illustrates a typical Colocated Identity Management Architecture configuration.
Figure 10-2 Typical Colocated Identity Management Architecture Configuration
Refer to Chapter 11 for details about Colocated Identity Management Architecture installation.
This configuration is very similar to the Colocated Identity Management Architecture. This architecture still separates the different tiers on to multiple computers, leaving the hardware cluster dependent tiers, the Oracle Real Application Clusters database and the Calendar Server Cold Failover Clusters installation, on the hardware cluster in the secured intranet. The difference from the Colocated architecture is that the Identity Management components, Oracle Internet Directory and Oracle Application Server Single Sign-On, are separately installed and distributed across multiple nonclustered servers in the DMZ. Thus, the name, Distributed Identity Management. This architecture is not an out-of-box solution and requires multiple installations of Oracle Collaboration Suite and manual postinstallation configuration.
In this architecture, Oracle Internet Directory as well as Oracle Application Server Single Sign-On shares an active-active high availability configuration. However, the high availability configuration for Oracle Collaboration Suite Database can either be active-active or active-passive.
Figure 10-3 illustrates a typical Distributed Identity Management Architecture configuration.
Figure 10-3 Typical Distributed Identity Management Architecture Configuration
Refer to Chapter 11 for details about Distributed Identity Management Architecture installation.
For all high availability configurations, you install the components in the following order:
Oracle Collaboration Suite Database
Identity Management components
If you are distributing the Identity Management components, you install them in the following order:
Oracle Internet Directory and Oracle Directory Integration and Provisioning
Oracle Application Server Single Sign-On and Oracle Delegated Administration Services
Oracle Calendar Server
Oracle Collaboration Suite Applications components
If you are plan to install Oracle Collaboration Suite in high availability environments, remember the following requirements:
Database requirement
You need to have Oracle Cluster Ready Services (CRS) installed. Subsequently when running the Oracle Collaboration Suite Installer, select Cluster Installation. This will install the Oracle Collaboration Suite Real Application Clusters database, including the Oracle Collaboration Suite Infrastructure. These steps are detailed in the Install guides.
Components requirement
Because the installer clusters the components in an Identity Management configuration, you must select the same components in the Select Configuration Options screen for all the nodes in the cluster.
For example, if you select Oracle Internet Directory, OracleAS Single Sign-On, and Oracle Delegated Administration Services for the installation on node 1, then you must select the same set of components in subsequent installations.
Clustering will fail if you select different components in each installation.
This section covers the following topics:
Section 10.2.1, "Review Recommendations for Automatic Storage Management (ASM)"
Section 10.2.4, "About Configuring SSL and Non-SSL Ports for Oracle HTTP Server"
If you plan to use ASM instances for the OracleAS Metadata Repository database, consider these recommendations:
If you plan to use ASM with Oracle Database instances from multiple database homes on the same node, then you should run the ASM instance from an Oracle home that is different from the database homes.
The ASM home should be installed on every cluster node. This prevents the accidental removal of ASM instances that are in use by databases from other homes during the deinstallation of a database Oracle home.
Before installing an Identity Management configuration, you must set up the following tasks:
Use the Same Path for the Oracle Home Directory (Recommended)
Configure Virtual Server Names and Ports for the Load Balancer
Configure Your LDAP Virtual Server to Direct Requests to Node 1 Initially
Configure Shared Storage for Calendar Oracle Mobile Data Sync
For all the nodes that will be running Identity Management components, use the same full path for the Oracle home. This practice is recommended, but not required.
Configure your load balancer with two virtual server names and associated ports:
Configure a virtual server name for LDAP connections. For this virtual server, you must configure two ports: one for SSL and one for non-SSL connections.
Note:
Ensure that the same ports that you configured for the LDAP virtual server are available on the nodes on which you will be installing Oracle Internet Directory.The installer will configure Oracle Internet Directory to use the same port numbers that are configured on the LDAP virtual server. In other words, Oracle Internet Directory on all the nodes and the LDAP virtual server will use the same port number.
Configure a virtual server name for HTTP connections. For this virtual server, you also must configure two ports: one for SSL and one for non-SSL connections.
Note:
The ports for the HTTP virtual server can be different from the Oracle HTTP Server
Listen ports.The installer will prompt you for the virtual server names and port numbers.
In addition, check that the virtual server names are associated with IP addresses and are part of your DNS. The nodes that will be running Oracle Collaboration Suite must be able to access these virtual server names.
Note that this procedure applies only to the LDAP virtual server configured on your load balancer. This does not apply to the HTTP virtual server configured on your load balancer.
Before you start the installation, configure your LDAP virtual server to direct requests to node 1 only. After you complete an installation on a node, then you can add that node to the virtual server.
For example, if you have three nodes:
Configure the LDAP virtual server to direct requests to node 1 only.
Install Identity Management components on node 1.
Install Identity Management components on node 2.
Add node 2 to the LDAP virtual server.
Install Identity Management components on node 3.
Add node 3 to the LDAP virtual server.
On your load balancer, set up cookie persistence for HTTP traffic. Specifically, set up cookie persistence for URIs starting with /oiddas/. This is the URI for Oracle Delegated Administration Services. If your load balancer does not allow you to set cookie persistence at the URI level, then set the cookie persistence for all HTTP traffic. In either case, set the cookie to expire when the browser session expires.
Refer to your load balancer documentation for details.
In a multiple mid-tier deployment there will be multiple Calendar Sync Server tiers. Thus, you must point each mid-tier to a central, unified storage location for this information. Failure to do this can result in many unnecessary slow (full) synchronizations.
See "Oracle Mobile Data Sync Tiers and Storage of Synchronization Information" in Oracle Collaboration Suite Concepts and Deployment Guide for details.
In Identity Management configurations, you install Oracle Internet Directory on multiple nodes, and in each installation, you enter the instance password in the Specify Instance Name and ias_admin Password screen.
The password specified in the first installation is used as the password for the cn=orcladmin and orcladmin users not just in the first Oracle Internet Directory, but in all Oracle Internet Directory installations in the cluster.
This means that to access the Oracle Internet Directory on any node, you must use the password that you entered in the first installation. You cannot use the passwords that you entered in subsequent installations.
Accessing the Oracle Internet Directory includes:
Logging in to Oracle Delegated Administration Services (URL: http://hostname:port/oiddas)
Logging in to Oracle Application Server Single Sign-On (URL: http://hostname:port/pls/orasso)
Connecting to Oracle Internet Directory using the Oracle Directory Manager
You still need the passwords that you entered in installations for logging in to Application Server Control.
When you are installing Identity Management configurations, the installer displays the Specify HTTP Load Balancer Host and Listen Ports screen.
This screen has the following two sections:
In the load balancer section, you specify the HTTP virtual server name and port number of the load balancer. You also indicate whether the port is for SSL or non-SSL requests.
In the Oracle HTTP Server section, you specify the port number that you want for the Oracle HTTP Server Listen port. You also indicate whether the port is for SSL or non-SSL requests.
The virtual server and the Oracle HTTP Server Listen port can use different port numbers.
You can use this screen to set up the type of communication (SSL or non-SSL) between client, load balancer, and Oracle HTTP Server. Three cases are possible:
Case 1: Communications between clients and the load balancer use HTTP, and communications between the load balancer and Oracle HTTP Server also use HTTP. Refer to Section 10.2.4.1.
Case 2: Communications between clients and the load balancer use HTTPS (secure HTTP), and communications between the load balancer and Oracle HTTP Server also use HTTPS. Refer to Section 10.2.4.2.
Case 3: Communications between clients and the load balancer use HTTPS, but communications between the load balancer and Oracle HTTP Server use HTTP. Refer to Section 10.2.4.3.
Note:
Because the values you specify in this dialog override the values specified in thestaticports.ini file, you should not specify port numbers for the Oracle HTTP Server Listen port in the staticports.ini file.To set up this type of communication, specify the following values:
HTTP Listener: Port: Enter the port number that you want to use as the Oracle HTTP Server Listen port. This will be the value of the Listen directive in the httpd.conf file. Enable SSL: Do not select this option. The installer tries the default port number for the SSL port.
HTTP Load Balancer: Hostname: Enter the name of the virtual server on the load balancer configured to handle HTTP requests.
HTTP Load Balancer: Port: Enter the port number that the HTTP virtual server listens on. This will be the value of the Port directive in the httpd.conf file. Enable SSL: Do not select this option.
Table 10-1 lists the screen and configuration file values.
Table 10-1 Case 1: Screen and Configuration File Values
| Values in Screen | Resulting Values in Configuration Files |
|---|---|
| HTTP Listener: Port: 8000
Enable SSL: Unchecked HTTP Load Balancer: Port: 80 Enable SSL: Unchecked |
In httpd.conf:
Port 80 Listen 8000 In Port <default port number assigned by installer> Listen <default port number assigned by installer> |
To set up this type of communication, specify the following values:
HTTP Listener: Port: Enter the port number that you want Oracle HTTP Server to listen on. This will be the value of the Listen directive in the ssl.conf file. Enable SSL: Select this option.
HTTP Load Balancer: Hostname: Enter the name of the virtual server on the load balancer configured to handle HTTPS requests.
HTTP Load Balancer: Port: Enter the port number that the HTTP virtual server listens on. This will be the value of the Port directive in the ssl.conf file. Enable SSL: Select this option.
In opmn.xml, the installer sets the ssl-enabled line in the Oracle HTTP Server section to true.
Table 10-2 lists the screen and resulting configuration file values.
Table 10-2 Case 2: Screen and Configuration File Values
| Values in Screen | Resulting Values in Configuration Files |
|---|---|
| HTTP Listener: Port: 90
Enable SSL: Checked HTTP Load Balancer: Port: 443 Enable SSL: Checked |
In httpd.conf:
Port <default port number assigned by installer> Listen <default port number assigned by installer> In Port 443 Listen 90 |
To set up this type of communication,specify the following values:
HTTP Listener: Port: Enter the port number that you want Oracle HTTP Server to listen on. This will be the value of the Listen directive in the httpd.conf file. Enable SSL: Do not select this option.
HTTP Load Balancer: Hostname: Enter the name of the virtual server on the load balancer configured to handle HTTPS requests.
HTTP Load Balancer: Port: Enter the port number that the HTTP virtual server listens on. This will be the value of the Port directive in the httpd.conf file. Enable SSL: Select this option.
The installer will change the following lines:
In opmn.xml, the installer sets the ssl-enabled line in the Oracle HTTP Server section to true.
In httpd.conf, the installer adds the following lines:
LoadModule certheaders_module libexec/mod_certheaders.so SimulateHttps on
Table 10-3 lists the screen and configuration file values.
Table 10-3 Case 3: Screen and Configuration File Values
| Values in Screen | Resulting Values in Configuration Files |
|---|---|
| HTTP Listener: Port: 9000
Enable SSL: Unchecked HTTP Load Balancer: Port: 443 Enable SSL: Checked |
In httpd.conf:
Port 443 Listen 9000 In Port <default port number assigned by installer> Listen <default port number assigned by installer> |
This section describes how to install the Oracle Calendar server in Cold Failover configurations.
In the Oracle Collaboration Suite high availability architectures, a Cold Failover Cluster configuration is used for the Oracle Calendar server. In a Cold Failover Cluster configuration, you have an active and a passive node, and shared storage that can be accessed by either node.
During normal operation, the active node runs the Oracle Calendar server processes and manages requests from clients. If the active node fails, then a failover event occurs. The passive node takes over and becomes the active node. It mounts the shared storage and runs the processes.
Figure 10-4 shows an Oracle Calendar server high availability configuration.
Figure 10-4 Oracle Calendar Server High Availability Configuration
Figure 10-4 depicts:
Storage devices local to each node.
Storage device that can be accessed by both nodes. You install Infrastructure on this shared storage device.
During normal operation, one node ("node 1") acts as the active node. It mounts the shared storage to access the Oracle Calendar server, runs the Oracle Calendar server processes, and handles all requests.
If the active node goes down for any reason, fails over the Oracle Calendar server processes to the other node ("node 2"), which now becomes the active node. It mounts the shared storage, runs the processes, and handles all requests. It is only if they have set up a package that the clusterware will automatically detect and fail over the processes, vip and the shared storage. With the default out-of-box OCS installation, you will need to manually failover the processes, vip and the shared storage.
These nodes appear as one computer to clients through the use of a virtual address. To access the Oracle Calendar server, clients, including Applications tier components, use the virtual address associated with the cluster. The virtual address is associated with the active node (node 1 during normal operation, node 2 if node 1 goes down). Clients do not need to know which node (node 1 or node 2) is servicing requests.
You use the virtual host name in URLs that access the Oracle Calendar server. For example, if vhost.mydomain.com is the virtual host name, the URLs for the Oracle HTTP Server and the Application Server Control would look like the following:
Before installing the Oracle Calendar Server in a high availability environment, perform the following tasks:
The "Event Log" service must be running on both nodes in the cluster. You can check it in the Services dialog. To access the Services dialog, perform the following task:
In Microsoft Windows 2000, select Start, Programs, Administrative Tools, Services.
In Microsoft Windows 2003, select Start, Administrative Tools, Services.
You need a virtual address to associate with the cluster. A virtual address consists of a virtual host name and an IP address. Clients access the OracleAS Cold Failover Cluster using the virtual host name. The virtual address is in addition to host name and IP address of each node.
To get a virtual address, consult your network administrator. Virtual host names and IP addresses are any valid host name and IP address in the context of the subnet containing the cluster.
Note:
You map the virtual host name and virtual IP address only to the active node. Do not map the virtual host name and IP address to both active and secondary nodes at the same time. When you fail over, only then map the virtual host name and IP address to the secondary node, which is now the active node.To verify that Microsoft Cluster Server (MSCS) is installed on a computer, check that you can launch the Cluster Administrator from the Start menu as follows:
In Microsoft Windows 2000, select Start, Programs, Administrative Tools, Cluster Administrator.
In Microsoft Windows 2003, select Start, Administrative Tools, Cluster Administrator.
Note that the "Cluster IP Address" and "Cluster Name" used by MSCS are different from the virtual host name and virtual IP created in the previous step.
You can use the Cluster Administrator to find out the name of your cluster.
You need a domain user to own the "OracleMSCSServices" service, which gets installed when you install Oracle Fail Safe.
The requirements for this user are as follows:
This user must be defined at the domain level (as opposed to a user defined locally) because you need to specify the same user on both nodes during installation.
Ensure that you do not have a local user with the same name on either node.
This user must have administrator privileges on both nodes in the cluster.
This user must also belong to the DBA group.
During Oracle Fail Safe installation, you must specify the domain and the user using the domainname\username format. If you are running on a Microsoft Windows 2000 domain, then you can also use the username@dnsDomainName format.
You need to install Oracle Fail Safe on the local storage of both nodes. Oracle Fail Safe is shipped with Oracle Application Server. It is available on the Oracle Fail Safe CD-ROM.
Overview of Steps to Install Oracle Fail Safe on Both Nodes
The sequence of steps for installing Oracle Fail Safe on each node is as follows:
Before you start installing Oracle Fail Safe, you need to know the domain and user who will own the "OracleMSCSServices" service. This service gets installed when you install Oracle Fail Safe. See Section 10.3.2.5, "Determine a Domain User to Administer Oracle Fail Safe" for details on this user.
Install Oracle Fail Safe on node 1. See details in the next section, "Steps for Installing Oracle Fail Safe".
Restart node 1.
Install Oracle Fail Safe on node 2.
Restart node 2.
Verify the cluster using Oracle Fail Safe Manager.
Steps for Installing Oracle Fail Safe
This section describes the screens for installing Oracle Fail Safe. For a full description of the screens, refer to the Oracle Fail Safe Installation Guide.
Table 10-4 Installing Oracle Fail Safe
| Step | Screen | Action |
|---|---|---|
| 1. | None | Insert the Oracle Fail Safe CD-ROM and double-click setup.exe to start up the installer. |
| 2. | Welcome | Click Next. |
| 3. | Specify File Locations | Name: Enter the name for this Oracle home.
Example: Destination Path: Enter the full path where you want to install Oracle Fail Safe. You must install Oracle Fail Safe on the local storage. Example: Click Next. |
| 4. | Select Installation Type | Select Typical.
This installs the following components:
Click Next. |
| 5. | Reboot Needed After Installation | This screen reminds you that you need to restart your computer after installation.
Click Next. |
| 6. | Summary | Click Install. |
| 7. | Oracle Services for MSCS Account/Password | Domain\Username: Enter the domain name and the username under which you want to run the OracleMSCSServices service.
Password and Confirm Password: Specify and confirm the password for the user. Click OK. |
| 8. | Configuration Assistants | This screen shows the progress of the configuration assistants. Configuration assistants configure components. |
| 9. | End of Installation | Click Exit to quit the installer. |
Verify the Cluster
After installing Oracle Fail Safe, verify the cluster using Oracle Fail Safe Manager.
Start Oracle Fail Safe Manager by selecting Start, Programs, Oracle - OracleHomeName, Oracle Fail Safe Manager.
OracleHomeName refers to the name that you gave to the Oracle home where you installed Oracle Fail Safe.
Enter the cluster name in Cluster Alias in the Add Cluster to Tree dialog. You have defined the cluster name by using Cluster Administrator. Click OK.
In the left frame, select the cluster. This causes Oracle Fail Safe Manager to display the Welcome dialog.
Click Verify Cluster.
You might see some warnings related to Oracle software. These warnings are expected because you have not installed any products in the cluster yet. However, if you see any system warnings, you should investigate them.
A group in Oracle Fail Safe is a logical collection of resources that will fail over to the standby node as a unit. Before you install OracleAS Infrastructure in an OracleAS Cold Failover Cluster, you must create a group using Oracle Fail Safe Manager, and add these resources to the group:
| To add this resource to a group: | Use This Tool |
|---|---|
| IP of virtual host | Oracle Fail Safe Manager |
| Virtual host name | Oracle Fail Safe Manager |
| Shared disk | Cluster Administrator |
Follow these steps to create and set up a group. This procedure creates a group with default attributes (for things such as failover and failback policies). You can change these attributes later if necessary. For details, see the Oracle Application Server High Availability Guide and the Oracle Fail Safe documentation.
Start Oracle Fail Safe Manager by selecting Start, Programs, Oracle - OracleHomeName, Oracle Fail Safe Manager.
OracleHomeName refers to the name that you gave to the Oracle home where you installed Oracle Fail Safe.
Expand the cluster on the left side.
Right-click Groups, and select Create from the pop-up menu. This starts up the Create Group Wizard.
Follow the screens in the Create Group Wizard to create a group called "OracleAS".
Table 10-5 Creating a group by using Create Group Wizard
| Step | Screen | Action |
|---|---|---|
| 1. | General | Enter the group name for the infrastructure resources and click Next. This guide calls the group "OracleAS". |
| 2. | Failback Policies | Select Prevent Failback and click Next. |
| 3. | Finish Creating the Group | Review the information and click OK. |
| 4. | Add Virtual Address | Click Yes. |
| 5. | Add Resource to Group - Virtual Address | Select Show networks accessible by clients.
Network: Select the name associated with the primary network interface card on the node. By default, it is "Local Area Connection". Host Name: Enter the virtual host name. Example: IP Address: Enter the IP of the virtual host name. Example: Click Next. |
| 6. | Finish Adding the Virtual Address to the Group | Review the information and click OK. |
Verify that you can see the group that you just created in Oracle Fail Safe Manager and that the group has the following resources:
IP address of the virtual host
Virtual host name (shown as Network Name)
By using Cluster Administrator, move the shared disk in which you will install OracleAS Infrastructure into the group that you have just created in Oracle Fail Safe Manager.
Start up Cluster Administrator from the Start menu as follows:
For Microsoft Windows 2000, select Start, Programs, Administrative Tools, Cluster Administrator.
For Microsoft Windows 2003, select Start, Administrative Tools, Cluster Administrator.
On the left side of the window, select the disk group that contains the shared disk.
Notice the "OracleAS" group on the left side of the window. This is the group that you created in Oracle Fail Safe Manager.
Drag and drop the shared disk from the right side of the window to the "OracleAS" group on the left side of the window. If the Cluster Administrator prompts you to confirm, then click Yes.
In Oracle Fail Safe Manager, check if the group includes the shared disk.
