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-*