Oracle RAC Administration – Part 15: Connection Load Balancing and FAN

Brief intro

In our last article, we looked at the service architecture.
We will continue our quest to understand the workload characteristics and the
load balancing connections in our Virtualized RAC.

Introduction to Workload Management

Connection Load Balancing

With Oracle Notification Services (ONS), we are able to have our RAC balance
our client connections across the nodes. The CLB (connection load balancing)
can be handled on the server-side or on the client-side. The client-side takes
care of the connection sharing across the Listeners, while server-side load
balancing manages and handles the connection requests to the most willingly
available node whose information is in turn provided to it by the LBA (Load
Balancing Advisory).

This in turn is analyzing the goals that may have been set for the LBA. You
can use a long goal or a short goal for this connection load balancing. Let’s
take a look at them both quickly.

Long Goals: Use long goals for applications that need long
uninterrupted connections. It is the default connection load balancing goal. To
see how to implement them, lets take a simple syntax. Using the DBMS_SERVICE and CLB_GOAL_LONG packages, you can define
the connection load balancing for long connections as follows and here FOKESERV
is our service:

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'FOKESERV'
        , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);

Short Goals: Think of quick and fast transactions like ordering or
placing a secure purchase like that on Amazon or any other place. You would
prefer to fill the order up fast and if, for any reason the process is delayed,
the connection is restarted, ensuring that the transaction is performed in a
short-lived connection.  Checking the syntax, here CARTSERV is the service
in question:

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'CARTSERV'
        , CLB_GOAL => DBMS_SERVICE.CLB_GOAL_SHORT);

Note: When you install your RAC with the DBCA (Database Configuration
Assistant), server-side load balancing is enabled by default. Also check out
the sample script in tnsnames.ora
file. The services created through the DBCA will have the Connection Load
Balancing default setting as CLB_GOAL=CLB_GOAL_LONG.

The ONS maintains client connections until the client decides to close the
connection or if a node fails or any other form of outage prevents the
continuity of that connection. However, if you configure TAF (transparent
application failover) then the connections are moved to another healthy
instance. For a typical SARG (Select Arguments), TAF can restart the query.
Alternately, from the client side, if you were accessing information on the
web, the search would simply carry on without you noticing the failover of the
connection to another node. However, if you were in the middle of a transaction
(INSERT, UPDATE, or DELETE) then the application must rollback the failed
transaction and submit it again. Any other session’s customizations must be
re-executed. However, in a normal processing scenario the sessions don’t move
irrespective of the workload changes, newer sessions are just redirected to
other nodes.

With the services, the deployment of TAF only becomes easier. By defining a
TAF policy for a service, all connections using this service will have TAF
automatically enabled for them. No client-side intervention is required,
meaning the server-side TAF setting will override the TAF setting at the client
level. In order to define the TAF policy you will need the DBMS_SERVICE
procedure:

EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'fokeserv.domain.com' 
, aq_ha_notifications => TRUE 
, failover_method => DBMS_SERVICE.FAILOVER_METHOD_BASIC 
, failover_type => DBMS_SERVICE.FAILOVER_TYPE_SELECT 
, failover_retries => 180 
, failover_delay => 5 
, clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);

Client-side load balancing is defined in your client
connection with the parameter LOAD_BALANCE=ON
(the default is ON). Upon
setting this parameter to ON,
Oracle will pick out an address from the address list at random and connect to
that node, thereby balancing the client connections across the cluster. Run the
command lsnrctl services
occasionally to see what services a listener supports.

FAN (Fast Application Notification)

As the Oracle RAC manual states:

FAN is a notification
mechanism that RAC uses to notify other processes about configuration and
service level information such as includes service status changes, such as UP
or DOWN events. Applications can respond to FAN events and take immediate
action. FAN UP and DOWN events can apply to instances, services, and nodes.

RAC publishes the FAN events the minute any changes are made to the cluster.
So, instead of waiting for the application to check on individual nodes to
detect an anomaly, the applications are notified by FAN events and are able to
react immediately.

FAN also publishes load balancing advisory (LBA) events.
Applications are in a position to take full advantage of
the LBA FAN events to facilitate a smooth transition
of connections to
healthier nodes in a cluster. One can take advantage of FAN is the following
ways:

  • When
    using integrated Oracle Client, the applications can use FAN with no
    programming whatsoever. Oracle 120g JDBC, ODP.NET and OCI would be considered
    as the components of the integrated clients.

  • Programmatic
    changes in ONS API make it possible for applications to still subscribe to the
    FAN events and can execute the event handling actions appropriately.

  • FAN
    can be implemented with server-side callouts on your database tier.

For instance, a typical DOWN
event will prevent any further disruption of service by cleanly terminating the
sessions on that failed node and notifying the user. Moreover, a typical UP event can address and allocate extra
resources for new incoming requests/ connections. There are however several
additional benefits with the server-side callouts, mainly you can utilize FAN
in order to:

  • Logging
  • Paging/SMS
    the DBA and/or to open trouble tickets when the resources fail to (re)start

  • Change
    resource plans or to shut down services when the number of available instances
    decreases, thus preventing further load on the cluster and keeping the RAC
    running until another healthy node is added to the cluster.

  • Automate
    the fail service back to PREFERRED
    instances when required.

Conclusion

In this article, we looked at the CLB and FAN. In future articles,
we will continue to discuss the services architecture and discuss FAN in detail
and take a look at the LBA.

»


See All Articles by Columnist
Tarry Singh

Tarry Singh
Tarry Singh
I have been active in several industries since 1991. While working in the maritime industry I have worked for several Fortune 500 firms such as NYK, A.P. Møller-Mærsk Group. I made a career switch, emigrated, learned a new language and moved into the IT industry starting 2000. Since then I have been a Sr. DBA, (Technical) Project Manager, Sr. Consultant, Infrastructure Specialist (Clustering, Load Balancing, Networks, Databases) and (currently) Virtualization/Cloud Computing Expert and Global Sourcing in the IT industry. My deep understanding of multi-cultural issues (having worked across the globe) and international exposure has not only helped me successfully relaunch my career in a new industry but also helped me stay successful in what I do. I believe in "worknets" and "collective or swarm intelligence". As a trainer (technical as well as non-technical) I have trained staff both on national and international level. I am very devoted, perspicacious and hard working.

Latest Articles