Tag Archives: Global Data Services

Oracle Global Data Services (GDS): Part 3 – Role-based Global Service Failover (for Active Data Guard)

In the previous blog post, we talked about GDS load balancing use cases. In this post, we will take a look at the role-based global service failover across databases – upon Data Guard role transition.

GDS is quite effective in achieving higher availability and improved manageability for the global services running on replicated databases. It takes into account configured global service placement policies while performing the service failover across databases.

Global services can be configured with a role attribute allowing specific services to be active only when the configured role matches the specific role of the database (primary, physical standby, snapshot standby, logical standby etc.).  Figure 1A depicts replicated databases in a GDS Configuration. Read Write service runs on the primary database while the Read Only service runs on the standby database. As illustrated in Figure 1B, when role transition happens in Data Guard Broker configuration, GDS relocates the global services automatically as per the role attribute. In the event when the last standby database in a Pool goes down, the Read Only service with the ‘Standby’ role can also be configured to failover to the primary.

 

GSF2A

Figure 1A: Role-based global services

GSF2BFigure 1B: Automatic relocation of global services upon Data Guard role transition

To achieve this capability, you would define the global services as shown below.

GDSCTL>add service -service order_entry_srvc -gdspool sales  –preferred_all –role PRIMARY

GDSCTL>add service -service reporting_srvc -gdspool sales  –preferred_all –role PHYSICAL_STANDBY –failover_primary

It is as simple as that. There is no need to write custom logic or database startup triggers to achieve this behavior.

In the next blog post, we will study the global service failover use case for Oracle GoldenGate.

Oracle Global Data Services (GDS): Part 2 – Load Balancing Use Cases

Oracle Database 12c Global Data Services galvanizes the asset utilization of replicated database resources. It allows connect-time and run-time load balancing, routing and service failover across replicated databases situated in any data center in any geographical region. With GDS, customers can now achieve these capabilities without the need to either integrate their High Availability stack with hardware load balancers or write custom homegrown connection managers. And remember that GDS comes with the Active Data Guard license and is also available to Oracle GoldenGate customers at no additional charge as well.

In this blog, we follow up on the introduction to GDS from Part 1 and walk through key use cases for workload balancing:
1. The first use case (shown below) is load balancing for reader farms:
readerfarmFigure 1: Load balancing of Read-Only workloads on a reader farm
Imagine a scenario where GDS is enabled for an Active Data Guard or Oracle GoldenGate reader farm with standby replicas located in both local and remote data centers. Let’s say a Read Write global service for Order Entry runs on the Primary database and the Read Only Global Services for Reporting run on the reader farm. Using GDS, the client connections are automatically load balanced among the Read Only global services running on the reader farm (across data centers). This capability improves resource utilization, performance and scalability with Read Only workload balancing on Active Data Guard or Oracle GoldenGate reader farms.

2. Another use case (as shown below) is load balancing of Read Write services among multi-masters within and across regions:

gds_ogg_lbsFigure 2: Load balancing for Read-Write workloads with GDS
Let’s take a scenario of active/active databases using Oracle GoldenGate in a GDS configuration. In this case the Read Write global service is configured to run on each of the masters. For this scenario, GDS automatically balances the Read Write workload among the databases in the GoldenGate multi-master configuration.

This wraps up our exploration of key Oracle Database 12c GDS load balancing use cases. In the next installment of the GDS blog series (Part 3), we will take a look at the use cases on Global Service failover across databases.

Oracle Global Data Services (GDS): Part 1 – Automated Workload Management for Replicated Databases

Introduction
Global Data Services is a key offering within Oracle’s Maximum Availability Architecture. It’s really a must-have for organizations that are using Oracle high availability technologies such as Active Data Guard or Oracle GoldenGate to replicate data across multiple databases. With automated workload balancing and service failover capabilities, GDS improves performance, availability, scalability, and manageability for all databases that are replicated within a data center and across the globe. And GDS boosts resource utilization, which really improves the ROI of Active Data Guard and GoldenGate investments. It does this in an integrated, automated way that no other technology can match. Plus it’s included with the Active Data Guard license – and since GoldenGate customers have the right to use Active Data Guard, it’s available to them at no additional charge as well.

Customer Challenges
Enterprises typically deploy replication technologies for various business requirements – high availability and disaster recovery, content localization and caching, scalability, performance optimization for local clients or for compliance in accordance with local laws. Oracle customers use Active Data Guard and Oracle GoldenGate to address all of these business requirements. They use Active Data Guard to distribute their Read-Only workload and GoldenGate to distribute not only Read workloads but also Read Write workloads across their replicated databases.

However when you’re trying to optimize workload management across multiple database replicas, you run into certain challenges that simply extend beyond the capabilities of replication technology. That’s because customers are unable to manage replicated databases with a unified framework and instead have to deal with database silos from an application and DBA’s perspective.

Let’s look at a couple of the main problems with database silos.
The first is under-utilized resources – for example, when one replica cannot be leveraged to shoulder the workload of another over-utilized database. This leads to suboptimal resource utilization, which can adversely affect performance, availability and of course cost. The other problem with silos is the inability to automatically fail over a service across databases – let’s say a production application workload is running against a particular replica. If that replica goes down due to an unplanned event, customers don’t have a mechanism that automatically and transparently relocates the Service to another available replica. When a replica fails that can lead to application outages.

Until the introduction of Oracle Global Data Services (GDS), there really wasn’t a way for enterprises to achieve Service Failover and load balancing across replicas out of the Oracle Stack. To address this, some customers have chosen to compile their own homegrown connection managers and others have integrated their HA stack with hardware load balancers. But these solutions still don’t address all of the issues:

Manual load balancing using homegrown connection managers, for example, incurs huge development costs and yet cannot optimize performance and availability for replicated systems. Special purpose network load balancers can help but they introduce additional cost and complexity – and they still can’t offer database service failover and centralized workload management.

Global Data Services Overview
Global Data Services delivers automated workload management, which addresses all of these key pain points. It eliminates the need for custom connection managers and load balancers for database workloads.

With a newly created concept called Global Service, Oracle Global Data Services extends the familiar Oracle RAC-style connect-time and run-time load balancing, service failover and management capabilities beyond a single clustered database. Capabilities that were so far applicable only to a single database can now be applied to a set of replicated databases that may reside within or across data centers. Customers can achieve these capabilities by simply setting the pertinent attributes of the Global Service.

workload balance

Figure 1: Workload balance – Maximize application performance with GDS

service_failover

Figure 2: Global Service Failover – Maximize application availability with GDS

GDS sits between the application tier and the database tiers of the stack. It orchestrates the Service high availability, Service level load balancing and routing. Global Services run on the databases but are managed by GDS. GDS algorithms take into account DB instance load, network latency between data centers and the workload management policies (region affinity, load balancing goals, DB cardinality, DB role, replication lag tolerance) that the customers can configure. These workload management policies are enabled via the attributes of a given Global Service.

What are the key capabilities that are really unique to GDS?

1. For performance optimization, there’s region-based workload routing, which automatically routes workloads to the database closest to the clients. For example, what if the customer has a requirement that all the clients/applications closer to the North American data center need to be routed to the database in the North American data center? Likewise, European clients may need to be routed to the European database. GDS addresses this problem by managing this workload routing automatically.

2. In addition, GDS provides connect time load balancing and supports run time load balancing – another key performance advantage.

3. For higher application availability, GDS enables inter-database service failover. If a replica goes down as a result of a planned or unplanned event, GDS fails over the service to another replica.

4. And it also offers role based global services. GDS will make sure that the global services are always started on those databases whose database role matches the role specified for the service. For example, if Data Guard undergoes role transitions, the global services are relocated accordingly, maintaining availability requirements.

5. For improved data quality, there’s also replication lag-based workload routing. This capability routes read workloads to a Data Guard standby whose replication lag is within a customer-specified threshold that’s based on business needs

6. By managing all of the resources of the replicas efficiently, customers are able to maximize their ROI because there are no longer any under-utilized servers.

This wraps up the introductory blog post on Oracle Database 12c GDS. We looked at the challenges of workload management for replicated databases and how GDS addresses those challenges. In the next blog, we will review some of the key capabilities of GDS and the tangible business benefits.