Skip to main content

Oracle Transparent Network Failover Failback (TNFF)

Oracle offers a high availability feature called Oracle Transparent Network Failover Failback (TNFF). In an IBM pSeries environment, this works closely with HACMP/ES.


Tip: The Oracle9i RAC network selection mechanism must be well understood before planning and configuring HACMP/ES.

Interconnect network selection

The Oracle cluster interconnect networks can be configured using either a "private" or a "public" network type defined in HCMP/ES. The Oracle IPC traffic is sent over one of the networks. Oracle RAC chooses the network interface according to the following rules:

1. HACMP "service" networks are required.

Oracle chooses only HACMP/ES networks configured as "service".

2. Oracle uses the HACMP cllsif utility to determine the network interface.

Oracle uses the HACMP utility cllsif to determine which network interface to use based on the rules described below. Oracle chooses the network to use according to the cllsif alphanumeric sort list.

3. Private networks are preferred over public networks.

If there are multiple private networks under HACMP, RAC chooses the interconnect communication by performance quality in the following order: SPswitch > FDDI > Ethernet

Note: Although networks can be labeled inside HACMP as public or private, this attribute has no functional meaning. It's only a way for Oracle to make network selections.

4. Maximum is three networks.

Oracle will choose up to three networks. Oracle recommends two private and one (or more) public networks for the cluster interconnect.

The Network failover and failback sequence

A typical configuration, using common network hardware, has two private interconnects and one public interconnect scenarios.

If the first HACMP/ES private service network goes down, Oracle TNFF fails over to the second private service network. If the second private service network also fails, TNFF continues to fail over to the public network.

If any of the two failed private interconnects is restored, the TNFF fails back to that private service interconnect. If both failed private interconnects are fixed, then TNFF restores the RAC communication to the first listed private service network, according to the cllsif command output alphanumeric sort order.

Comments

Popular posts from this blog

Typical Oracle RAC configurations

All configurations are based on the following building blocks: Hardware Server nodes Storage Networking Software Operating system Cluster software Oracle RAC (application) Application architecture Oracle9i RAC on RAW devices is based on a shared disk architecture. Figure 2-1 shows a two-node cluster. The lower solid line is the primary Oracle interconnect, the middle dashed line is the secondary Oracle interconnect. For high availability, both these networks should be defined in the HACMP as "private". HACMP/ESCRM provides Oracle9i RAC with the infrastructure for concurrent access to disks. Although HACMP provides concurrent access and a disk locking mechanism, this mechanism is not used. Oracle, instead, provides its own locking mechanism for concurrent data access, integrity, and consistency. Volume groups are varied on all the nodes, thus ensuring short failover time. This type of concurrent access can only be provided for RAW ...

Configuring the virtual path devices

We recommend that you start with a "fresh" disk configuration, so it is a good idea to delete all previously configured FC adapters and their child (disk) devices. On node1, we checked which disks are still defined: {node1:root}/-> lspvhdisk0 0022be2ab1cd11ac rootvg activehdisk1 0022be2a3d02ead0 Nonehdisk2 0022be2a4cbbafd8 Nonehdisk3 none NoneThese are the internal SCSI disk drives {node1:root}/-> lscfg grep disk+ hdisk3 U1.9-P2/Z2-A8 16 Bit LVD SCSI Disk Drive (36400 MB)+ hdisk2 U1.9-P2/Z1-A8 16 Bit LVD SCSI Disk Drive (36400 MB)+ hdisk1 U1.9-P1/Z2-A8 16 Bit LVD SCSI Disk Drive (36400 MB)+ hdisk0 U1.9-P1/Z1-A8 16 Bit LVD SCSI Disk Drive (36400 MB)In order to include the ESS disks, run the configuration manager on each node: {node1:root}/-> cfgmgr -vSince ESS was configured with two host paths for each node (node1a and node1b), this results in two hdisks on the nodes. Actually, those two logical hdisks represent the same physical disk, accessed via the two ...

IBM SAN Multipath installation on Red Hat Enterprise Linux 5.X

This section describes the steps for installing Red Hat Enterprise Linux 5.2 on a multipath device. 1.Determine which multipath device your machine boots from. To do this, note down the LUN (Logical Unit) number of the bootable device that is made available by your Fibre Channel Adapter card during firmware boot. In the test environment, the firmware displays the boot disk, showing lun number 0.                           2.Start the installation by providing the keyword mpath in the kernel command line. In the test environment, linux mpath vnc was used. The Partitioning screen displays a list of multipath devices as mapper/mpath*. 3. Determine the multipath device that corresponds to the bootable device for the host being installed. Go back to the console window if using VNC, or start an alternate console. In the test environment, the System x® is hooked up to an RSA. In the remote control console,...