Overview of Oracle RAC - Expert Oracle RAC 12c - page 6

Oracle RAC is designed to provide scalability by allowing all the RAC instances to share database workloads.
In this way, Oracle RAC Database presents users with a logical database server that groups computing resources
such as CPUs and memory from multiple RAC nodes. Most times, with proper configuration using RAC features
such as services, Single Client Access Name (SCAN), and database client failover features, changes on the cluster
configuration such as adding or removing nodes can be done as transparently to the users as possible. Figure 1-1
illustrates an Oracle RAC configuration where users are connected to the database and can perform database
operations through three database instances.
This architecture also provides HA during a failure in the cluster. It can tolerate N-1 node failures, where N is
the total number of the nodes. In case of one or more nodes failing, the users connecting to the failed nodes are
failed over automatically to the surviving RAC nodes. For example, as shown in Figure 1-1 , if node 2 fails, the user
connections on instance 2 fail over to instance 1 and instance 3. When user connections fail over to the surviving
nodes, RAC ensures load balancing among the nodes of the cluster.
Oracle RAC 12cR1 introduced a new architecture option called Flex Clusters. In this new option, there are two
types of cluster nodes: Hub nodes and Leaf nodes. The Hub Nodes are same as the traditional cluster nodes in Oracle
RAC 11gR2. All of the Hub Nodes are interconnected with the high-speed interconnect network and have direct access
to shared storage. The Leaf Nodes are a new type of node with a lighter-weight stack. They are connected only with the
corresponding attached Hub Nodes and they are not connected with each other. These Leaf Nodes are not required
to have direct access to shared storage. Instead, they will perform storage I/O through the Hub Nodes that they
attach to. The Flex Cluster architecture was introduced to improve RAC scalability. Chapter 4 will discuss the detailed
configuration of this new feature in 12c.
Hardware Requirements for RAC
A typical Oracle RAC database requires two or more servers, networking across the servers, and the storage shared
by the servers. Although the servers can be SMP Unix servers as well as low-cost commodity x86 servers, it has been
an industry trend to move the database server from large SMP Unix machines to low-cost x86-64 servers running on
Linux OS, such as Red Hat Enterprise Linux and Oracle Linux.
It is recommended that all the servers in any Oracle RAC cluster should have similar hardware architecture.
It is mandatory to have the same OS, with possibly different patches among the servers on the same Oracle RAC.
In order to ensure load balancing among the RAC cluster nodes, in 11gR2, server pool management is based on
the importance of the server pool and the number of servers associated with the server pool, and there is no way to
differentiate between the capacities of the servers. All the servers on the RAC cluster are assumed to have similar
(homogeneous) capacity configuration such as CPU counts and total memory, as well as physical networks. If the
servers are different in capacity, this will affect resource distribution and session load balancing on the RAC. In Oracle
RAC 12c, the policy-based cluster management can manage clusters that consist of heterogeneous servers with
different capabilities such as CPU power and memory sizes. With the introduction of server categorization, server
pool management has been enhanced to understand the differences between servers in the cluster.
Each server should also have proper local storage for the OS, Oracle Grid Infrastructure software home, and
possibly for Oracle RAC software home if you decide to use the local disk to store the RAC Oracle Database binary.
Potentially, in the event of a RAC node failure, the workloads on the failed node will be failed over to the working
nodes; so each RAC node should reserve some headroom for the computing resources to handle additional database
workloads that are failed over from other nodes.
The storage where the RAC database files reside needs to be accessible from all the RAC nodes. Oracle
Clusterware also stores two important pieces of Clusterware components—Oracle Cluster Registry (OCR) and
voting disk files—in the shared storage. The accessibility of the shared storage by each of the RAC nodes is critical
to Clusterware as well as to RAC Database. To ensure the fault tolerance of the storage connections, it is highly
recommended to establish redundant network connections between the servers and shared storage. For example,
to connect to a Fibre Channel (FC) storage, we need to ensure that each sever on the cluster has dual HBA( Host Bus
Adapter) cards with redundant fiber links connecting to two fiber channel switches, each of which connects to two