Migration vers Oracle 12c : pourquoi le CERN y est allé

Présent lors de l’annonce en France d’Oracle 12c (Lire 12c : Oracle soigne la productivité de ses DBA), la dernière version de la base de données du troisième éditeur mondial, Eric Grancher, architecte base de données au sein du CERN, a détaillé les raisons qui ont poussé le laboratoire européen pour la recherche sur les particules à s’intéresser très tôt à cette mouture.

Client de la base Oracle depuis 1982, à l’origine pour gérer l’accélérateur, le centre de recherche, qui emploie 2 400 personnes majoritairement en Suisse où sont situées ses installations principales – notamment l’accélérateur de particules LHC –, fait en effet partie des premiers utilisateurs à avoir adopté 12c. Une migration dictée par la volonté de relever trois challenges principaux, selon Eric Grancher (en photo).

« Le premier d’entre eux réside dans la continuité de fonctionnement des applications, explique-t-il. Si une base de données rencontre une erreur, il est très difficile d’avoir une application qui réagisse positivement. » Pour le CERN, cette incapacité à assurer la finalisation d’une transaction a des conséquences opérationnelles très lourdes : en cas d’erreur sur l’application de gestion des accélérateurs, le laboratoire se voit contraint de détourner les faisceaux de protons, perdant ainsi des fonds et du temps.

« Dans 12c, la fonction Transaction Guard permet à une application de demander un numéro pour chaque transaction et d’obtenir un état sur ces transactions. De son côté, Application Continuity permet de rejouer les opérations ayant échoué », détaille Eric Grancher. Des fonctions qui ont évidemment un impact sur les performances, mais un impact faible selon l’architecte, qui cite des tests effectués sur l’application de collecte de données issues de l’accélérateur de particules. Une application engrangeant 150 Go et 4 milliards d’entrées par jour.

Réplications synchrones malgré la distance

Seconde motivation du CERN : améliorer ses performances en matière de haute disponibilité, avec l’appui de son site distant situé à Budapest. « Nous souhaitions faire fonctionner cette architecture en mode synchrone, sans risque de perte de données, explique Eric Grancher. Mais étant donné la distance et les performances des réseaux, c’était jusqu’à présent impossible. »

Dans 12c, l’option Far Sync permet de répondre à cette attente, en positionnant ce qu’Eric Grancher qualifie de « répéteur » à proximité de la base primaire (en réalité une instance légère de la base fournissant un accusé de réception dès l’arrivée en mémoire des données et prenant en charge l’écriture sur la base secondaire). « Nous obtenons les mêmes performances qu’avec une synchronisation locale », assure l’architecte.

La troisième raison qui a poussé le CERN à faire partie des premiers utilisateurs de 12c ? Le concept d’instances de base de données connectables à chaud sur des containers, l’argument numéro un de cette version selon Oracle. « Sans ce concept, les bases de données mélangent l’administration et la logique applicative. Ce qui lie les futures opérations », remarque Eric Grancher.

Pour le CERN, la nouvelle architecture multitenant de 12c offre au moins quatre opportunités : pousser plus loin les opérations de consolidation, proposer aux utilisateurs des database-as-a-service (des instances prêtes à l’emploi en quelques clics), faciliter les tests de non-régression (en utilisant la fonction « capture and replay » pour vérifier le bon fonctionnement d’une application après mise à jour de l’environnement) et déplacer facilement les applications.

Voir aussi

Quiz Silicon.fr – La saga Oracle