Certes pas encore tout à fait mais le mouvement est enclenché …
Pas de faire-part
En effet, de manière très (trop ?) discrète Oracle a précisé que la fonctionnalité RAC (Real Application Clusters) ne serait plus supportée en édition Standard Edition 2 à partir de la version 19c.
Pas de communication officielle, nous l’avons appris au détour d’une recherche sur le site du support Oracle : Desupport of Oracle Real Application Clusters (RAC) with Oracle Database Standard Edition 19c (Doc ID 2504078.1)
Pour rappel cette possibilité était apparue en 2005 avec la version 10GR2 de la base de données et s’il elle s’accompagnait de quelques contraintes techniques (2 noeuds maximum, utilisation d’ ASM pour le stockage notamment), elle permettait de mettre en place une configuration haute-disponibilité à un coût intéressant. En effet cette solution permettait d’optimiser à la fois le RPO (Recovery Point Objective – perte de données tolérable) et le RTO (Recovery Time Objective – temps d’interruption maximum) des bases de données Oracle.
De fait, en tant que spécialistes de ces environnements nous avons souvent recommandé cette configuration et l’avons déployé à de multiples reprises en versions 10GR2 puis 11GR2, à la grande satisfaction de nos clients.
Des signes avant-coureurs
L’apparition de la licence SE2 en 2014 avec la version 12.1.0.2 a porté un premier coup à l’intérêt de cette configuration, limitant le nombre de threads de CPU utilisables simultanément sur une base (8 threads par instance). Pour des environnements peu gourmands en CPU cela restait néanmoins un compromis acceptable.
Là, c’est différent : la 19c étant la version finale de la 12.2 (oui je sais ça fait bizarre, mais vous pouvez consulter la note suivante si vous ne me croyez pas : Release Schedule of Current Database Releases (Doc ID 742060.1)), l’intérêt pour un client SE ou SE2 avec une base RAC 11gR2 ou 12cR1 de migrer est à étudier :
- Le support ‘Premier’ de la 12.2.0.1 se termine en Novembre 2020
- Le support ‘Premier’ de la 18c (12.2.0.2) se terminera normalement avant fin 2021
- La version 19c (12.2.0.3, vous suivez toujours ?) bénéficiera du support étendu jusqu’en Mars 2026, mais on ne peut plus utiliser RAC …
Si vous êtes concernés
Disons que tout va dépendre de la criticité de vos environnements et de votre degré de confiance vis à vis d’Oracle, vous pouvez :
- Changer de mode de licensing Oracle et passer en édition Enterprise de la base de données + option RAC payante : au vu de la différence de coût et de mode de calcul entre Standard Edition 2 et Enterprise vous ferez le bonheur de votre commercial Oracle (ps : passez par nous pour les licences, on vous fera un prix 🙂 )
- Garder la configuration cluster et ASM (a priori rien dans la note citée plus haut n’interdit de les utiliser en version 19c) et mettre en place des bases en mode actif / passif. Cela nécessite un peu de développement (pour les scripts de gestion des ressources) et de tests mais c’est tout à fait gérable et fonctionnel (nous l’avons déjà implémenté pour plusieurs clients). Le RPO reste le même que pour une configuration RAC, le RTO est lui un peu dégradé. Le problème ici n’est pas tellement technique mais que personne ne peut vous garantir que ces fonctionnalités (cluster, ASM) pourront encore être utilisées en SE2 après la 19c, l’historique d’Oracle ne plaidant pas pour l’optimisme béat.
- Changer de méthode de sécurisation de vos bases de données en utilisant des bases de standby et en particulier l’outil additionnel Dbvisit, adapté aux bases SE2 . Le RPO est un peu moins bon (2 à 5 minutes en cas de sinistre majeur), le RTO est clairement dégradé puisque la bascule entre les environnements doit être déclenchée par un administrateur.
- Migrer vos bases de données Oracle vers votre cluster Vwmare pour profiter de toutes les possibilités de sécurisation de celui-ci. Attention aux sensations fortes si jamais vous vous faites auditer ! (un conseil si vous êtes dans ce cas : contactez-nous rapidement). Néanmoins, suivant vos accords avec Oracle cela peut constituer une solution envisageable.
- Migrer vers le Cloud, enfin un de ceux qui sont supportés par Oracle : Amazon, Azure ou Oracle. Là on change de dimension et on n’est souvent plus dans un projet d’infrastructure Oracle mais plus dans un projet d’entreprise (il y a énormément d’implications et d’imbrications à migrer la base de données d’une application de production existante vers le cloud …). Néanmoins si c’est la stratégie à long terme de votre société, c’est peut-être l’occasion de vous lancer …
Back to basics
Si vous aviez mis en place une architecture RAC c’était a priori pour de bonnes raisons : besoin de sécurisation forte des données et/ou de disponibilité élevée. Ce qui devrait guider vos choix d’architecture ce sont vos contraintes : localisation physique des données, perte de données admissible, temps de reprise, reprise automatisée ou non, stratégie de gestion de vos données…
Ce changement imposé est ainsi l’occasion de faire le point, de vérifier si les contraintes ayant justifié la mise en place d’un cluster RAC n’ont pas évolué. C’est peut-être également le moment de redéfinir une architecture de gestion de vos données correspondant à votre stratégie à long terme, avec ou sans Oracle …
Nous sommes à même, dans tous les cas, de vous accompagner sur ces projets et serions ravis d’échanger avec vous sur ces sujets. N’hésitez pas à nous contacter !