Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
2.2. Sample Two-Node Cluster
The sample two-node cluster that will be used for this configuration is a simple cluster that can be configured for either of the two install types. Tips and Notes will be provided to help with the process of customizing the install to a particular set of business requirements.
Figure 2.1, “Sample Two-Node Oracle Cluster” shows a generalized overview of the configuration this installation yields. In this configuration, there are two nodes, each with a fencing agent and each connected to shared storage. A quorum disk has been configured. There is also an application tier network that accesses the nodes.
Figure 2.1. Sample Two-Node Oracle Cluster
Figure 2.2, “Cluster Node Connections” shows a generalized summary of the connections for each node in the configuration. Each node is connected to a public network, to a private network, and to shared storage. In addition, each node is configured with a fencing device that is also connected to the private network.
Figure 2.2. Cluster Node Connections
Note
RAC clusters are often configured to be symmetrical; the type of workload presented to the nodes is similar. In this topology, the servers are also of the same relative computing strength. Typically, the servers are over-configured by 50% in order for the failover node to handle the work of both nodes. However, this assumes that the business requirements for degraded operation are identical to normal operation, which is not always the case.
An alternative configuration is to build asymmetric topologies. In our simple two-node case, one node might be used to update the database (ETL - Extract, Transform and Load), and the other node may be used to run queries. Some nodes could be significantly larger in order to be dedicated to just one form of processing (e.g., Parallel Queries). Oracle RAC is not universally transparent to SQL workloads; awareness of when and where writes occur (SQL inserts, updates and deletes) can dramatically improve scalability, even in the two-node case.
Asymmetrical RAC topologies do have implications for failover, as a set of nodes might be tuned for queries and now must handle other work on behalf of the failed node. This topology is more common with higher node counts.
