Insert VERITAS™ White Paper Title Here -...

W H I T E P A P E R

VERITAS High Availability Solution for Oracle Applications

VALIDATION REPORT

1

2

TABLE OF CONTENTS EXECUTIVE SUMMARY ........................................................................................................... 3 OBJECTIVES & STRATEGY..................................................................................................... 4 SYSTEM CONFIGURATION ..................................................................................................... 5

PRIMARY AND SECONDARY SITES ................................................................................... 5 VERITAS CLUSTERS............................................................................................................ 6 CLUSTER SERVER SERVICE GROUPS.............................................................................. 7 LOCALLY INSTALLED SOFTWARE ..................................................................................... 7 DISK GROUPS ...................................................................................................................... 8 NETWORK............................................................................................................................. 8

OTHER CONFIGURATION NOTES .................................................................................... 14 CLUSTER SERVER SERVICE GROUPS.............................................................................. 9

SWITCHOVER TEST CASES ................................................................................................. 16 CONCLUSION......................................................................................................................... 17 APPENDIX A – HARDWAE SPECIFICATIONS ...................................................................... 18 APPENDIX B – SOFTWARE SPECIFICATIONS .................................................................... 19

Copyright 2003 VERITAS Software Corporation. All rights reserved. VERITAS, the VERITAS Logo, and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies. Specifications and product offerings subject to change without notice.

3

EXECUTIVE SUMMARY Maintaining high levels of access to systems and data is essential as companies increasingly rely on enterprise resource planning (ERP), customer relationship management (CRM) and supply chain management (SCM) systems to manage their business. Implemented across the Global 2000, these systems simply cannot fail. Downtime is unacceptable and results in lost revenue opportunities, eroding customer and supplier confidence, and increased operational costs that can negatively affect company profitability. The direct relationship between top-line revenue growth and system availability is the compelling driver behind IT’s push to eliminate downtime risk across critical ERP, CRM and SCM systems. Providing continuous local and global access to Oracle eBusiness Applications across heterogeneous environments without compromising a quality user experience is a challenge to any IT organization. VERITAS has addressed the requirement for business continuity by offering a complete High Availability solution tailored for the Oracle Applications environment. The solution includes the following products: VERITAS Database Edition/High Availability (HA) for Oracle, VERITAS Cluster Server, VERITAS Volume Replicator, VERITAS Global Cluster Manager and VERITAS Cluster Server Agents for Oracle Applications. Packaged as a software bundle, the VERITAS High Availability solution for Oracle Applications provides customers with an out-of-the-box solution designed to optimize “time to value” and minimize total cost of ownership. VERITAS Database Edition/HA is an integrated suite of industry-leading VERITAS products engineered specifically to deliver an unprecedented combination of superior performance, easier manageability and continuous system and database access. VERITAS Cluster Server, the industry's leading open systems clustering solution, eliminates planned and unplanned downtime, facilitates server consolidation, and protects a wide range of applications in heterogeneous environments. VERITAS Volume Replicator delivers high-performance, flexible, storage-independent data replication services for maximum business continuity when data currency, integrity and availability are paramount. VERITAS Global Cluster Manager monitors and controls multiple, geographically distributed VERITAS Cluster Server™ configurations. It is a critical component of enterprises that require a complete disaster recovery strategy. The complete High Availability Solution ensures that Oracle Applications are always available (locally and globally), easy to manage and performing optimally. Browse the VERITAS Web site (www.veritas.com) for complete descriptions of these and other VERITAS products. This white paper reports the details of the integration validation performed by VERITAS Software. The results provide conclusive evidence that VERITAS’ High Availability Solution ensures comprehensive system availability for users of Oracle Applications.


4

OBJECTIVES & STRATEGY The first objective of the validation project was to create an out-of-the-box solution offering for the Oracle Applications architecture. The second objective was to verify the ability of VERITAS’ High Availability solution to switch over Oracle Application processes both locally and globally. A local switchover moves one or more Oracle Application components among systems that are in a single cluster. A global switchover migrates an entire application instance from one cluster site to another. Successful switchovers demonstrate VERITAS’ ability to provide High Availability services to Oracle Applications by protecting single-point-of-failure resources. The objectives were achieved using the following strategy:

• Assembled necessary hardware to create two production-quality operating environments (primary & secondary sites).

• Installed base software on each server in both clusters (VERITAS Database Edition/HA, VERITAS Volume Replicator, VERITAS Global Cluster Manager, and VERITAS Cluster Server agents for Oracle Applications).

• Installed Oracle Applications 11.5.7 to include: Concurrent Manager, Database Server, 9iAS Web Application Server, Forms Server, Forms Metrics Server, Forms Metrics Client, and Report Server. Installed components using Oracle’s Rapidwiz installer in a multi-node network configuration.

• Designed, developed and tested VERITAS Cluster Sever Agents for Oracle Application components.

• Defined local VERITAS Cluster Server service groups and resources.

• Configured VERITAS Volume Replicator to replicate data between primary site and secondary site.

• Configured VERITAS Global Cluster Manager to monitor clusters on the primary site and the secondary site.

• Developed comprehensive local and global switchover test plan. Executed resulting test plan.

• Performed functionality testing to verify that Oracle Application processes and database components continued to function properly during local and global switchover testing.

The validation project was hosted at the VERITAS Sunnyvale Data Center facility.


5

SYSTEM CONFIGURATION Figure 1 depicts the computing environment that supported the validation project. The paragraphs that follow further describe relevant portions of the environment.

System1

VxVM VxFSDBE VCS

VVR GCM

Web App Server(9iAS)


FormsServicesForms

Services

AdministrationServer


System2

VxVM VxFSDBE VCS

VVR GCM

OracleDatabaseOracle

Database

ConcurrentManager/

Reports Server

ConcurrentManager/

Reports Server

Shared Disk

Replication (VVR)Forms Srvr Database

Concurrent Mgr/RPTAdmin

App Srvr Forms Srvr Database

Concurrent Mgr/RPTAdmin

App Srvr

Shared Disk

Global Cluster (GCM)

Site A: Cluster 1

Site B: Cluster 2

Primary Secondary

System3

VxVM VxFSDBE VCS

VVR GCM



FormsServicesForms

Services



System4

VxVM VxFSDBE VCS

VVR GCM

OracleDatabaseOracle

Database

ConcurrentManager/

Reports Server

ConcurrentManager/

Reports Server

WANWAN

Oracle ApplicationsValidation Lab Configuration

Figure 1. Oracle Applications Architecture Diagram

PRIMARY AND SECONDARY SITES Primary and secondary sites were created to provide independent operating environments. Each site hosted one VERITAS cluster. Both clusters were supported by identical hardware, software and networking resources in the validation lab. Thus, the application could execute equally well in both environments. This is not required nor generally practiced in production implementations around the world. Most organizations carefully weigh the costs of building a secondary fail-over disaster recovery (DR) site and conclude that a degraded capacity is acceptable in the event they would experience a true data center disaster. To mitigate total cost of DR ownership, customers will often size the DR site for a QA or development copy of the Oracle Application. If a true disaster event occurs, the primary or production instance might fail over to a cluster that is running a development copy of the application. In this scenario, the implementation team can configure the fail over process in a way that will ensure the development Oracle Applications instance is shutdown prior to bringing the production instance online. This strategy provides the implementing organization with several benefits to include:

• The implementing organization can save money building out the disaster recovery site. For example, the primary site responsible for running the production instance might use 4 very large SMB machines (12 way machines) while the DR site might use 6 smaller 4-way machines. The DR site might have less capacity but still provides enough computing resource to run the production instance should a disaster


6

strike. The important point is that the primary and secondary sites do not have to look identical in terms of number and size of machines deployed.

• The implementing organization can save money building out DR site disk capacity. The SAN disk infrastructure can differ in terms of type but not size. For example, the storage architect might configure their production site with very expensive and very fast SAN disk arrays providing a total capacity of X terabytes. While he/she still needs to provide X terabytes of storage at the DR site to honor the full data replication role, the architect could choose less expensive SAN disk as a way to mitigate the total cost of ownership of the entire system. The VERITAS Volume Replicator product does not require the same disk array product on both sides of the replication link and works very effectively in a heterogeneous SAN environment.

• The DR site does not have to be passive. It is not always practical or cost efficient to build out a disaster recovery site for the sole purpose of serving a disaster event. Many organizations are looking to optimize their DR investment and leverage this capacity to perform useful work. As a result, the disaster recovery site is really a development center where this “extra” DR capacity is being used on a daily basis to support development and testing activity. This strategy provides the implementing organization a rich new way to provide computing resources for development, quality assurance and production without incurring additional overhead to build out a dedicated, “passive” DR site.

• Primary and secondary cluster designation is relative, not absolute. In other words, the primary site for a HQ instance of Oracle Financials is located at Site A. However, Site B might serve as the primary site for a separate “production” instance of Oracle Financials in a multi-national company where the company has decided to maintain a separate and distinct instance of Oracle Financials to support a wholly owned subsidiary. In this case, Site B might serve as the secondary site for the HQ Financials instance while Site A might serve as the secondary site for the “subsidiary” instance. The data center architect could configure a Site C to serve as a single DR site for both Sites A and B. The high availability architect has a number of very good choices and, in many cases, is able to leverage existing resources to achieve a level of protection not previously available at a manageable cost.

With a diverse set of design options, deployment of the high availability/disaster recovery solution for Oracle Applications yields reduced costs, increased utilization and greater instance manageability. VERITAS CLUSTERS VERITAS Cluster Server provides fail-over protection for Oracle Application component resources by encapsulating these resources into service groups. The service group is a collection of Cluster Server resources that are bound together into a unit and represent an application component. Using the VERITAS Cluster Server Administrator, the operations team can operate on the Cluster (start and stop), the service group (start, stop, switchover, freeze, etc) and on a service group resource (start, stop, monitor, and clean). In this specific case, VERITAS created service groups for the Oracle Web (9iAS) server, the Oracle Forms server components, the Concurrent Manager, the Oracle Administration service and the Oracle 8i Database. Oracle Application Service groups may execute on any system in the cluster. Each Oracle Application service group contains a set of dependent resources. Typically, VERITAS Cluster Server resources represent lower level components required by an application to operate successfully. Resource examples include: disk groups, disk volumes, file systems, IP addresses, NIC cards and dependent application processes. For example, the Oracle 9iAS service group has the following resources:

• VERITAS Disk group with 2x9GB LUNS • VERITAS Volume with 18GB of space • VERITAS File System with 18GB of space • The hme0 network interface card • A virtual IP address • An Oracle Listener Process • The 9iAS Web Application Server Processes


7

The file system resource is dependent on the volume resource, which, in turn, is dependent on the disk group resource. The virtual IP address is dependent on the NIC. The 9iAS Web Application server is dependent on both the virtual IP address resource and the file system resource. Encapsulating the Oracle application component resources into service groups that are system-agnostic transforms the servers in the cluster to merely containers in which the Oracle Applications component service groups may execute. VERITAS Cluster Server can start, stop, monitor and migrate the service groups on any server in the cluster in response to a server or resource fault. In like manner, the server administrator can proactively move a service group from one system in the cluster to another in order to perform preventative system maintenance or apply a patch. Refer to the VERITAS Cluster Server User’s Guide for complete descriptions of service groups and resources. CLUSTER SERVER SERVICE GROUPS Web Application Server (9iAS): The Oracle 11i Application Suite includes Oracle’s 9iAS Web Application Server. 9iAS is both an HTTP server and web applications server providing the Oracle eBusiness user the primary application interface in a thin-client model. 9iAS provides a web services application environment for both web and enterprise java bean containers. Oracle bundles 9iAS Release 1 with Oracle Applications. This service group includes the 9iAS Web Application Server and the SQLNET8 node listener. Forms Services: The Forms Services Service Group encapsulates the Oracle Forms Server, Forms Metrics Server process, Forms Metrics Client Process and the SQLNet8 Node Listener. The Forms Server works in conjunction with the Oracle Jinitiator Java Applet to provide users with interactive application forms. The Forms Metrics Server and Client processes provide Forms load balancing services. The Node Listener provides SQLNET8 network services for the other forms components. Concurrent Manager: This service group supports Oracle’s Concurrent Manger, Report Server and Node Listener. Concurrent Manager provides batch processing and scheduling services. Report Server provides backend engine support for Oracle Reports. Node Listener provides SQLNET8 network services for the Concurrent Manager and Report Server components. Administration Server: Installed as a separate component using the Oracle Applications 11i Rapidwiz installer, the administration server service group includes a SQLNET8 Node Listener process used to handle application administration requests. Oracle Database: The Oracle Database service group consists of the database engine process and the SQL listener process. Most Oracle Applications components depend on the database for persistent storage. In addition, Oracle metadata is stored in the database. Thus, the database is a vulnerable, single-point-of-failure resource for Oracle applications since only one instance of it may be active at a time. Replication Service Groups: Replication service groups were also implemented for the validation, but they are not shown n Figure 1. These service groups contain resources that perform the data replication functions provided by VERITAS Volume Replicator. Each application service group (e.g., Oracle Database, Concurrent Manager, Forms Services, Web Application Server and the Administration Server) has one associated replication service group that is responsible for replicating the application service group’s programs and data. A replication service group must always be online before its associated application service group is brought online. LOCALLY INSTALLED SOFTWARE Each cluster node was configured by first installing the operating system, VERITAS Volume Manager™, VERITAS File System™, VERITAS Database Edition/HA, VERITAS Volume Replicator, VERITAS Global Cluster Manager, and the VERITAS Cluster Server agents for Oracle Applications on internal disk. There are two Cluster Server agents for Oracle Applications: (1) VERITAS Cluster Server Agent for Oracle Applications and (2) VERITAS Cluster Server Agent for Oracle Applications Concurrent Manager. To complete the local installation,


8

the VERITAS Cluster Server NameSwitch agent also had to be installed on each cluster node. These components provide the foundation services that enable each server to be part of an Oracle Applications cluster. DISK GROUPS Each service group requires a dedicated file system, volume and disk group to store the service group’s data and programs. Dedicating the combination of file system, volume and disk group to a service group enables the service group to be independent and mobile by allowing this set of storage objects to be imported and exported on different servers in the cluster without affecting other service groups. VERITAS Cluster Server will shutdown each resource in the service group starting at the top of the resource hierarchy with the following results:

• As the file system resource is shutdown, the file system is unmounted • As the volume is shutdown, the volume is stopped • As the disk group is shutdown, the disk group is deported.

VERITAS Cluster Server initiates startup of the service group on another system in the cluster where each resource is started in dependent order. On the new system, the disk group will be imported, the volume started and the file system will be mounted. This sequence could not be accomplished if the Oracle Application component was installed on local system disk on one node in the cluster. Going beyond the context of a single cluster, VERITAS Volume Replicator is used to replicate the contents of each disk volume across the wide area network to the secondary site. While the replication can be synchronous or asynchronous, most installations will choose to asynchronously replicate Oracle Applications data from the primary to the secondary site. Asynchronous replication performs better as each disk write is logged on the local volume and control is passed back to the running Oracle Application without blocking on the synchronous I/O replication. VERITAS Volume Replicator will capture and replicate all “write” I/O across the link to include database writes, configuration file changes, and the application of Oracle Application patches. Figure 1 illustrates the overall architecture of the solution and shows the replication arrow going from left to right. This is true while Site A is running the Oracle Application instance. Once global switchover occurs and the Oracle Application is restarted on Site B, this arrow will point in the reverse direction indicating that volume replication is now going from the Site B volumes back to Site A. Switching replication direction occurs automatically when the application is migrated from one site to other. Complete data integrity is maintained before, during and after application migration. NETWORK Three types of networks were used in the validation environment: public Ethernet, private Ethernet and a storage area network. The public Ethernet provided standard TCP/IP-based access for administrators and users to access all servers and applications. The private Ethernets were configured as point-to-point connections between the two servers in each cluster. These private, dedicated connections support cluster heartbeat communications. Two private connections are configured between servers to provide redundancy. The storage area network enabled the shared disk environment. Each server had a fibre-optic connection to a Brocade switch, and the switch had a fibre connection to the A5200 disk array. A more detailed specification of the hardware and software used for the project is included in Appendix A.


9

CLUSTER SERVER SERVICE GROUPS Figure 2 below depicts the relationships between the Cluster Server service groups required to support a generic Oracle Applications installation. As the figure indicates, to start the application, the database server is first brought online. After it’s online, Forms Services and Concurrent Manager are started. Finally, the Web server is started to allow user access through a browser interface. Although the diagram depicts the service group dependencies for one Oracle Applications instance, there is no practical limit to the number of instances that can be included in a single cluster. Service group dependencies for each Oracle Applications instance would follow the same pattern.

Forms Services

ConcurrentManager/

Reports Server

OracleDatabase

Server

Web ApplicationServer

(9iAS R1)

Oracle Applications 11iService Group Dependency Diagram

Figure 2. Oracle Applications 11i Service Group Dependency Diagram


Figure 3 depicts the resource dependencies required to build an Oracle Applications 9iAS Web Application Server service group. The diagram illustrates that all disk-related and network-related resources must be online before starting the node listener and the 9iAS Web Application Server. Refer to the VERITAS Cluster Server Agent 1.0 for Oracle Applications Installation and Configuration Guide to learn more about configuring these resources and service groups.

Web ApplicationServer

NodeListener

NetworkInterface

Virtual IP Mount

Disk Group

Oracle Applications 11iWeb Application Resource Dependency Diagram

Figure 3. Oracle Applications 9iAS Resource Dependency Diagram


10

Figure 4 illustrates resource dependencies for the set of components that constitute an Oracle Applications Forms Services service group. Notice the underlying infrastructure resources look similar to the Oracle 9iAS Web Application Server service group to include the virtual IP address, the network interface and the disk resources. All of the Oracle Forms servers share this common infrastructure but are configured to use a different virtual IP address and different mount point. Again, refer to the VERITAS Cluster Server Agent 1.0 for Oracle Applications Installation and Configuration Guide to learn more about configuring these resources and service groups.

FormsServer

FormsListener

NetworkInterface

Virtual IP Mount

MetricsServer

MetricsClient

Disk Group

Oracle Applications 11iForms Services Dependency Diagram

Figure 4. Oracle Applications Forms Services Resource Dependency Diagram


11

Figure 5 shows a resource dependency diagram for the Oracle Applications’ Concurrent Manager (CM) and Report Server. It is important to note the dependency between the Concurrent Manager Server and the VERITAS NameSwitch resource. Concurrent Manager is sensitive to the underlying hostname (uname –n) at startup and uses this information to locate configuration files and to download scheduling information from the supporting Oracle Database server. It is also important to note the dependency between Concurrent Manager and Node Listener resource. Concurrent Manager cannot successfully start until it has established a session with the Node Listener. Further details and explanation of these important dependencies are explained in the Configuration Notes section of this paper.

NodeListener

NetworkInterface

Virtual IP Mount

Disk Group

ReportServer

ConcurrentManager

Name Switch

Oracle Applications 11iConcurrent Manager Dependency Diagram

Figure 5. Oracle Applications Concurrent Manager Resource Dependency Diagram


12

Figure 6 illustrates the resource dependencies used to setup Oracle Applications Administrative services. The Oracle Applications Administrative Server is based on a specialized Node Listener. The Oracle Applications Rapidwiz installer allows for a separate installation of the administrative listener so it can run independent of the other Oracle Applications components.

AdministrativeNode Listener

NetworkInterface

Virtual IP

Disk Group

Mount

Oracle Applications 11iAdministration Server Resource Dependency Diagram

Figure 6. Oracle Applications Administrative Server Resource Dependency Diagram


13

14

OTHER CONFIGURATION NOTES Use the Oracle Applications 11i Rapidwiz Installer. In order to create a solution that embraced the most demanding Oracle Applications implementations, VERITAS used the “multi-node” installation option to the Oracle provided Rapidwiz installer. Following the detailed installation instructions provided for a multi-node installation in the installation guide titled, Installing Oracle Applications Release 11i (11.5.7), VERITAS used the following sequence to create their test instance of the Oracle Applications Vision Demo:

1. Created an Oracle Applications Staging Area. Created a dedicated disk group, volume and file system on shared disk to hold the application installation staging area.

2. Created Supporting Unix User Accounts, Group Accounts, Virtual IP Addresses. Created a separate Unix account for each service group and used the dba group account for all service groups. Created virtual IP addresses and hostnames for each component. VERITAS system engineers used NIS so they could create the user, group and virtual IP address in one place, using NIS to make this information on every node in the test cluster. The following table provides a example of the accounts created and the IP addresses used:

Oracle Applications Component

UNIX Account/ Group Account

Virtual Hostname Virtual IP Address

9iAS Web App Server oraweb/dba oracleweb/ oracleweb.veritas.com

10.127.5.21

Forms Services oraforms/dba oracleforms/ oracleforms.veritas.com

10.127.5.22

Concurrent Manager/ Report Server

oraccms/dba oracleccms/ oracleccms.veritas.com

10.127.5.23

Administration Server oraadms/dba oracleadms/ oracleadms.veritas.com

10.127.5.24

Oracle Database Instance oraappsdb/dba oracleappsdb/ oracleappsdb.veritas.com

10.127.5.25

3. Setup Disk Groups, Volumes and File Systems for Each Oracle Service Group. VERITAS system

engineers created a mount point for each service group on every system in the cluster. They then created a disk group, disk volume and file system for each Oracle Applications component to be included in the validation testing. The setup took on the following form:

Oracle Applications

Component Disk Group Mount Point Size

9iAS Web App Server oraweb /ora_apps/web 9 GB Forms Services oraforms /ora_apps/forms 18 GB Concurrent Manager/ Report Server

oraccms /ora_apps/ccms 9 GB

Administration Server oraadms /ora_apps/adms 18 GB Oracle Database Instance oraappsdb /ora_apps/database 45 GB Oracle Staging Area orastage /ora_apps/stage 25 GB

4. Generated an Oracle Applications Configuration File for Vision Demo. Using the Rapidwiz Installer,

a config.txt file was generated. It held the application installation configuration data for each Oracle Applications component which included: Web App Server, Forms Services, Concurrent Manager and Report Server, Administration Server and Oracle Database Server.

5. Setup VERITAS Cluster Server Service Groups for Each Component. Setup service groups for each component and created disk group, volume, mount, IP and NIC resources to get the service group initially populated.


15

6. Invoked Rapidwiz Multi-node Installer for Each Component. Installation can occur on a single host in the cluster. Mounted the staging area and each component’s file system before the team began each component install. Separately installed each component in the following order (provided some sample syntax to further clarify the team’s approach):

Oracle Applications Component

Mount Point Sample Installation Syntax

Oracle Database Instance (must be first)

/ora_apps/database # cd /ora_apps/stage/Stage11i/redCD/Disk1/rapidwiz # ./rapidwiz –servername oracleappsdb

9iAS Web App Server /ora_apps/web # cd /ora_apps/stage/Stage11i/redCD/Disk1/rapidwiz

# ./rapidwiz –servername oracleweb

Forms Services /ora_apps/forms # cd /ora_apps/stage/Stage11i/redCD/Disk1/rapidwiz # ./rapidwiz –servername oracleforms

Concurrent Manager/ Report Server

/ora_apps/ccms # cd /ora_apps/stage/Stage11i/redCD/Disk1/rapidwiz # ./rapidwiz –servername oracleccms

Administration Server /ora_apps/adms # cd /ora_apps/stage/Stage11i/redCD/Disk1/rapidwiz

# ./rapidwiz –servername oracleadms

7. Setup Remaining Service Group Resources. Completed the installation and setup by creating the

Oracle Application resources in each service group. This completed the configuration of the VCS cluster for Oracle Applications. Consult the VERITAS Cluster Server Agent 1.0 for Oracle Applications Installation and Configuration Guide and the VERITAS Cluster Server Agent 1.0 for Oracle Applications Concurrent Manager Installation and Configuration Guide for complete details on agent installation and resource setup.

Link the JDBC Properties Files. Each Oracle Application component will try to establish connectivity with the Oracle Database instance to obtain application-wide configuration information (11i instance meta-data). To successfully establish a database session, the application will perform a JDBC property file lookup to obtain the right database session information. The application server expects the JDBC property file to have the form, “ServerName_DBNAME.dbc” where ServerName is the local hostname defined by the output of the command, “uname –n” and DBNAME is the database name established during the installation. To avoid a JDBC property lookup problem, VERITAS created a soft-link of the JDBC properties file for each node name in the VERITAS cluster. Consult the VERITAS Cluster Server Agent 1.0 for Oracle Applications Installation and Configuration Guide and the VERITAS Cluster Server Agent 1.0 for Oracle Applications Concurrent Manager Installation and Configuration Guide for specific configuration details and examples.

Address Concurrent Managers Host Dependency Problem. It is important to note the dependency between the Concurrent Manager Server and the VERITAS NameSwitch resource. Concurrent Manager is sensitive to the underlying hostname (uname –n) at startup and uses this information to locate configuration files and to download scheduling information from the supporting Oracle Database server. If the hostname of the cluster node is not changed to match the Virtual Hostname of the Concurrent Manager prior to Concurrent Manager startup, the Concurrent Manager will attempt to use the administrative hostname of the cluster node to govern startup behavior. This will cause several Concurrent Manager startup errors. Most importantly, the administration name will not match any of the Concurrent Manager “nodenames” registered in the Oracle meta-data preventing the Concurrent Manager from downloading important report scheduling information. The Concurrent Manager will not function properly in this circumstance.

Use of the VERITAS NameSwitch agent solves this startup problem. The NameSwitch agent will change the underlying hostname to match the Concurrent Manager virtual hostname immediately prior to Concurrent


Manager startup. In like manner, when the Concurrent Manager instance fails-over to another machine in the cluster or an administrator chooses to offline the Concurrent Manager resource, the NameSwitch agent will switch the node name back to its original administrative name when the NameSwitch resource is signaled to go offline. Re-enforce Concurrent Manager Resource Dependency on Node Listener. It is also important to note the indirect dependency between the Concurrent Manager resource and the Node Listener. When Concurrent Manager starts, it seeks to establish a connection with the Node Listener. If the Listener is not present, the Concurrent Manager issues a sleep statement and waits before trying to connect again. After a series of unsuccessful connection attempts, the Concurrent Manager will core dump. To avoid this behavior, it is important to insure that the Node Listener is started and running prior to Concurrent Manager startup. Creating a dependency between Concurrent Manager and Node Listener resources best enforces this startup rule. Taking both dependencies into account, Figure 5 illustrates a solution showing the Concurrent Manager resource dependent on the NameSwitch resource, which, in turn, is dependent on the Node Listener resource. SWITCHOVER TEST CASES A test case is a set of test inputs, execution conditions and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. The purpose of a test case is to clearly describe all the conditions that will be implemented and are necessary to verify that the system is functioning as expected. (Source: Rational Unified Process) VERITAS engineers developed a series of local switchover, global switchover and basis test cases for the validation project. The local test cases validated the ability of VERITAS Cluster Server to manually switch over each service group among the system within a single cluster. The global test cases validated the ability of the complete solution to manually migrate the entire application (i.e., all service groups) from one site to another. The basis test cases verify that important Oracle Applications functions work properly before and after a switchover or migration is performed. All test cases followed the same basic two steps: 1) initiate a switchover, (either manually using the Cluster Server command-line interface or automatically by creating a fault condition); and 2) verify that the application is operational after the switchover is complete by performing the basis test cases. The results of executing the test cases are summarized in the following notes. The results demonstrate the flexibility of VERITAS Cluster Server to support either a symmetric or an asymmetric cluster configuration. • The entire application operated properly on both the primary and secondary clusters. • The 9iAS Web Application server successfully failed over and could run on any system in the cluster. It could

run concurrently with any other Oracle Applications component on the same physical system. Web application server switchover was transparent to the rest of the Oracle Application server processes.

• All components of the Oracle Forms service group successfully failed over and could run on any system in the

cluster. The Forms Server processes to include the Forms Server, Metrics Server and Metrics client could run concurrently with any other Oracle Applications component on the same physical system.

• Oracle Applications Concurrent Manager and Report Server successfully failed over and could run on any

system in the cluster. Concurrent Manager could run on the same system as the underlying Oracle Applications database server or on systems that did not physically host the database server. The NameSwitch agent and corresponding resource did have to change the hostname of the cluster node to successfully start the Concurrent Manager instance. The Concurrent Manager and Report Server processes could run concurrently with any other Oracle Applications component on the same physical system.

• All Oracle Applications server processes were indifferent about which physical system the database executed

on.


16

17

It’s important to note that each switchover was performed without an end-user load on the system. Thus, actual switchover times in a production environment will depend on the number of users, the types of transactions being performed and the supporting hardware resources. CONCLUSION The validation results offer clear evidence that VERITAS’ High Availability solution provides comprehensive system availability management for Oracle Applications — ensuring minimal planned and unplanned downtime. The High Availability solution will also reduce an organization’s IT costs due to its simplified implementation, platform independence, flexible configuration, ease of operation and breadth of supported hardware. To obtain the Cluster Server agents included in this solution, contact your VERITAS sales representative or VERITAS Enterprise Consulting Services. For additional information and guidance on configuring a highly available environment using VERITAS products, refer to the specific product’s documentation and to VERITAS’ High Availability white papers, which can be downloaded from the VERITAS Web site (www.veritas.com).


18

APPENDIX A – HARDWARE SPECIFICATIONS The table below provides the detailed hardware configuration for the project. HARDWARE SERVER

Host

Machines 4 x Sun E220R Processor Sparc Clock rates 450 MHz

System Memory

System memory 1GB

Disk I/O Ultra2 Wide SCSI Narrow Single Ended SCSI

Disk Controllers

Fibre Card QLogic QLA2202F/66

Disks

Internal storage 2x36GB SAN storage SAN attached Sun A5200 disk array available to all nodes in the cluster

SAN Brocade 2800

Network Cards:

Network Interface Single Internal Port Quad Port Card


19

APPENDIX B – SOFTWARE SPECIFICATIONS The table below provides the detailed software configuration for the project. SOFTWARE

Operating system Sun Solaris 8.0, 64-bit

Volume Manager VERITAS Volume Manager 3.5

File System VERITAS File System 3.5

HBA Driver Emulex LP8000-F1 driver

High Availability

VERITAS Cluster Server 3.5 with the following Agents: • VCS Agent 1.0 for Oracle Applications • VCS Agent 1.0 for Oracle Applications Concurrent Manager • VCS Enterprise Agent 2.0.1 for Oracle • VCS Enterprise Agent 2.0 for VERITAS Volume Replicator • VCS Agent 2.0 for NameSwitch

VERITAS Global Cluster Manager 3.5

Application Oracle Applications 11i (11.5.7) Vision Demo

Database Oracle 8.1.6

Database Acceleration VERITAS Database Edition 3.5 for Oracle

HTTP Server Oracle Applications 9iAS Release 1


20

VERITAS Software Corporation Corporate Headquarters 350 Ellis Street Mountain View, CA 94043 650-527-8000 or 866-837-4827

For additional information about VERITAS Software, its products, or the location of an office near you, please call our corporate headquarters or visit our Web site at www.veritas.com.


http://www.veritas.com/

Date post:	11-Mar-2018
Category:	Documents
Upload:	duongliem
View:	217 times
Download:	1 times

Insert VERITAS™ White Paper Title Here -...

Documents