How to : Oracle ASM – Ajout d’un disque SAN à un diskgroup sur Windows

Comme premier article de l'année, je me suis lancé dans un petit tuto pour montrer au mieux comment ajouter un nouvel espace de stockage SAN à un diskgroup ASM sur un environnement RAC 11G windows (à partir de 2008). Rien de bien complexe, mais cela reste des opérations courantes qui méritent d'avoir leur petit tuto ;-)

Pour ce qui est du contexte technique, j'ai donc un cluster Oracle (sur machines physique) à deux noeuds, en 11.2.0.3 (Grid + RDBMS), sur un windows 2008R2.

L'objectif est d'ajouter un espace de stockage SAN de 250Go à mon diskgroup "DATA" utilisé par ASM, sans provoquer d'incident ou d'indisponibilité.

Attention :

Il faut s'assurer que le zoning soit bien réalisé depuis le SAN sur les 2 noeuds, sans accès EXCLUSIF, si si cela peu arriver ...

=> Pour la petite note, l'accès "exclusif" se caractérise par le fait de réaliser des opérations sur un nouveau disque depuis un nœud du RAC, qui ne seraient pas propagées sur le ou les autres nœuds.

Tout d'abord, dès que l'espace SAN a été mappé sur les 2 serveurs, il faut s'assurer de la visibilité du disque depuis l'utilitaire DISKPART.

L'utilisation de cet utilitaire est préconisé par Oracle pour gérer les disques qui seront affectés à ASM, il faut en effet éviter d'utiliser le GUI "diskmgmt.msc" pour éviter des problèmes de FREEZE (que j'ai d'ailleurs rencontré quelques fois), qui feraient que le simple ajout -d'un disque devient une opération complexe pour ne pas dire d'autres mots.

On lance donc DISKPART depuis une commande dos sur l'un des noeuds du RAC, et on affiche l'ensemble des disques identifiés par le System pour ensuite s'occuper du nouvel espace ajouté.

Nota : il se peut que le nouveau disque ne soit pas visible sur les noeuds du cluster. Pas de panique, un RESCAN permet de rafraîchir le gestionnaire de disques Windows

Dans cette liste, on visualise 2 disques Offline qui sont à ajouter. Nous allons ajouter le disque 5 de 250Go à notre groupe de disque ASM "DATA".

-> Toujours à travers DISKPART, on sélectionne le disque et débutons la création de 2 partitions en passant tout d'abord le disque ONLINE (la mise ONLINE du disque doit être réalisé sur l'ensemble des noeuds du RAC).

Note : Pour les stockages windows ASM, il faut avoir un disque ayant une partition ETENDUE puis LOGIQUE (soit à la taille globale du disque, ou non)

On créée la partition ETENDUE :

Ah ... dommage . Le volume est en READ ONLY il est donc impossible de créer quoique ce soit dessus.

L'origine de ce problème est connu de Microsoft (KB), et fait référence à de nouvelles stratégies de groupes windows relatif à la gestion des disques SAN. En 2008 et 2008R2 les stratégies de groupes SAN attribuent le mode READ ONLY à tout nouveaux disques partagés SAN (mode VDS_SP_OFFLINE_SHARED) , alors que dans les versions plus récentes, le mode READ WRITE (VDS_SP_ONLINE) est le mode par défaut.

Les différentes stratégie de groupes SAN :  

VDS_SP_ONLINE: All newly discovered disks are brought online and made read-write. 
VDS_SP_OFFLINE_SHARED: All newly discovered disks that do not reside on a shared bus are brought online and made read-write. 
VDS_SP_OFFLINE: All newly discovered disks remain offline and read-only.

Le contournement proposé est donc de modifier les attributs du disque, pour le forcer à être en READ WRITE via la commande "ATTRIBUTE DISK CLEAR READONLY"

Qu'à cela ne tienne, passons le disque 5 en READ WRITE , et continuons la création de nos partitions.

=> Ceci est à faire sur l'ensemble des noeuds du cluster RAC.

Pour la création des deux partitions, il faut suivre les commandes ci dessous sauf pour la partition logique, dans le cas où une limite d'espace disque est à fixer (ce qui n'est pas mon cas)

Création de la partition étendue :

CREATE PARTITITON EXTENDED

Création de la partition logique en utilisant tout l'espace disque de la partition étendue :

CREATE PARTITION LOGICAL 

Ou si une taille doit être spécifiée (exemple pour 10Go, la SIZE étant spécifiée en MB)

CREATE PARTITION LOGICAL SIZE=10000

Ce qui donne pour moi :

=> Après cette étape il faut s'assurer que les partitions soient BIEN VISIBLES des autres noeuds du cluster. Dans mon cas je vérifie sur mon second node toujours via DiskPart, après avoir fait en revanche un petit RESCAN pour rafraichir le gestionnaire de disque.

Histoire d'être sur (car normalement depuis windows 2008 c'est par défaut), on lance une commande "AUTOMOUNT ENABLE" pour être sur que le disque sera monté au prochain reboot.

Maintenant que cette étape est faite, il faut vérifier un point certes peu impactant mais qui peut être gênant pour oracle,  windows et les applications :

A chaque découvertes de nouvelles partitions, Windows attribue AUTOMATIQUEMENT une nouvelle lettre de lecteur, que ce soit pour une partition étendue ou standard. Il faut donc veiller à RETIRER la LETTRE qui a du être automatiquement ajoutée sur le second noeud (en effet, le nœud d'où a été créée la partition n'a quand à lui pas cette lettre d'automatiquement associée)

Après avoir cliqué droit sur la partition, puis sélectionné "Change drive letter and path" :

=> on remove !

On dit YES bien sur ..

Hop, plus de lettre, c'est tout bon, je peux maintenant passer à la partie Oracle, et plus particulièrement ASM, pour agrandir mon DISKGROUP existant avec cette nouvelle partition LOGIQUE précédemment créée.

La première action est, sous windows (et oui pas besoin sous Unix) est de labelliser cette partition, pour être ensuite CANDIDATE sous ASM.

Pour cela, il faut lancer l'utilitaire ASMTOOL (disponible dans le répertoire d'installation du GRID CONTROL) soit en mode graphique ou en ligne de commande. Etant sous windows je ne vais pas me compliquer la vie, j'utilise ASMTOOLG :

On continue (NEXT) et on arrive sur la liste des partitions visibles par le system, et celles qui sont candidates à être formatées ASM :

La partition 1 du Disk5, qui est CANDIDATE, est bien celle qui a été précédemment créée.

Je garde le même PREFIX pour le nom ASM "DATA" puisque je vais procéder à une augmentation du diskgroup de ce même nom. Ceci étant j'aurais pu mettre "DATA2" ou "BATMAN", cela n'aurait pas empêché l'opération d'agrandissement, il s'agit plus de normes et conventions, autant les respecter alors ;-)

Je sélectionne donc ma partition 1 du disk5, et lance la "labellisation" du disk en format ASM :

Je peux enfin passer sous ASM pour agrandir mon diskgroup ! 

Mais faisons au préalable un petit état des lieux, pour avoir un état avant et après, et également identifier le disque ASM qui sera à ajouter.

J'ai donc bien d'identifié par ASM mon disque en statut PROVISIONED et non utilisé, qui peut être ajouté au diskgroup DATA, auquel cas je lance ma commande :

Tout juste une fois cette commande lancée, nous pouvons interroger les opérations de REBALANCE en cours sur le diskgroup DATA :

Qu'est ce le REBALANCE ?

->  A chaque ajout de disque (un ou plusieurs) au sein d'un même diskgroup, il y a des opérations de redistribution des données qui sont automatiquement réalisées par ASM, l'objectif étant que les données soient réparties au mieux à travers tous les disques qui composent le diskgroup.

Les opérations de REBALANCE se découpent en 3 phases :

1. Analyse des données à répartir : "PLANNING"
2. Ré-allocation des EXTENTS des fichiers de données : "File extents relocation"
3. Compactage : "Disk compacting"

Par défaut, le niveau de REBALANCE est fixé à 1 via le paramètre ASM_POWER_LIMIT

Ce qui signifie que les opérations ne vont pas "trop" solliciter les ressources machines / SAN (CPU / IO) pour ne pas impacter les performances (dans le cas où par exemple cette opération serait lancée en pleine journée).

Mais l'impact de laisser tel quel ce paramètre à sa valeur par défaut peut être majeur, puisque autant sur une base de 100G, répartir la données sur l'ensemble des disques va prendre un temps probablement acceptable, dans lequel peu de risques peuvent survenir, autant sur une base de quelques To, cela ne va pas être la même limonade...

Si l'opération met plusieurs heures à se réaliser, les facteurs risquent augmentent (risques de pannes disques, machines, coupure lien SAN, reboot et j'en passe) ce qui peut provoquer un doux bazar au sein des données ASM.

Il est donc important de vérifier le temps que va mettre ASM à effectuer ses opérations de réorganisation, pour adapter au mieux et éviter ainsi un certain nombres de risques.

La gestion de la REBALANCE est dynamique, nous pouvons augmenter ou diminuer ASM_POWER_LIMIT, via une commande du type "alter diskgroup MYDISK rebalance power 3;", voyons donc ce que cela donne pour moi :

On voit que le temps estimé ne descend pas, c'est plutôt le contraire (et c'est normal car c'est la première phase de "Planning"). Nous allons donc passer au niveau rebalance 4 :

Tout de suite, en montant le niveau de rebalance à 4, on divise par deux le temps nécessaire à la réorganisation des données.

Nous avons donc maintenant notre diskgroup DATA pleinement opérationnel avec ces 250 nouveaux Go !

Enjoy !

Micka