Problématique
Lorsque l’on utilise des diskgroups ASM en environnement Linux, il faut que l’instance puisse identifier les disques qui constituent ses diskgroups de manière invariable. Pour cette raison, l’instance ne peut pas se fier au nom du device qui peut changer suite à des modifications matérielles.
Il existe plusieurs solutions pour gérer ce problème.
- ASMLib : Driver spécifique fourni par Oracle. C’est la solution préconisée mais qui offre un gros désavantage dans ses dernières versions : l’obligation de partitionner ses disques avant de pouvoir les tagger pour ASM. Cela rajoute de la complexité lors de l’extension de LUNs, ce qui rend la solution peu séduisante.
- ASMFD (ASM Filter Driver) : Nouvelle solution proposée par Oracle en version 12c, elle apporte le même service avec en complément la protection des devices au niveau de l’OS (impossibilité d’écraser les disques).
- udev : Solution standard Linux pour figer le mapping d’un device. Cette solution est très universelle et ne nécessite pas la création de partitions.
Nous allons nous intéresser ici à la solution udev, qui malgré le développement d’outils officiels par Oracle, reste très populaire pour gérer les disques ASM.
Implémentation
Voyons comment configurer udev sur un environnement Oracle Enterprise Linux 7.6.
La Grid Infrastructure est installée en version 19c, mais la méthode peut fonctionner de la même manière sur une version plus ancienne.
Trois disques ont été présentés à la machine virtuelle dans le but de constituer un diskgroup, ces derniers sont détectés comme /dev/sdb, /dev/sdc et /dev/sdd.
[root@orasrv1 ~]# ll /dev/sd* brw-rw---- 1 root disk 8, 0 19 déc. 14:54 /dev/sda brw-rw---- 1 root disk 8, 1 19 déc. 14:54 /dev/sda1 brw-rw---- 1 root disk 8, 2 19 déc. 14:54 /dev/sda2 brw-rw---- 1 oracle oinstall 8, 16 19 déc. 14:57 /dev/sdb brw-rw---- 1 oracle oinstall 8, 32 19 déc. 14:57 /dev/sdc brw-rw---- 1 oracle oinstall 8, 48 19 déc. 14:57 /dev/sdd
Pour la configuration udev, il faut se baser sur un identifiant unique pour que chaque disque soit identifié de manière fiable.
Pour ce faire, nous disposons de l’id SCSI.
Il faut commencer par prendre note des ids de chaque disque que l’on souhaite ajouter en disque ASM. On peut afficher cet id à l’aide de la commande scsi_id.
[root@orasrv1 ~]# /usr/lib/udev/scsi_id -g -u -d /dev/sdb 1ATA_VBOX_HARDDISK_VB554716ff-b7cf8ef1 [root@orasrv1 ~]# /usr/lib/udev/scsi_id -g -u -d /dev/sdc 1ATA_VBOX_HARDDISK_VB78dfaecb-a4c2453d [root@orasrv1 ~]# /usr/lib/udev/scsi_id -g -u -d /dev/sdd 1ATA_VBOX_HARDDISK_VBebc2562a-43e3cd04
Nous allons maintenant effectuer les règles udev permettant de remapper ces disques sur un chemin différent avec un nom fixe.
La règle permet également de changer les utilisateurs et groupes propriétaires des disques, ainsi que le mod 660 sur les fichiers.
Pour configurer les règles udev, créer un fichier /etc/udev/rules.d/99-asm.rules
vi /etc/udev/rules.d/99-asm.rules
Saisir les règles suivantes :
KERNEL=="sd?", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/%k", RESULT=="1ATA_VBOX_HARDDISK_VB554716ff-b7cf8ef1", SYMLINK+="asmdisks/data1", OWNER="oracle", GROUP="oinstall", MODE="0660" KERNEL=="sd?", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/%k", RESULT=="1ATA_VBOX_HARDDISK_VB78dfaecb-a4c2453d", SYMLINK+="asmdisks/data2", OWNER="oracle", GROUP="oinstall", MODE="0660" KERNEL=="sd?", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/%k", RESULT=="1ATA_VBOX_HARDDISK_VBebc2562a-43e3cd04", SYMLINK+="asmdisks/data3", OWNER="oracle", GROUP="oinstall", MODE="0660"
Quelques précisions sur cette configuration:
- La règle udev utilise elle même la commande scsi_id pour identifier les disques (PROGRAM==). Le résultat attendu de cette commande, soit l’id scsi ciblé, est configuré dans la clause RESULT==
- Le format de nommage des disques doit être matché par la regex « sd?« . Si par exemple les disques virtuels sont vus comme xvdb, xvdc, xvdd, alors il faudra l’adapter en « xvd?«
- Le binaire scsi_id doit se trouver dans /usr/lib/udev
- L’option SYMLINK+ permet de définir le nom de l’alias qui sera créé sous /dev. En spécifiant asmdisks/nom_du_disque, on obtiens un sous-répertoire asmdisks sous /dev, dans lequel les alias seront positionnés.
Une fois cette règle en place, elle doit être effective au prochain reboot.
Pour éviter de devoir rebooter, il faut recharger les règles et les réappliquer (option trigger).
[root@orasrv1 ~]# udevadm control --reload-rules [root@orasrv1 ~]# udevadm trigger
Les alias devraient apparaitre sous /dev/asmdisks
[root@orasrv1 ~]# ls -l /dev/asmdisks/ lrwxrwxrwx 1 root root 6 19 déc. 17:03 data1 -> ../sdb lrwxrwxrwx 1 root root 6 19 déc. 17:00 data2 -> ../sdc lrwxrwxrwx 1 root root 6 19 déc. 17:03 data3 -> ../sdd
Il faut également s’assurer que les droits et owners des devices sous-jacents soient bien passé à oracle:oinstall en mod 660
[root@orasrv1 ~]# ls -l /dev/sd[bcd] brw-rw---- 1 oracle oinstall 8, 16 19 déc. 17:09 /dev/sdb brw-rw---- 1 oracle oinstall 8, 32 19 déc. 17:05 /dev/sdc brw-rw---- 1 oracle oinstall 8, 48 19 déc. 17:07 /dev/sdd
Il est intéressant à ce stade de vérifier que la configuration reste bien en place après un reboot du serveur.
Utilisation
A ce stade, les disques sont prêts à être ajoutés dans un diskgroup.
Si le grid n’est pas déjà installé, il est maintenant possible de l’installer et de créer le diskgroup initial en utilisant ces disques.
Veiller à utiliser la asm_diskstring /dev/asmdisks pour que les disques ASM apparaissent en candidat.
Si l’instance ASM est déjà en place, il est possible de s’y connecter et de modifier le paramètre.
[grid@orasrv1 ~]sqlplus / as sysasm SQL> alter system set asm_diskstring = '/dev/asmdisks' scope = 'both';
Si un autre emplacement contient également des disques ASM, il est possible de mettre plusieurs chemins dans le paramètre asm_diskstring :
SQL> alter system set asm_diskstring = '/dev/asmdisks','autre/chemin/de/disques/asm' scope = 'both';
La règle udev que nous avons mis en place permet de figer l’association entre le nom de l’alias et le device qu’il doit representer.
Si l’on venait à inverser l’ordre de branchement des disques sur le controlleur, l’instance ASM ne serait pas impactée du tout.
