Mise en oeuvre d'ASM avec UDEV sous linux

Pourquoi mettre en œuvre ASM avec Udev alors que l’on a à disposition sous linux les packages oracleasm et oracleasmlib qui sont là pour nous simplifier la vie?
L’histoire est un peu longue, mais je vais essayer de vous la résumer.
Tout commence par l’installation d’un Cluster 12c sur une infrastructure Dell avec baie flash Nettapp sous Redhat 6.7. Au début, tout va bien. L’installation se déroule sans problème majeur avec les packages ASMlib. Tout se gâte lorsque commencent les tests d’exploitabilité, notamment les tests de mise à jour de firmware des contrôleurs de la baie flash. Cette opération nécessite de basculer les liens d’un contrôleur à un autre. Lors de cette opération, on perdait systématiquement le contact avec les disques ASM touchés par la bascule de contrôleur.
Après avoir vérifié la configuration multipath, fait des tests de copie OS de fichiers et autres dd lors de la bascule de contrôleur, et constaté que tout ce passait normalement, on a validé que le problème se reproduisait bien avec la version 11gR2 du clusterware.
La décision fut alors prise de se passer de la partie OracleAsm pour valider que le problème venait bien de là.
Depuis lors, plus de problème.
Les causes du choix étant éclaircis, passons maintenant à la mise en œuvre d’ASM avec Udev.
Le cluster est constitué de lames Dell POWEREDGE M630, le stockage se fait sur une baie flash Nettapp OnTap, l’OS est de la Rehat Enterprise 6.7.
Nous partirons du principe que dans la configuration multipath, les alias liés aux volumes ASM seront préfixés par asm.
De plus, pour faciliter la gestion des alias, ceux-ci seront stockés dans un fichier /etc/multipath/conf.d/aliases.conf.
De ce fait, le fichier multipath.conf ressemblera a celui-ci :
 

defaults {
config_dir /etc/multipath/conf.d
user_friendly_names no
max_fds max
queue_without_daemon no
flush_on_last_del yes
dev_loss_tmo infinity
fast_io_fail_tmo 5
}
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
}
devices {
device {
vendor "NETAPP"
product "LUN"
path_grouping_policy group_by_prio
features "4 queue_if_no_path pg_init_retries 50 retain_attached_hw_handler"
prio "alua"
path_checker tur
path_selector "round-robin 0"
failback immediate
hardware_handler "1 alua"
rr_weight uniform
rr_min_io_rq 1
retain_attached_hw_handler yes
getuid_callout "/lib/udev/scsi_id -g -u -d /dev/%n"
}
}

Dans un premier temps, assurez vous que les luns ont bien été présentées à l’ensemble des serveurs à l’aide de la commande sanlun lun show
L’option –p permet de récupérer toutes les informations concernant le mutipathing des luns présentées.
Le résultat de la commande étant verbeux, on va réduire le retour de la commande aux informations dont on a besoin. C’est à dire que l’on ne va garder que les luns qui n’ont pas encore de device créée sur le serveur, dont la ligne ligne Host Device: est différente de :

Host Device: asmXXXX
sanlun lun show -p|egrep "ONTAP Path|Host"|awk '{if ($0 ~ /ONTAP Path/) printf "%s",$3; else printf " %s\n",$3}'

on obtient un résultat du type

XXXXXX:/vol/YYYYYY/DATA1 3600a098038303733732b486639787678

On considèrera que DATA1 sera l’alias multipath une fois préfixé par asm.
Le seconde partie de la ligne étant le wwid du volume.
On vérifie qu’il n’existe pas déjà une partition sur ce volume à l’aide de la commande partprobe

partprobe /dev/mapper/3600a098038303733732b486639787678

si elle n’existe pas, on la crée, ici avec la commande parted

parted /dev/mapper/${wwid} mklabel msdos
parted /dev/mapper3600a098038303733732b486639787678mkpart primary ext4 1 -- -1s

On vérifie qu’il n’existe pas déjà un alias du même nom dans le fichier /etc/multipath/conf.d/aliases.conf

grep DATA1 /etc/multipath/conf.d/aliases.conf

Si l’alias n’existe pas, on peut l’ajouter dans le fichier /etc/multipath/conf.d/aliases.conf.

vi /etc/multipath/conf.d/aliases.conf
multipaths {
multipath {
wwid       3600a098038303733732b486639787678
alias     asmDATA1
}

Puis on recharge la configuration multipath

service multipathd reload

Passons maintenant à la configuration UDEV. Celle-ci se fait à travers un fichier /etc/udev/rules.d/99-oracleasm.rules
Vérifions qu’il n’existe pas déjà une règle pour notre alias.

grep asmDATA1 /etc/udev/rules.d/99-oracleasm.rules

Si l’alias n’est pas défini, on peut l’ajouter au fichier de config

vi /etc/udev/rules.d/99-oracleasm.rules
ENV{DM_NAME}=="asmDATA1p1",NAME="asm-DATA1", OWNER="grid", GROUP="asmadmin", MODE="0660"

On recharge la configuration udev

/sbin/udevadm control --reload-rules
/sbin/udevadm trigger --type=devices --action=change

Voilà, votre disque est maintenant prêt a être inséré dans un volume ASM à l’aide d’asmca.
Assurez-vous avant tout que le chemin de découverte des disques est bien /dev/asm-*
 

Laisser un commentaire

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