Oracle Clusterware Network Configuration Concepts

Oracle Clusterware enables a dynamic Oracle Grid Infrastructure through the self-management of the network requirements for the cluster. Oracle Clusterware 12c supports the use of Dynamic Host Configuration Protocol (DHCP) or stateless address autoconfiguration for the VIP addresses and the Single Client Access Name (SCAN) address, but not the public address. DHCP provides dynamic assignment of IPv4 VIP addresses, while Stateless Address Autoconfiguration provides dynamic assignment of IPv6 VIP addresses.

When you are using Oracle RAC, all of the clients must be able to reach the database, which means that the clients must resolve VIP and SCAN names to all of the VIP and SCAN addresses, respectively. This problem is solved by the addition of Grid Naming Service (GNS) to the cluster. GNS is linked to the corporate Domain Name Service (DNS) so that clients can resolve host names to these dynamic addresses and transparently connect to the cluster and the databases. Oracle supports using GNS without DHCP or zone delegation in Oracle Clusterware 12c (as with Oracle Flex ASM server clusters, which you can configure without zone delegation or dynamic networks).

Note:

Oracle does not support using GNS without DHCP or zone delegation on Windows.

See Also:

Oracle Automatic Storage Management Administrator's Guide for more information about Oracle Flex ASM

Beginning with Oracle Clusterware 12c, a GNS instance can now service multiple clusters rather than just one, thus only a single domain must be delegated to GNS in DNS. GNS still provides the same services as in previous versions of Oracle Clusterware.

The cluster in which the GNS server runs is referred to as the server cluster. A client cluster advertises its names with the server cluster. Only one GNS daemon process can run on the server cluster. Oracle Clusterware puts the GNS daemon process on one of the nodes in the cluster to maintain availability.

In previous, single-cluster versions of GNS, the single cluster could easily locate the GNS service provider within itself. In the multicluster environment, however, the client clusters must know the GNS address of the server cluster. Given that address, client clusters can find the GNS server running on the server cluster.

In order for GNS to function on the server cluster, you must have the following:

  • The DNS administrator must delegate a zone for use by GNS

  • A GNS instance must be running somewhere on the network and it must not be blocked by a firewall

  • All of the node names in a set of clusters served by GNS must be unique

See Also:

"Overview of Grid Naming Service" for information about administering GNS