This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
The concept of a virtual server
is a very significant feature in a failover cluster that allows
smooth and seamless connectivity to clustered computing resources or
services by client applications.
To users and clients, connecting
to a database or service running as a clustered virtual server
appears to be the same as connecting to a single, physical server.
In fact, any node in the cluster, but usually the primary or
surviving node, can host the connection to a virtual server. The
user or client application will not know which node is actually
hosting the virtual server. As shown in the Figure 3.8, the Virtual
Server is an addressing mechanism for the client connections.
Figure 3.8: Cluster Access by
using Virtual Server
Server clusters manage the
virtual server as a resource that is mapped to the IP address or
network name. Application client connections to a virtual server are
made by a client session that knows only the IP address that the
cluster service publishes as the address of the virtual server. The
client view is simply a view of individual network names and IP
For example, in a typical
database cluster having two physical nodes, each with distinct IP
addresses, the cluster server configures an additional IP address,
usually termed as virtual server or host. This virtual host always
maps to the active node in the cluster where database service is
Whenever there is a failure in
the primary node, and the application or database is in disabled
function, the failover process begins as initiated by a script or
agent. Fail-over in host-based database system usually includes the
following steps in sequential order.
* Detecting failure by
monitoring the heartbeat and checking the status of resources.
* Reorganizing cluster
membership in the Cluster Manager.
* Transferring disk ownership
from the primary node to a secondary node.
* Mount the file system on
* Starting database instance on
* Recover the database and
rollback uncommitted data.
* Reestablishing client
connections to the fail over node (database)
The following are examples of
how a typical resource group is configured in a Veritas Cluster
server and Microsoft Cluster service.
Veritas Cluster Server (VCS),
Service Group is the basic unit of fail over. Service group fails
over to backup node when failure occurs at the primary node. Service
groups consist of related resources that work together to deliver
database service to clients. Service Groups allow the monitoring and
controlling of service availability as a whole, as opposed to the
individual items (servers, disks, software, etc.) The failure of one
critical item in the service group will cause the entire group to
fail over to another system.
In Oracle database
implementation within the framework of Microsoft Cluster Service (MSC),
the Cluster Group includes the following resources:
One or more virtual addresses,
each of which consists of an IP address and network name:
* The Oracle database server
* All disks used by the Oracle
* A Net8 (or SQL*Net) network
listener that listens on the virtual address (or addresses) of the
group for connection requests to the databases in the group
* An Oracle Intelligent Agent
configured to use one of the group?s virtual addresses (if Oracle
Enterprise Manager will be used to manage the database)
The Cluster group is the basic
failover unit in case of MSC. Oracle provides failsafe manager tools
to configure and manage Oracle database service failover with in MSC
The above examples demonstrate
that the database instance has been freshly started after required
resources are online. It is a mutually exclusive condition in which
the database instance resides on a primary node or on a backup node.