Brief intro
There is a lot of hype on Virtualization. It is a $20
Billion market and although heavy transaction intensive applications and Oracle
RAC may not find its place in your Virtual Infrastructure today, someday they
surely will. Disk Virtualization, Network Virtualization, not only address the
increasingly crucial issues of cost but also taking a harder look at
manageability. Oracle RAC and Oracle installations have always been big deals.
If you do a search on Oracle’s site, you’ll find installation documents all
over the place.
Performance is where the meat is. Even in the virtualization
arena, there are some developments. There is a committee (A Non Profit
Organization) called SPEC that is working on a model for benchmarks. VMware
will be introducing its VMmark soon. Someday we will have a globally deployable
Oracle RAC on a Virtual Infrastructure, like the screenshot on my
blogpost!
In this article, we will focus on the workload management.
We will start our discussion and I hope to have my 4-node RAC ready on the
Enterprise Linux provided by Oracle on VMware’s ESX 3.0.1 server (latest
version) with enough memory and 4 vCPUs!
Introduction to Workload Management
Workload management helps us
manage and distribute our workload to provide us with peak performance and high
availability. So what all do we have in the Workload management?
- Services : If you remember the
Services Architecture, we created our service above our physical nodes to
provide not only transparency but it also masks the individual nodes to give us
a typical grid. This way we can group our RAC databases into separate entities.
We will also go ahead and create more entities (services) to address the needs
of our applications, such as OE, HR, Sales etc. - Connection Load Balancing :
This feature of ONS (Oracle Net Services, if you remember when you provide the
command to list all the processes , crsstat –t or plainly crsstat to get a
detailed description of all the processes) helps the connections get adequately
load balanced across the RAC. - High Availability : A RAC component that ensures that
the cluster is online all the time. - Fast Application Notification (FAN)
: This notifier alerts applications continuously on any changes in the
configurations and workload services. - Load Balancing Advisory : As the name suggests, this provides
the necessary information to applications regarding the service levels provided
by nodes. It advises the applications to make the requests at the best available
services by a given node depending on the policy defined by you (the DBA). - Fast Connection Failover : This
facilitates the Clients to rapidly failover to available nodes by being
adequately informed by FAN. - Runtime Connection Load Balancing
: Clients need to provide available connections in the Connection Pool in order
to complete a transaction, thus the name runtime. The continuity or the High
Availability is the core of the whole RAC operation and this intelligent
mechanism ensures that the operations are completed when started.
Let’s take a look at the above mentioned components.
Services
Although the Services is the core of the Service Architecture of RAC, and
can be an extended topic, lets just briefly see what it is about and we will
see what we can do in the upcoming example articles on more practical aspects
of services.
Now when a user connects to a database, it is preferable to connect to the service
layer by mentioning the service in the connection string. As I mentioned above,
we can create more services to address and logically differentiate the needs of
the clients and applications without mingling into the nodes. Let’s see various
service level deployments.
1.
Using Oracle Services
2.
Default Service Connections
3.
Connection Load Balancing
Oracle Services: This is a perfect way to manage applications or a subset of
applications. Simply, OLTP users, DWH/Batch Operations can have their own
services assigned to themselves. Service level
requirements should be the same for users /applications assigned to a service.
When defining a service, you have the opportunity to define which nodes will
support that service. They become preferred instances while the ones that
will provide failover support are known as available instances.
When you specify PREFERRED
instances, then a particular set of instances are brought in to assist and
support that service and the subset of applications. Should one or more of
these PREFERRED instances
fail, then the failover takes place and the services are moved over to the AVAILABLE instances. Should the failed
instances come back online the services will not fall back to the PREFERRED instances simply because it
has successfully met the service level requirement and is doing a fine job of
providing high availability. Thus, there is no need to enact another outage to
bring them back to the originally determined PREFERRED
instances. Do however note that you can easily fail them back to the original
situation by using FAN callouts.
Also, note that Resource profiles are
automatically created when you define a service. A resource profile takes care
of the manageability of the service and defines service dependencies for the
instance and database. Stopping a service would mean stopping the database and
the instances associated with the service, so use caution when you attempt to
bring down the services.
Services are integrated with Resource Manager thus
enabling us to restrict the resources that are being used by a service.
Consumer groups are mapped to the services so users connecting are members of
the specific consumer group. AWR (Automatic Workload Repository) helps us
monitor the performance per service.
ONS (Oracle Net Services) provides connection load
balancing. This can be simply done by setting the CLB goal in the listener, CLB_GOAL. It is also possible to specify
a single TAF policy for all users of a specific service by defining the FAILOVER_METHOD, FAILOVER_TYPE, etc.
Conclusion
In future articles we will continue what we’ve started here
and try to stay on course, describing the services deployment scenarios.
