Exadata : Reconfiguration de la couche GRID 12cR1 sur EXADATA

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Dans cet article, je vais vous montrer comment dé-configurer/reconfigurer la couche Grid Infrastructure 12.1 sur Exadata.

La dé-configuration et la reconfiguration du cluster entier reconstruisent l’OCR et Voting Disks.
Les ressources utilisateurs (base de données, instance, service, listener, etc.) devront être rajoutées manuellement au cluster une fois la reconfiguration terminée.

Pourquoi la dé-configuration est-elle nécessaire ?

La dé-configuration est nécessaire lorsque :

  • L’OCR est corrompu sans aucune sauvegarde
  • On souhaite changer le séquence number des instances ASM (+ASM1, +ASM2 , etc.)
  • $GRID_HOME est intact, car la dé-configuration ne corrigera pas la corruption

Vérifier l’état des nœuds :

Avant de dé-configurer un nœud, il faut s’assurer qu’il n’est pas épinglé :

Si le nœud est épinglé, vous devriez le détacher en premier, en tant que root :

Collecter les ressources du cluster :

Avant de dé-configurer, vous devez collecter les éléments suivants en tant qu’utilisateur grid, afin de générer une liste des ressources utilisateurs à rajouter au cluster une fois la reconfiguration terminée, un exemple des éléments à récupérer :

Si ACFS (ASM Cluster File System) ou bien AFD (ASM Filter Driver) est utilisé, les données ci-dessous doivent être collectées avant de dé-configurer la couche GRID :

Arrêter du cluster GRID

Avant de dé-configurer le cluster, vous devez arrêter le cluster sur tous les nœuds :

Dé-configuration de la couche GRID

1. Si l’OCR et Voting Disks ne sont pas dans l’ASM ou si l’OCR et Voting Disks sont sur ASM et qu’il n’y a pas de données utilisateur dans l’OCR et Voting Disks :

Sur tous les nœuds distants, en tant que root :

Une fois la commande ci-dessus est terminée sur les nœuds distants, sur le nœud local, en tant que root:

2. Si l’OCR et Voting Disks sont sur ASM et qu’il existe des données utilisateur dans l’OCR et Voting Disks :

Sur tous les nœuds distants, en tant que root :

Une fois la commande ci-dessus terminée sur les nœuds distants, sur le nœud local, en tant que root :

Sur cet article, je vais traiter le deuxième cas (OCR et Voting Disks sont sur ASM et il existe des données utilisateur dans l’OCR et Voting Disks) :

Création d’un nouveau GRIDDISK

Création d’un nouveau GRIDDISK sur l’ensemble des storage cells de l’exadata :

Configuration de la couche GRID 12cR1

Le fichier Grid-racnode1.oracle.com.rsp est auto-généré au moment du déploiement de la couche GRID avec l’outil onecommand, exemple de l’emplacement du fichier « onecommand/linux-x64/WorkDir/Grid-racnode1.oracle.com.rsp »

Un exemple de l’output du fichier rsp généré (vous devez changer tous les occurrences DATA1 en DATAREC1)

Lancer le script config.sh :

Exécuter le script root.sh

Le script root.sh doit être lancé sur le premier nœud et attendre la fin de son exécution. Puis vous pouvez le démarrer sur tous les autres nœuds sauf le dernier, attendez qu’il se termine sur tous les nœuds; et enfin l’exécuter sur le dernier nœud.

Récupérer les diskgroups

Une fois l’installation est terminée, vous devez récupérer les données utilisateurs qui étaient sur les diskgroups DATA1 et RECO1.
En tant que grid :

Démarrer le diskgroup sur les nœuds distants :

Changer l’emplacement de l’OCR et VOTING DISK

OCR :

Voting disk :

Supprimer le diskgroup temporaire

Création de ressources cluster

Quelques exemples de recréation des ressources cluster.

1. Création de la ressource listener infiniband :
En tant que root :

En tant que grid :

2. Création de la ressource database :
En tant que oracle :

Objectif atteint !
Vous avez ré-configuré de nouveau la couche GRID 12cR1.
 

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Laisser un commentaire

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