| Port | Function |
| a | GAB |
| b | I/O fencing |
| d | Oracle Disk Manager (ODM) |
| f | Cluster File System (CFS) |
| h | VERITAS Cluster Server (VCS: High Availability Daemon) |
| o | VCSMM driver |
| v | Cluster Volume Manager (CVM) |
| w | vxconfigd (module for CVM) |
a
This is node-to-node communication. As soon as GAB starts on a node, it will look for other nodes in the cluster and establish port "a" communication
b
This is used for IO fencing. If you use RAC or VCS 4.x, you can use IO fencing to protect data disks. In RAC, as soon as the gab port membership changes, we will have a race for the coordinator disks, and some nodes will panic when they lose the race
d
This is a port used specifically in RAC, and specifically or ODM. Let's start by saying what ODM is, and then why it is needed. Oracle (like most other database managers) will try to cache IO before writing it out to disk (raw volumes or data files on a filesystem). The biggest problem comes in when Oracle tries to write to a filesystem. Each filesystem has it's own cache. As you can think, the general purpose filesystem cache is not the same as the very specific Oracle cache. The startegy used is very different between Oracle and the filesystem. A while ago, Veritas had a close look at how the Oracle cache works and how it sends IO to the filesystem. Veritas then wrote an extension for their filesystem (called Quick IO - QIO). With QIO, they got performance very close to the performance Oracle got on raw volumes. The rest of the filesystem comunity (read SUN UFS, IBM JFS, .....) thought that Oracle gave the information to Veritas and complained about it. Oracle then sat down and actually wrote a specification. This specification allows everyone to write their own library, and the Oracle will call this library to do IO. Oracle called this specification ODM (Oracle Disk Manager). The best is, that only Veritas ever wrote their own libraries for ODM. So, getting back to port "d". Port "d" is used for ODM to ODM communication in a RAC cluster. (wow, QIO, ODM and port "d" in one go !)
f
This is the main communications port for cluster file system.More than 1 machine can mount the same filesystem, but they need to communicate to not update the metadata (like inodes,super-block, free inode list, free data block list, etc.....) at the same time. If they do it at the same time, you will get corruption. There is always a primary for any filesystem that controls the access to the metadata. This control (locking) is done via port "f"
h
Well, now we've got GAB. The different nodes in the cluster needs to know what is happening on other nodes (and on itself) It needs to know which service groups, resources are online or offline or faulted. The program that knows all this info, is the "main" vcs program called "had". So on each machine, had needs to talk to GAB. This is done via port "h"
o
In RAC, the different Oracle instances need to talk to each other. GAB provides port "o" for this. So, port "o" membership will start when Oracle RAC starts
u
Not a port you would normally see, but just to be complete,let's mention it here. When a Cluster Volume Manager is started, it will need to do a couple of things. The access to changing the configuration of volumes, plexes, subdisks and diskgroups, needs to be coordinated. This means that a "master" will always need to be selected in the cluster (can be checked with the "vxdctl -c mode" command). Normally the master is the first one to open port "u". Port "u" is an exclusive port for registering with the cluster volume manager "master". If no master has been established yet, the first node to open port "u" will assume the role of master. The master controls all access to changes of the cluster volume manager configuration. Each node that tries to join the cluster (CVM), will need to open (exclusively) port "u", search for the master, and make sure that the node and the master sees all the same disks for the shared diskgroups.
v
OK, now that we've estabblished that there is a master, we need to mention that fact that each instance of volume manager running (thus on each node) keeps the configuration in memory (regardless if it is part of a cluster or not). This "memory" is managed by the configuration daemon (vxconfigd). We will get to the vxconfigd in a minute, but first port "v". So, port "v" is actually used to register membership for the cluster volume manager. (once the node got port "u" membership, the "permanent" membership is done via port "v". Only members of the same cluster (cluster volume manager cluster that is) are allowed to import and access the (shared) disks
w
The last port in cluster volume manager. This is the port used for the vxconfigd on each node to communicate with the vxconfigd on all the other nodes. The biggest issue is that a configuration change needs to be the same across the whole cluster (does not help that 1 node thinks we still have a mirrored volume and the others don't know a thing about the mirror)