webleads-tracker

Journal / Blog

Vous êtes ici

Migrer une base Oracle RAC vers un MétroCLuster NETAPP sans arrêt de production (ou presque)

0 Commentaires

Remplacer une baie SAN existante par un MétroCluster NETAPP sans arrêt de Production (ou presque) : voilà le défi qu'a relevé DIGORA pour un de ses clients du secteur hospitalier, qui utilise une base Oracle RAC hautement stratégique. Comment notre consultant expert s'y est-il pris  ?

1. Le contexte

Notre client utilise un cluster Oracle RAC 11g avec le progiciel de Gestion du Dossier Patient ACTIPIDOS. La baie de stockage actuellement utilisée par ce cluster doit être remplacée par  une nouvelle infrastructure de stockage de type MétroCluster NETAPP. Au passage, l'un des deux serveurs Oracle RAC sera déplacé dans une deuxième Salle Informatique. L'objectif est d'effectuer la mise en oeuvre en perturbant le moins possible les utilisateurs.

2. Les scénarios envisagés

Dans le cadre de la pré-étude menée par DIGORA, deux scénarios ont été identifiés : migration à froid et migration à chaud. Dans les deux cas, il sera nécessaire de patcher les serveurs Windows au passage.

Scénario 1 : Migration à froid

Le Centre Hospitalier dispose d’un serveur de secours, qui peut être utilisé momentanément pour faire fonctionner la base de Production. Puis, l'ensemble des tâches liées à la migration vers la nouvelle configuration de stockage peut être exécutée. Une fois le nouveau cluster Oracle RAC prêt, la base de Production pourra à nouveau être déplacée sur celui-ci. Avantage : cela permet d'effectuer la migration de l'infrastructure de stockage plus confortablement. Inconvénient : cette méthode nécessite deux interruptions de la production et la mise en oeuvre de bases StandBy pour diminuer la durée des deux interventions.

Scénario 2 : Migration à chaud

Cette solution consiste à connecter au Cluster existant la nouvelle infrastructure de stockage NETAPP tout en laissant connectée l'ancienne baie SAN et à y copier à chaud les volumes utilisés par Oracle. Toute l'élégance de la méthode consiste à utiliser une fonctionnalité d'Oracle ASM (le système de fichier Clusterisé d'Oracle RAC) qui permet d'ajouter aux DiskGroups ASM les nouveaux LUNs créés sur la nouvelle baie, d'y copier les fichiers Database puis de supprimer des DiskGroups ASM les LUNs existants précédemment sur l'ancienne baie. Avantage : la production n'est arrêtée à aucun moment : le reboot des serveurs Windows peut s'effectuer en alternance. Inconvénient : la manipulation est plus délicate et nécessitera un scénario extrêmement détaillé et précis.

 3. La mise en oeuvre

C'est bien sûr la solution 2 qui a été choisie et mise en oeuvre, en collaboration avec l'intégrateur gérant les baies de stockage. Voici quelques schémas :

Voici le détail des opérations effectuées :

Système Windows :

  • mise en oeuvre de patchs Windows, avec reboot des serveurs en alternance; au passage, déménagement d'un des deux serveurs dans la Salle 2

SAN :

  • Connexion aux serveurs des baies NETAPP en MétroCLuster tout en gardant la connexion à l'ancienne baie SAN

Oracle :

  • migration à chaud de l'OCR File d'Oracle RAC 11g
  • migration à chaud du Voting Disk d'Oracle RAC 11g
  • migration à chaud des données sur les nouvelles baies SAN grâce à Oracle ASM

SAN :

  • Déconnexion de l'ancienne baie SAN

 4. Le bilan

L'opération s'est déroulée sans aucun problème et sans interruption de service. Les deux serveurs Oracle RAC associés à la base "Dossier Patient"  sont désormais répartis dans deux salles informatiques sur un Métro-Cluster NETAPP.

Commentaires (0)