Jean FRANCOIS blog [Weblogic / Java EE / SOA]

http://docs.oracle.com/cd/E21764_01/web.1111/e13737/gridlink_datasources.htm

Enfin un mariage consommé entre BEA Weblogic et Oracle Database. Le nouveau driver GridLink est un substitue du MultiDataSource pour se connecter à une DataBase Oracle en RAC (Real Application Clusters).

L’objectif étant d’utiliser les internes de la DataBase pour mieux coller à son architecture. Ce driver va plus loin est rend caduque tous les palliatifs de détection d’absence de ressource distante qui dégrade les performances du serveur d’application. Les avantages par rapport au MultiPool sont :

ü  Éliminer les tests de vérification de présence de base qui charge inutilement l’infrastructure (remonté de notification lors d’incident directement plutôt que test systématique de la connexion).

ü  Éliminer le polling pour être notifié d’une remontée d’un nœud DataBase.

ü  Cache l’infrastructure sous-jacente de la DataBase (Ajout ou suppression dynamique de nœud RAC sans modification de configuration Weblogic).

ü  Répartition de charge intelligente fonction de la charge des nœuds RAC (plutôt qu’un RoundRobine).

ü  Notification immédiate d’incident lors de perte sans devoir attendre de TIMEOUT (plus de perte de temps côté application).

ü  Conservation de la connexion sur une même transaction initiée par Weblogic (implémenté côté driver et non plus dans Weblogic) (non supporté en MultiDataSource dans le cas d’une transaction globale).

ü  Répartition sur les instances RAC lors de la création des connexions (un seul pool, plusieurs connexions différentes).

PRINCIPES

---

La différence du GridLink par rapport au MultiDataSource est qu’il n’utilise qu’un seul DataSource. Le MultiDataSource  est obligé de déclarer autant de pool que d’instance RAC.

   Ce driver utilise UCP (Universal Connection Pool) pour l’implémentation du pool et ses fonctionnalités de FCF (Fast Connection Failover) via les notifications d’événement FAN (Fast Application Notification). Cela permet de :

ü  Annuler et supprimer des connexions non valides.

ü  Arrêt transparent planifier ou non d’instance DataBase.

ü  S'adapter aux changements de topologie, tels que l'ajout ou la suppression d'un nœud.

ü  Distribution dynamique des requetâge selon la charge DataBase.

                                                                           

C’est la partie ONS (Oracle Notification Service) qui notifie le client de tout changement dans l’architecture RAC (tombé volontaire ou non de nœud, ajout ou suppression de nœud, indication de stress des nœuds). Cela permet au GridLink d’adapter la charger et les connexions dynamiquement à l’état du cluster RAC et rendre transparent tout changement d’architecture.

MOUVEMENT DE NOEUD

---

Ci-dessous un extrait de documentation qui explique comment sont gérées les connexions lors de mouvement de nœuds RAC.

Planned down Event

Planned outages are defined as database maintenance or other activities that are needed to perform at a known point in time. Support for these events is available where an Oracle RAC service can be gracefully shutdown. In such scenarios, any borrowed or inuse connections are not interrupted and closed until work is completed and control of the connection is returned to the pool. This provides an extremely efficient way in large heterogeneous customer environments to manage planned outages.

           

Unplanned down Event

Support for unplanned outages is provided by detecting and removing stale connections to an Oracle RAC cluster. Stale connections include connections that do not have a service available on any instance in an Oracle RAC cluster due to service-down and nodedown events. Borrowed connections and available connections that are stale are detected, and their network connection is severed before removing them from the pool. These removed connections are not replaced by the pool. Instead, the application must retry connections before performing any work with a connection. The primary difference between unplanned and planned shutdown scenarios is how borrowed connections are handled. Stale connections that are idle in the pool (not borrowed) are removed in the same manner as the unplanned shutdown scenario.

Up Event

Oracle RAC Instance Rejoin and New Instance Scenarios -Scenarios where an Oracle RAC cluster adds instances that provide a service of interest are supported. The instance may be new to the cluster or may have been restarted after a down event. In both cases, WebLogic Connection Pool for JDBC recognizes the new instance and creates connections to the node as required

LOAD BALANCING

---

Ci dessous un extrait de documentation qui explique comment et géré l’attribution de connexion

Load Balancing

The load balancing advisory service issues FAN events that advise clients on the current state of the cluster including advice on where to direct connections to. WebLogic Server connection pool receives load balancing advisory events issued by the database, and distributes connections to the RAC nodes accordingly as shown in the diagram below.

• Manages pooled connections for high performance and scalability

• Receives continuous recommendations on the percentage of work to route to database instances

• Adjusts distribution of work based on different back-end node capacities such as CPU capacity or response time

• Reacts quickly to changes in cluster reconfiguration, application workload, overworked nodes, or hangs

• Receives metrics from the Oracle RAC Load Balance Advisory. Connections to well performing instances are used most often. New and unused connections to under-performing instances will gravitate away over time. When distribution metrics are not received, connection is selected using a random choice

Connection Affinity

Connection affinity allows a connection pool to select connections that are directed at a specific Oracle RAC instance to provide the best performance for the customer applications. The pool uses run-time connection load balancing to select an Oracle RAC instance to create the first connection and then subsequent connections are created with an affinity to the same instance.

Transaction-Based Affinity

Transaction-based affinity is an affinity to an Oracle RAC instance that can be released by either the client application or a failure event. Applications typically use this type of affinity when long-lived affinity to an Oracle RAC instance is desired or when the cost (in terms of performance) of being redirected to a new Oracle RAC instance is high. WebLogic XA connections that are enlisted in a distributed transaction keep an affinity to the Oracle RAC instance for the duration of the transaction. In this case, an application would incur a significant performance cost if a connection is redirect to a different Oracle RAC instance during the distributed transaction.

The affinity will be established based on the global transaction id, instead of by individual data source, to ensure that connections obtained from different data sources that are configured for the same RAC cluster are all associated with the same RAC instance.  The LLR two-phase commit optimization will be supported by the RAC data source and will also participate in XA affinity.

The Universal Connection Pool Java library

has been integrated with WebLogic Server and been utilized by WebLogic GridLink data source implementation to provide the Fast Connection Failover, Runtime Connection Load Balancing and Affinity features

Oracle Database services (services)

are logical abstractions for managing workloads in Oracle Database. Services divide workloads into logically disjoint groupings.  Each service represents a workload with common attributes, service-level thresholds, and priorities.  Services are built into the Oracle Database, providing a single system image for workloads, prioritization for workloads, performance measures for real transactions, and alerts and actions when performance goals are violated. Services enable database administrators to configure a workload, administer it, enable/disable it, and measure workload as a single entity.

PARAMETRAGE

---

http://www.oracle.com/technetwork/middleware/weblogic/wls-jdbc-gridlink-howto-333331.html

Le fait de créer un DataSource de type GridLink avec le FAN active, désactive complètement les tests de validité de connexion (Test Connections On Reserve, Test Frequency) et de pooling (Connection Creation Retry Frequency). Ces paramètres peuvent être réactivés en désactivant le FAN.

Création d’un DataSource de type GridLink.

On  spécifie l’URL SCAN d’accès aux instances RAC.

Test de connexion en succès.

Spécification des instances ONS de notification avec les notifications FAN. On pourra spécifier ces certificats pour sécuriser les connexions avec les ONS Wallet.

Test de connexion en succès.

VALIDATION

---

http://www.oracle.com/technetwork/middleware/weblogic/wls-jdbc-gridlink-howto-333331.html

Pour vérifier le bon fonctionnement de l’infrastructure mis en place, vous pouvez utiliser une petite application (gridlank_ha.war) qui démontre la répartition de charge des connexions.