EASYTEAM LE BLOG

Cet article décrit les bonnes pratiques à mettre en oeuvre dans un environnement Maximum Availability Architecture (MAA) pour que les clients Oracle basculent automatiquement sur la base de secours lorsque la base de production devient inaccessible soit du fait que le ou les serveurs de la base de données soient défaillants ou que nous soyons en présence d’un désastre partiel de site.

Environnement Oracle Maximum Availability Architecture (MAA)

 L’environnement Oracle se compose de deux clusters Oracle RAC 11gr2 constitués chacun de deux nœuds qui sont répartis sur deux sites distincts.

 Un site héberge la base de production que nous désignons par ‘PRODUCTION’ alors que l’autre site héberge la base de secours dont la synchronisation repose sur les mécanismes Dataguard et que nous dénommons ‘SECOURS’.

 Un service ‘oltp’ spécialisé dans les transactions est associé à la base de production alors qu’un service de ‘reporting’ est publié sur la base de secours qui utilise la nouvelle option d’Oracle 11gR2 ‘Active Dataguard’ qui permet d’accéder en lecture la base de secours en même temps que celle-ci est synchronisée (RECOVER).

Configuration des services Oracle au niveau du clusterware

 La définition des services doit être unique en fonction de la nature de la connexion du client qui peut être soit OCI ou JDBC, ainsi chaque type de client dispose d’un dispositif de notification différent pour détecter la disponibilité ou non du service. Le dispositif de notification pour les clients OCI  repose sur Oracle Advanced Queue (AQ) alors que les clients JDBC utilisent Oracle Notification Service (ONS).

 En premier lieu il convient de configurer par exemple les services oltp, reporting au niveau du cluster Oracle pour que l’application puisse se connecter à la base de données. Le service devra être créé et accessible en fonction du rôle de la base de données (Primary, Standby). Ainsi le service oltp sera disponible pour la base de données primaire (Primary) alors que le service reporting sera uniquement accessible sur la base de données de données de secours (Standby).

Configuration des services client OCI

La configuration des services sera donc fonction du rôle de la base de données dans le cluster Oracle.

• Cluster de production

srvctl add service –d production –s oltp_oci –r instance1,instance2 –l PRIMARY –q TRUE –e SESSION –m BASIC –w 10 –z 150
srvctl add service –d production –s reporting_oci –r instance1,instance2 –l PHYSICAL_STANDBY –q TRUE –e SESSION –m BASIC –w 10 –z 150

• Cluster de secours

srvctl add service –d secours –s oltp_oci –r instance1, instance2 –l PRIMARY –q TRUE –e SESSION –m BASIC –w 10 –z 150
srvctl add service –d secours –s reporting_oci –r instance1, instance2 –l PHYSICAL_STANDBY –q TRUE –e SESSION –m BASIC –w 10 –z 150

• Au niveau de la base de production (Primary) les services doivent être déclarés pour qu’ils soient propagés et appliqués sur la base de secours (Standby), ainsi tout client OCI qui se connecte au service hérite implicitement des attributs du service définis au niveau de la base de données, aussi il n’est pas utile de configurer TAF du côté du client dans le fichier tnsnames.ora

SQL> exec dbms_service.create_service(‘oltp_oci’,’oltp_oci’,NULL,NULL,TRUE,’BASIC’,’SESSION’,150,10,NULL);
exec dbms_service.create_service(‘reporting_oci’,’reporting_oci’,NULL,NULL,TRUE,’BASIC’,’SESSION’,150,10,NULL);

Configuration des services pour client JDBC

Les clients JDBC ne supportent pas TAF, aussi la configuration des services jdbc devraient être la suivante :

• Cluster de production

srvctl add service –d production –s oltp_jdbc –r instance1, instance2 –l PRIMARY –q NONE –e NONE –m BASIC –w 0 –z 0
srvctl add service –d production –s reporting_jdbc –r instance1, instance2 –l PHYSICAL_STANDBY –q NONE –e NONE –m BASIC –w 0 –z 0

• Cluster de secours

srvctl add service –d secours –s oltp_jdbc –r instance1, instance2 –l PRIMARY –q NONE –e NONE –m BASIC –w 0 –z 0
srvctl add service –d secours –s reporting_jdbc –r instance1, instance2 –l PHYSICAL_STANDBY –q NONE –e NONE –m BASIC –w 0 –z 0

• Au niveau de la base de production (Primary) les services doivent être déclarés pour qu’ils soient propagés et appliqués sur la base de secours (Standby)

SQL> exec dbms_service.create_service(‘oltp_jdbc’,’oltp_jdbc’,NULL,NULL,FALSE,’NONE’,’NONE’,0,0,NULL);
exec dbms_service.create_service(‘olpt_jdbc’,’reporting_oci’,NULL,NULL,FALSE,’NONE’,’NONE’,0,0,NULL);

Configuration de la bascule pour les clients OCI et JDBC sans FAN

Dans cette section nous nous concentrerons uniquement sur la bascule automatique des clients qui ne supportent pas Fast Application Notification (FAN).

Bascule automatique pour les clients OCI

Pour une meilleure exécution l’alias réseau d’Oracle Net devrait initialiser l’option LOAD_BALANCE=OFF au niveau DESCRIPTION_LIST ainsi avec cette configuration les tentatives de connexion sur la deuxième DESCRIPTION ne seront effectives que si toutes les tentatives de connexion sur la première DESCRIPTION ont échoué.

• Les clients OCI 11gR2 peuvent directement faire référence à l’alias réseau du SCAN introduit avec cette nouvelle version.

oltp_oci =
(DESCRIPTION_LIST=
   (LOAD_BALANCE=OFF)
   (FAILOVER=ON)
   (DESCRIPTION=
       (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
       (ADDRESS_LIST=
          (LOAD_BALANCE=ON)
          (ADDRESS=(PROTOCOL=TCP)(HOST=production-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=oltp_oci)))
   (DESCRIPTION=
       (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
       (ADDRESS_LIST=
          (LOAD_BALANCE=ON)
          (ADDRESS=(PROTOCOL=TCP)(HOST=secours-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=oltp_oci))))

Le SCAN est constituée de 3 adresses IP si la connexion essayée à l’adresse IP ne répond pas dans les 3 secondes TRANSPORT_CONNECT_TIMEOUT l’adresse IP suivante sera alors tentée. Toutes les 3 adresses IP seront essayées pour un total de quatre fois (la tentative initiale plus RETRY_COUNT dans cet exemple). Si la tentative de connexion est infructueuse sur le site de production la connexion sera alors basculée sur le site de secours avec le même mécanisme d’exécution de la connexion.

• Alors que les clients OCI dont la version est antérieure à la 11gR2  doivent faire référence à l’alias réseau de la VIP ou l’adresse IP du SCAN.

oltp_oci =
(DESCRIPTION_LIST=
   (LOAD_BALANCE=OFF)
   (FAILOVER=ON)
   (DESCRIPTION=
       (ADDRESS_LIST=
          (LOAD_BALANCE=ON)
          (ADDRESS=(PROTOCOL=TCP)(HOST=production-vip1)(PORT=1521))
          (ADDRESS=(PROTOCOL=TCP)(HOST=production-vip2)(PORT=1521)))
          (CONNECT_DATA=(SERVICE_NAME=oltp_oci)))
   (DESCRIPTION=
       (ADDRESS_LIST=
          (LOAD_BALANCE=ON)
          (ADDRESS=(PROTOCOL=TCP)(HOST=secours-vip1)(PORT=1521))
          (ADDRESS=(PROTOCOL=TCP)(HOST=secours-vip2)(PORT=1521)))
          (CONNECT_DATA=(SERVICE_NAME=oltp_oci))))

Du coté du client il est recommandé d’initialiser dans le fichier ‘sqlnet.ora ‘ le paramètre SQLNET.OUTBOUND_CONNECT_TIMEOUT, ce paramètre permet de réduire la durée de tentative de connexion à chacun des serveurs indisponibles qui sont définis dans ADDRESS_LIST. Une valeur à 3 secondes pour ce paramètre convient dans la plupart des environnements.

Bascule automatique pour les clients JDBC

Comme nous l’avons dit précédemment les clients JDBC ne supportent pas TAF, aussi la logique de reconnexion doit être prise en compte par l’application pour répondre convenablement en cas de défaillance. Par exemple, quand une session du pool de connexion reçoit une exception qui engendre une déconnexion (comme une erreur ORA-3113), l’application devrait automatiquement essayer de reconnecter cette session. Les tentatives de reconnexion devraient être configurées pour qu’elles puissent durer aussi longtemps que la bascule des services est effective.

• Client JDBC 11gR2

String dbURL =
   "jdbc:oracle:thin:@" +
   "(DESCRIPTION_LIST=" +
   “(LOAD_BALANCE=off)” +
   "(FAILOVER=on)" +
   "(DESCRIPTION=" +
     "(ADDRESS_LIST=" +
       "(LOAD_BALANCE=on)" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=production-scan)(PORT=1521)))" +
     "(CONNECT_DATA=(SERVICE_NAME=oltp-jdbc)))" +
   "(DESCRIPTION=" +
     "(ADDRESS_LIST=" +
       "(LOAD_BALANCE=on)" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=secours-scan)(PORT=1521)))" +
     "(CONNECT_DATA=(SERVICE_NAME=oltp-jdbc))))";

•  Client JDBC antérieur à la version 11gR2

String dbURL =
  "jdbc:oracle:thin:@" +
  "(DESCRIPTION_LIST=" +
   “(LOAD_BALANCE=off)” +
   "(FAILOVER=on)" +
   "(DESCRIPTION=" +
     "(ADDRESS_LIST=" +
       "(LOAD_BALANCE=on)" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=production-vip1)(PORT=1521))" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=production-vip2)(PORT=1521)))" +
     "(CONNECT_DATA=(SERVICE_NAME=oltp-jdbc)))" +
   "(DESCRIPTION=" +
     "(ADDRESS_LIST=" +
       "(LOAD_BALANCE=on)" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=secours-vip1)(PORT=1521))" +
       "(ADDRESS=(PROTOCOL=TCP)(HOST=secours-vip2)(PORT=1521)))" +
     "(CONNECT_DATA=(SERVICE_NAME=oltp-jdbc))))";

Dans un prochain article nous verrons comment configurer les clients Oracle avec FAN