Configuration et Gestion des Services Oracle en Environnement RAC
A) Gestion des Services
1) Qu’est ce qu’un service ?
Un service sert à regrouper des sessions au cours desquelles le même type de travail est exécuté. Il offre des fonctions de gestion de la charge globale, il sert de base à la haute disponibilité des connections et offre une nouvelle dimension pour le réglage des performances «Service et SQL» remplace «Session et SQL».
2) Création d’un service
A l’aide des interfaces standards telles dbca, EM (Entreprise Manager), l’utilitaire srvctl et le package DBMS_SERVICES, vous pouvez créer, configurer, administrer, activer, désactiver et mesurer un service.
Pour la configuration de notre application, on a retenu l’utilitaire srvctl et le package DBMS_SERVICES.
3) Description de l’architecture :
Mtlunt8
Mtlunt9
BD : ADOP
Instance 1 : ADOP1@Mtlunt8
Instance 2 : ADOP2@Mtlunt9
Pour le déploiement de cette architecture, stockés dans le référentiel du cluster (OCR : Oracle Cluster Registry) afin d’être gérés par le CRS Clusterware d’oracle.
Service L_PBSTSC_CI : Ce service sera disponible sur les deux nœuds mtlunt89 et mtlunt97.
Il sert pour la lecture des schemas PBSTSC_CI..
Un compte et un role oracle sont associsés
Le service L_PBSTSC_CI sera configuré pour gérer l’équilibrage de charge entre les deux nœuds en utilisant la fonction de conseil du LBA (Load Balancing Advisory).
4) Configuration des services
a) Création des services
$ srvctl add service -d ADOP -s L_PBSTSC_CI -r ADOP1,ADOP2 -d: Le nom de la base de données
-s: Le non du service
-r: Instances pré-sélectionnées
-a: Instances disponibles en cas d’incidents.
b) Démarrage des services
$ srvctl start service -d ADOP -s L_PBSTSC_CIc) Arrêt des services
$ srvctl stop service -d ADOP -s L_PBSTSC_CId) Configuration et statut d’un service
$ srvctl config service -d ADOP$ srvctl status service -d ADOP1C) Equilibrage de Charge des Connexions
L’équilibrage de charge des connexions permet aux processus d’écoutes (listeners) de distribuer des demandes de connexions aux meilleures instances. Des mesures de performances sont utilisées par les listeners pour la prise de décision et pour sélectionner l’instance la mieux adaptée. Ce choix dépend de l’objectif d’équilibrage de charge (GOAL) défini pour le service.
On active la fonction de conseil LBA, lorsqu’on affecte la valeur DBMS_SERVICE.GOAL_SERVICE_TIME ou DBMS_SERVICE.GOAL_THROUGHPUT à l’objectif du service.
1) Service_time : Temps de réponse du service.
2) Throughput : Débit du service (Quantité de travail terminé en une unité de temps).
Les processus d’écoutes utilisent le paramètre DBMS_SERVICE.CLB_GOAL, pour distribuer les connexions. Ce dernier possède les valeurs suivantes :
1) Clb_goal_short : Utilisation de la fonction de conseil LBA
2) Clb_goal_long : Utilisation du nombre de session par service.
Pour gérer côté serveur l’équilibrage de charge et configurer la fonction d’enregistrement dynamique de la performance des services, il faut attribuer un nom TNS décrivant la liste des tous les processus d’écoute disponibles au paramètre d’ initialisation REMOTE_LISTENER de chaque instance. Ainsi, sur la base des informations sur la charge calculées par la fonction LBA et envoyées par chaque processus PMON, le listerner1 (Nœud : MTLUNT97) redirige la demande de connexion entrante vers le listener2 (Nœud : MTLUNT89) sur lequel le service correspondant fonctionne le mieux et vis versa.
Paramètre en 11g
remote_listener ADOPCRS:1521
D) Configuration de la fonction TAF
Cette fonction permet à une application de se reconnecter automatiquement au service si la connexion initiale échoue. Pendant la reconnexion, les transactions actives font l’objet d’une annulation (Rollback), mais la fonction TAF donne la possibilité de reprendre l’exécution d’une instruction SELECT qui était en cours.
Cette fonction prend en charge deux méthodes de gestion des incidents :
1) BASIC : La connexion est rétablie au moment de l’incident.
2) PRECONNECT : Cette méthode est semblable à la méthode BASIC, à ceci près qu’une connexion de secours est créée pendant la connexion initiale afin d’anticiper les éventuels incidents.
Pour notre configuration on a retenu la première méthode. Pour activer cette dernière, il faut utiliser l’utilitaire srvctl et l’option –P BASIC à la création du service.
L’application doit se connecter au service via un descripteur de connexion. Le paramètre FAILOVER_MODE doit être inclus dans la section CONNECT_DATA du descripteur.
1) TYPE : Définit le type de gestion des incidents et à pour valeurs :
Ÿ SESSION : Signifie que seule la session utilisateur est authentifiée à nouveau côté serveur. Les curseurs ouverts dans l’application doivent être réexécutés.
Ÿ SELECT : Signifie que non seulement la session est authentifiée à nouveau côté serveur, mais encore les curseurs ouverts peuvent également poursuivre les fetchs.
2) METHOD : BASIC est utilisé pour rétablir une connexion au moment de l’incident.
3) RETRIES : Permet d’indiquer le nombre de tentatives de connexions après incidents.
4) DELAY : Permet de définir le délai, en secondes, entres les tentatives de connexions.
E) Définitions des Services et des Descripteurs de Connexions
Les services sont utilisés dans le fichier tnsnames.ora pour influencer quel noeud est à utiliser pour chaque application.
1) Service L_PBSTSC_CI1.1) Création du service$ srvctl add service -d ADOP -s L_PBSTSC_CI -r ADOP1,ADOP21.2) Démarrage du service$ srvctl start service -d ADOP -s L_PBSTSC_CI1.3) Activation de la fonction LBABEGINDBMS_SERVICE.MODIFY_SERVICE (service_name => L_PBSTSC_CI ' , goal => DBMS_SERVICE.GOAL_SERVICE_TIME , clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);END;1.4) Descripteur de connexion côté clientL_PBSTSC_CI = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = AdopCRS)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = L_PBSTSC_CI) ) )
Aucun commentaire:
Enregistrer un commentaire