Oracle RAC Administration - Part 14: Services Architecture in Workload Management

February 1, 2007

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.

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.

» See All Articles by Columnist Tarry Singh