Migrer un système d’exploitation et ses bases de données est toujours un peu stressant. Quand en plus, il faut garantir la disponibilité du service pour 9000 utilisateurs, ça rajoute du piquant. Mais par-dessus tout, s’il s’agit des dossiers patients d’un hôpital, vous devez être parfaitement préparé. Décortiquons ce projet réalisé pour le CHU de Bordeaux.
Migrer d’AIX vers Linux pour profiter d’un cluster actif/actif
Le Centre Hospitalier Universitaire de Bordeaux utilise depuis toujours des bases Oracle sur le système d’exploitation AIX d’IBM. Leur volumétrie est très conséquente. Le logiciel principal utilisé est Dxcare de la société Dédalus. Il sert à gérer le dossier patient informatisé (ou Dossier Médical Partagé), dont les données sont stockées sur une base Oracle. Cette base de données principale occupe actuellement plus de 19 terra-octets. Un grand nombre d’autres bases de données Oracle sont aussi utilisées pour des applications annexes.
Le CHU de Bordeaux désirait se désengager du système d’exploitation AIX et de sa gestion du cluster en mode actif/passif (par le biais de Veritas Cluster Manager) afin de basculer sur le système d’exploitation Oracle Linux en mode cluster mais en actif/actif.
Migrer un système d’informations et des données sensibles présente différents enjeux et complexités. Il fallait en outre :
- Minimiser au maximum les temps d’interruptions de service ;
- Garantir le retour des accès aux applications aux 9000 utilisateurs potentiels du CHU ;
- Assurer une stabilité de l’application dans ce passage actif/passif vers actif/actif ;
- Faire monter en compétence l’équipe des DBAs du CHU de Bordeaux afin de garantir l’exploitation de la solution.
5 phases clés pour préparer la migration
Ce projet, qui a duré plus de deux ans, a été effectué en plusieurs phases :
- Définir la nouvelle infrastructure en fonction des consommations actuelles sur les serveurs AIX afin que le CHU puisse acquérir des serveurs Linux/Intel suffisamment calibrés en termes de nombre de cœurs de CPU et de mémoire
- Installer et configurer un nouveau cluster de test et formation, et effectuer des transferts de compétences avec l’équipe DBA
- Faire des premiers tests de migration en basculant les bases de test sur ce cluster et valider l’exploitabilité de la solution, notamment avec les outils de supervision utilisés par le CHU
- Installer et configurer les nouveaux clusters de production
- Migrer les bases de production
Oracle 19c au cœur du projet
Bien sûr, l’aspect technologique d’un tel projet de migration est essentiel. Dans ce cas, les bases de données tournaient principalement sur Oracle Database 19c.
Les nouveaux serveurs en cluster Oracle Linux ont été installés en utilisant le logiciel Grid Infrastructure en version 19C qui permet de gérer la couche cluster et le stockage partagé sous ASM (Automatic Storage Management).
Les moteurs bases de données (RDBMS) ont été installés en version 12CR1 et 19C.
Certaines bases de données Oracle Database, les moins volumineuses et critiques, ont été migrées en version 19C par le biais d’export et d’import. Bien évidemment les progiciels utilisant ces bases ont été validés par les éditeurs en version 19C.
La base la plus critique utilisée pour le dossier patient informatisé ne pouvait pas être migrée par export/import. En effet, il aurait fallu plus de 24h d’export et plus de 48h d’import… Le choix s’est donc porté sur la possibilité de convertir les fichiers de la base de données d’origine en utilisant RMAN (Oracle Recovery Manager) et les sauvegardes de la base source AIX. En effet, la même version Oracle (12.1.0.2) doit être utilisée sur les deux environnements.
Pourquoi cette conversion ? Les données sous AIX utilisent des caractères en mode Big Endian alors que Linux lui utilise le mode Little Endian. Rman est donc capable d’effectuer cette conversion (changement dans l’ordre des octets, poids fort/poids faible).
Les étapes clés pour effectuer la migration
Le support Oracle est très fourni et propose la note 2471245.1 qui détaille les différentes étapes à effectuer lors d’une migration de type Transportable Tablespace/Database. La note met notamment à disposition un script shell permettant de faciliter les actions à mener :
- Restauration avec conversion des fichiers de la base de données en utilisant les sauvegardes en mode Transportable Tablespace. Cette étape a été effectuée deux semaines avant la date de migration ;
- Application des sauvegardes incrémentales converties de la base AIX sur la base Linux. Cette étape a été renouvelée plusieurs fois avant la date de migration. Le but étant de minimiser les écarts entre les deux bases afin de minimiser le temps d’interruption final ;
- Le jour J de la migration, les étapes suivantes ont été réalisées en se relayant avec l’équipe des DBA du CHU de Bordeaux :
- A 1h du matin l’ensemble des applications utilisant la base de données ont été arrêtées ;
- A 1h20 du matin, la base de secours gérée par Dataguard est passée en mode « cliché », les droits applicatifs sont modifiés en Lecture Seule. Dxcare est accessible en lecture aux utilisateurs pendant la coupure ;
- A 2h du matin, la dernière sauvegarde incrémentale a été effectuée. Les tablespaces de la base source AIX ont été placés en mode lecture seule. Un export des métadonnées a été effectué ;
- A 2h10 du matin, la dernière sauvegarde a été appliquée sur la base Linux, et les métadonnées ont été importées ;
- A 2h30 l’export des tablespaces à transporter est fini ;
- A 3h05 l’import des transportables tablespaces est fini ;
- A 4h15 du matin, l’ensemble des objets procéduraux et autres objets non transportés (fonction, procédure, package, travaux, db_links, public synonym, tables temporaires, ACL, droits des users…) ont été recréés ;
- A 5h du matin, l’ensemble des actions ont été terminées avec succès ( passage tablespaces en Lecture Ecriture, passage de la base en mode archivage, mise en place des sauvegardes, modification alias SQLNet dans le LDAP, récupération des profiles et des Baselines SQL, paramétrage serveurs applicatifs et redémarrage) ;
- A 5h du matin, les tests fonctionnels ont été réalisés par les chefs de projet des différentes applications ;
- A 6h15 du matin, l’accès complet aux utilisateurs a été ouvert ;
- A 7h, début de la création de la base de secours et disponibilité de celle-ci à 14h pour les accès en mode lecture seule pour les analystes (infocentre).
Grâce à une préparation minutieuse en collaboration avec les DBA du CHU, le temps d’indisponibilité a été réduit à 6h (entre 1h et 7h du matin).
Après la migration, s’assurer que tout fonctionne
Un suivi des performances et de comportement a eu lieu avec l’aide de Digora pendant les 3 jours suivants. Aucun dysfonctionnement n’a été détecté, le ressenti des utilisateurs a été très bon, l’application se comportant bien mieux sur cette nouvelle infrastructure que sur les anciens serveur AIX.
Ce projet est donc une réussite pour le CHU de Bordeaux qui possède dorénavant une infrastructure très évolutive et robuste pour faire tourner son Dossier Patient Informatisé et les différentes données sensibles qu’il renferme.
Nous remercions le CHU de Bordeaux pour leur accord de principe sur la diffusion de cet article, et notamment M. Olivier Jecker, Responsable Département d'Ingénierie technique et production du CHU de Bordeaux.
Source image : Illustration de Owen Beard sur Unsplash
