0

Oracle 19c High Availabality : une solution de haute disponibilité à moindre coût.

twitterlinkedinmail

 

Hello

voici un petit article rapide sur la haute disponibilité Oracle 19c.
Comme nous le savons déjà, la solution Real Application Cluster (RAC) pour une architecture Oracle n’est plus disponible depuis la version 19c standard Edition SE2.
Et comme de nombreux clients détiennent ce type de licences bien moins couteuses que “Enterprise Edition”, cela pose un réel souci en terme de haute disponibilité.

Nous avions présenté il y’a quelques mois, la solution “DBVisit standby“. le “dataguard” proposé par un éditeur tiers pour la version Standard Edition.

Mais cette solution ne prend pas en charge la couche “Grid infrastructure”.

 

Oracle  19c High availabality

 

Oracle propose, depuis le version Oracle Database 19.7 la fonctionnalité “Oracle 19c High Availabality”. Cette solution permet de profiter des fonctionnalités de la couche “Grid infrastructure” (ASM, ACFS…) avec une version Standard Edition 2, mais cela, au détriment de certaines restrictions.

Cette architecture est disponible aussi bien sous Linux que pour Solaris ou Windows.

 

Principes

l’objectif est de garantir au client une haute disponibilité dans un budget bien moins onéreux que de migrer vers une version “Enterprise Edition”.

 

En effet, lorsqu’un client souhaite passer d’une version Oracle 12cR2 RAC Standard Edition 2, par exemple, vers la version 19c, il n’a pas d’autres choix que :

  • migrer vers une version Oracle 19c Enterprise Edition pour bénéficier de l’option RAC.
  • convertir son instance vers une Oracle Standalone et perdre les fonctionnalités “Grid Infrastructure”

Une autre solution, mais alors bien plus contraignante pour un bon nombre de clients, est de passer vers une version “autonomous database” sur le Cloud Oracle.

C’est dans ce contexte que Oracle a réfléchi a une 4e solution avec la fonctionnalité “Oracle 19c High Availabality”.

 

Les avantages

 

Cette fonctionnalité comporte un certain nombres d’avantages

  • prise en charge de la Grid infrastructure : Clusterware, disques ASM, ACFS, HAVIP et MGMTDB
  • mode actif/passif, un bascule d’instance est possible en cas de panne sur l’instance active et permet de continuer l’activité sur l’instance passive.
  • Pas de surcoût en terme de licence, si et seulement si, le démarrage de l’instance passive n’excède pas 10 jours.
  • Les agents pour Oracle Grid Infrastructure Clusterware peuvent fonctionner pour le monitoring de Oracle 19c High Availabality.

 

Les inconvénients

 

Comme cette fonctionnalité s’adapte pour des licences SE2 sans surcoût d’utilisation, nous avons clairement des limites à l’utilisation.

  • Lorsque nous effectuons un “failover” sur l’instance passive, son utilisation est limitée à 10 jours continus.
  • Seuls 2 nœuds, l’un actif, l’autre passif, sont permis.
  • De plus, cette solution est loin d’être aussi robuste qu’un RAC classique pour les raisons suivantes :
    • il n’y a pas de relocalisation automatique des ressources RAC, un DBA doit intervenir manuellement pour démarrer la passive lors d’un crash du nœud actif.
    • une relocalisation de service en ligne n’est pas possible (on pense à un srvctl relocate service -d…), il faut arrêter l’instance active afin d’intervenir.
    • pour appliquer les patchs DB et CRS, le mode “rolling upgrade” n’est pas possible.

 

Conclusion

 

Cette solution est loin de valider la robustesse d’un Real Application Cluster, puisque toute intervention requiert une action manuelle et surtout les 2 instances ne sont pas UP au même moment comme pour un RAC.

Cependant, elle a le mérite de permettre à son utilisateur de profiter de l’infrastructure Grid avec disques ASM, ACFS et Clusterware et ce avec une licence Oracle Standard Edition et sans surcoût.
De plus, ce mode de fonctionnement actif/passif avec l’infrastructure Clusterware, garantit un failover d’instance rapide.

En revanche, le SPOF (single point of failure) restera toujours, dans une architecture Oracle RAC, le stockage sur nos disques ASM locaux ou sur un SAN.
La mise en place d’un RAID avec controler associé assureront la haute disponibilité de ce coté.

 

🙂

 

Emmanuel RAMI

 

 

 

Continuez votre lecture sur le blog :

twitterlinkedinmail

Emmanuel RAMI

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.