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. GDS improves the ROI of Active Data Guard and GoldenGate investments.

Note: GDS is included with  Active Data Guard and Oracle GoldenGate license.

This blog post describes the key components of the Oracle GDS architecture, namely, Global Service, GDS Configuration, GDS Pool, GDS Region, Global Service Manager (GSM), GDS Catalog, GDSCTL and GDS ONS Network.

Figure 1 illustrates a typical GDS architecture that has two data centers and two sets of replicated databases (SALES, HR).

Global Service

Distributed workload management for replicated databases relies on the use of Global Services. Global Services hide the complexity of a set of replicated databases by providing a single system image to database clients. The set of databases may include clustered or non-clustered Oracle databases (hosted on homogeneous or heterogeneous server platforms) which are synchronized with some form of a replication technology such as Oracle Data Guard, or Oracle GoldenGate etc. A client request for a Global Service can be forwarded to any database in the set.

GDS Configuration

A GDS Configuration is a set of databases integrated by the GDS framework into a single virtual server offering global services. The databases in a GDS configuration can be located in any data center. Within a GDS configuration, there can be various sets of replicated databases belonging to different domains that do not share anything besides GDS framework components that manage them.

Clients connect by specifying the global service name and need not know the architectural topology of the GDS configuration.

GDS Pool

A set of replicated databases within a GDS configuration providing a unique set of global services and that belong to a certain administrative domain is termed as a GDS Pool. Examples of a GDS Pool can be a SALES pool or HR pool etc. This segregation of databases in a GDS configuration into pools allows simplified service management and better security.

A given GDS configuration can comprise of multiple GDS Pools spanning across multiple GDS Regions.

GDS provides scalability on demand by allowing dynamic provisioning of databases. This means GDS provides the ability to add another replicated database to a pool (for example, SALES POOL) dynamically and transparently (as needed) to obtain additional resource capability to scale the application workloads. GDS allows this with no change to the application configuration or client connectivity.  The same transparency is attained during the removal of the databases from a given pool.

If an application suddenly needs lot of resources to process massive quarter-ending reports etc., a replica can be added to the given GDS Pool and the application can transparently start taking advantage of the newly added replica and work requests will automatically be sent to it. This does not require any application-level code modification.

GDS Region

A set of databases in a GDS configuration and the database clients are said to be in the same GDS Region, if they share network proximity such that the network latency between the members of a given region is typically lower than between the members of different regions. A GDS Region typically corresponds to a data center and clients that are in the geographical proximity to the data center. Examples of a GDS Regions are East region or West region etc.

A GDS Region can contain databases belonging to different GDS Pools. However, all the GDS Pools belong to the same GDS configuration. A database can be associated with at most one GDS Region, one GDS Pool and one GDS configuration. For high availability purposes, each region in a GDS configuration should have a designated buddy region, which is a region that contains global service managers that can provide continued access to a GDS configuration if the global services managers in the local region become unavailable.

Global Service Manger (GSM)

GSM is the “brain” of the GDS technology and is the central component of the GDS configuration. At a minimum, there must be one GSM per GDS Region. GSMs can be installed on any commodity server similar to the ones used for the application tier. The recommended approach is to deploy three GSMs per region for availability and scalability reasons.

A GSM can be associated with one and only one GDS configuration. All the GDS Pools share all the GSMs in a GDS configuration. Every GSM manages all global services supported by the GDS configuration.

A Global Service Manager provides the following set of functions:

• Acts as a regional listener that the clients use to connect to global services. Any GSM can forward a connection request to any database (in any GDS Region) that provides a given global service.
• Manages GDS configuration by making changes to the configuration data in all GDS components
• Gathers connection load balancing and performance metrics from all instances of the databases in the GDS configuration. Measures network latency between its own Region and all other GDS Regions and relays this information to all GSMs in other Regions.
• Performs connection load balancing routing (CLB) the client connections to the best database instance servicing a given global service in the GDS configuration – based on CLB metrics , network latency and the region affinity of the global service
• Generates FAN runtime load balancing (RLB) advisory and publishes it to client connection pools – based on Performance metrics and integrating them with estimated network latency
• Manages failover of global services
• Monitors availability of database instances and global services, and notifies clients via FAN HA events upon failure incidents

GDS Catalog

A GDS Catalog is a repository that keeps track of the configuration data and the run-time status of a given GDS configuration. Basically it contains information pertinent to Global Services, their attributes, GDS Pools, Regions, GSMs and database instances that are in the GDS configuration. Each GDS catalog is dedicated to one and only one GDS configuration. It is a recommended to host the GDS Catalog schema along with the other catalogs such as EM Cloud Control Repository and RMAN Catalog in a single consolidated database that is protected with Oracle-recommended MAA technologies.

GDSCTL / Enterprise Manager

GDS Configuration can be administered either by the GDSCTL command-line user interface or Oracle Enterprise Manager Cloud Control (EMCC) 12c graphical user interface. Administrators who have used SRVCTL will be quite familiar with the look and feel of GDSCTL. GDS is also supported by EMCC DB plug-in starting from 12.1.0.5.

GDS ONS Network

Oracle 12c FAN clients use the Oracle Notification System to receive FAN events. ONS runs outside the database and across the system with no database dependencies. When a database is stopped or fails, FAN posts the status change events immediately, and ONS delivers them immediately. Starting from Oracle Database 12.1, FAN is posted by Global Data Services (GDS) for spanning data centers. GDS takes into account the service placement attributes, automatically performs an inter-database service failover to another available database for planned maintenance that involves a data center change, and if unplanned outages occur, notifies failures of an entire database. The Oracle clients and connection pools are interrupted on failure events and notified when a global service has been newly started.

Each GSM instance contains an Oracle Notification Service (ONS) server. The ONS server is used to publish FAN HA events and RLB metrics, subscribed by the clients. All the ONS servers of the regional GSMs are interconnected and make up a regional ONS network. GDS clients connect to the ONS servers of all regional GSMs and its buddy region and subscribe to the relevant FAN events.

Client Connectivity in GDS

In a GDS enabled environment, the clients connect to the GSM listeners instead of the database listeners. GSM forwards the connection to the local listener (bypassing the SCAN listeners).

The TNS entry on the client side includes the specification of the endpoints of the GSM listeners. It must contain a list of addresses for each GDS Region – one list of local GSMs for load balancing and intra-region failover, and another list of addresses for remote GSMs for inter-region failover. CLB balances connection requests across GSM listeners and includes connect-time failover. Client connection requests are randomly distributed among all regional GSMs first.

The following snippet shows an example connect descriptor mapped to a TNS alias using GSM Listeners in the tnsnames.ora file.

sales_reporting_srvc =

(DESCRIPTION =(CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)    (TRANSPORT_CONNECT_TIMEOUT=3)

(FAILOVER=ON)

(ADDRESS_LIST =                                         /* GSMs of Datacenter1 */

(LOAD_BALANCE=ON)

(ADDRESS = (PROTOCOL = TCP)(HOST = gsm-host1a)(PORT = 1571))

(ADDRESS = (PROTOCOL = TCP)(HOST = gsm-host2a)(PORT = 1571))

(ADDRESS = (PROTOCOL = TCP)(HOST = gms-host3a)(PORT = 1571))

)

(ADDRESS_LIST =                                         /* GSMs of Datacenter2 */

(LOAD_BALANCE=ON)

(ADDRESS = (PROTOCOL = TCP)(HOST = gsm-host1e)(PORT = 1572))

(ADDRESS = (PROTOCOL = TCP)(HOST = gsm-host2e)(PORT = 1572))

(ADDRESS = (PROTOCOL = TCP)(HOST = gsm-host3e)(PORT = 1572))

)

(CONNECT_DATA =

(SERVICE_NAME = sales_reporting_srvc.sales.oradbcloud) (REGION=WEST)

Note: For clients close to Datacenter2, it would be better to put the 2nd address list before the 1st address list (in the tnsnames entry).

Clients load balance among local GSMs and use the remote GSMs, if all the local GSMs are unavailable. It is possible for a client to connect to a GSM in another region. Therefore, it is not possible to infer the clients region by the GSM it connects to. Clients specify global service name and which region they originate from.

Simplification of client configuration

In the client configuration files, (for a given replication), customers typically have to list all the database servers that a given service can run on. Any addition or deletion of these servers requires them to modify configuration files on each of the client nodes to reflect the servers that are part of the replication. Some customers, as part of role change, opt to make the DNS alias re-pointed to the current Primary/Master. Role-based PL/SQL triggers are used to bring up the services on the appropriate role for each replicated configuration.

However, with GDS, all these complexities disappear. GDS automatically addresses these scenarios and requires no change to the client configuration files or the DNS modifications or the need for any role-based triggers on any database of any GDS Pool that is under the governance of the shared GDS infrastructure.

Client Compatibility

GDS supports all clients for Connect-time load balancing and for the clients using Oracle connection pools and drivers (JDBC/UCP, OCI and Oracle Data Provider for .NET). It also supports the Run-time load balancing. Oracle WebLogic Active GridLink, Apache Tomcat, IBM Websphere and Red Hat JBOSS will leverage UCP. It is recommended that the clients use the version 12.1 or greater.

GDS – A Shared infrastructure for multiple replicated configurations

GDS is a shared infrastructure and in Oracle Database 12c, a single GDS configuration can manage up to:

• 300 Database Instances
• 1000 Global Services
• 20 GDS Pools
• 10 GDS Regions
• 5 GSMs per Region
• 1000 Mid-Tier connection pool based clients

Recommended GDS configuration:

• GDS catalog database (can be consolidated with EM Cloud Control repository and RMAN catalog) in a Data Guard configuration for HA/DR (MAA best practice)
• 3 GSMs per Region (GDS binaries installed on each GSM node)

Note: GDS supports both Policy and Administrator Managed RAC databases. It is recommended that Data Guard configuration is Broker enabled.

I plan to cover various use cases of GDS, in a series of blog posts. Coming soon!