Veritas InfoScale™ 7.3.1 Installation Guide - Linux
- Section I. Introduction to Veritas InfoScale
- Section II. Planning and preparation
- System requirements
- Preparing to install
- Setting up the private network
- Setting up shared storage
- Planning the installation setup for SF Oracle RAC and SF Sybase CE systems
- Section III. Installation of Veritas InfoScale
- Installing Veritas InfoScale using the installer
- Installing Veritas InfoScale using response files
- Installing Veritas Infoscale using operating system-specific methods
- Completing the post installation tasks
- Section IV. Uninstallation of Veritas InfoScale
- Uninstalling Veritas InfoScale using the installer
- Uninstalling Veritas InfoScale using response files
- Section V. Installation reference
- Appendix A. Installation scripts
- Appendix B. Tunable files for installation
- Appendix C. Troubleshooting installation issues
Planning the private network configuration for Oracle RAC
Oracle RAC requires a minimum of one private IP address on each node for Oracle Clusterware heartbeat.
You must use UDP IPC for the database cache fusion traffic. The Oracle RAC UDP IPC protocol requires an IP address. Depending on your deployment needs, this IP address may be a dedicated IP address or one that is shared with Oracle Clusterware.
For Oracle and later versions, you must use UDP IPC for the database cache fusion traffic.
Note:
The private IP addresses of all nodes that are on the same physical network must be in the same IP subnet.
The following practices provide a resilient private network setup:
Configure Oracle Clusterware interconnects over LLT links to prevent data corruption.
In an Veritas InfoScale cluster, the Oracle Clusterware heartbeat link MUST be configured as an LLT link. If Oracle Clusterware and LLT use different links for their communication, then the membership change between VCS and Oracle Clusterware is not coordinated correctly. For example, if only the Oracle Clusterware links are down, Oracle Clusterware kills one set of nodes after the expiry of the css-misscount interval and initiates the Oracle Clusterware and database recovery, even before CVM and CFS detect the node failures. This uncoordinated recovery may cause data corruption.
Oracle Clusterware interconnects need to be protected against NIC failures and link failures. For Oracle RAC 11.2.0.1 versions, the PrivNIC or MultiPrivNIC agent can be used to protect against NIC failures and link failures, if multiple links are available. Even if link aggregation solutions in the form of bonded NICs are implemented, the PrivNIC or MultiPrivNIC agent can be used to provide additional protection against the failure of the aggregated link by failing over to available alternate links. These alternate links can be simple NIC interfaces or bonded NICs.
An alternative option is to configure the Oracle Clusterware interconnects over bonded NIC interfaces.
See High availability solutions for Oracle RAC private network.
Note:
The PrivNIC and MultiPrivNIC agents are no longer supported in Oracle RAC 11.2.0.2 and later versions for managing cluster interconnects.
For 11.2.0.2 and later versions, Veritas recommends the use of alternative solutions such as bonded NIC interfaces or Oracle High Availability IP (HAIP).
Configure Oracle Cache Fusion traffic to take place through the private network. Veritas also recommends that all UDP cache-fusion links be LLT links.
Oracle database clients use the public network for database services. Whenever there is a node failure or network failure, the client fails over the connection, for both existing and new connections, to the surviving node in the cluster with which it is able to connect. Client failover occurs as a result of Oracle Fast Application Notification, VIP failover and client connection TCP timeout. It is strongly recommended not to send Oracle Cache Fusion traffic through the public network.
Use NIC bonding to provide redundancy for public networks so that Oracle RAC can fail over virtual IP addresses if there is a public link failure.