Bases
Cet article décrit certains avantages que la bibliothèque ASM spécifique à Linux fournie par Oracle (ci-après "ASMLib") apporte à l'administration d'un système Linux exécutant Oracle. Linux présente souvent le défi de la persistance du nom de disque. Modifiez la configuration de stockage et un disque qui apparaissait comme /dev/sdg hier peut apparaître comme /dev/sdh après un redémarrage aujourd'hui. Comment ces changements peuvent-ils être isolés afin qu'ils n'affectent pas l'ASM ?
Pourquoi ne pas laisser ASM analyser tous les disques ?
ASM analyse tous les disques qu'il est autorisé à découvrir (via asm_diskstring). Pourquoi ne pas analyser tous les disques et laisser ASM déterminer ce qui l'intéresse, plutôt que de se soucier de la persistance du nom du disque ?
La question est théoriquement correcte. Si vous passez /dev/sd* à ASM et qu'ASM peut lire les périphériques, ASM peut en effet choisir ses disques, que /dev/sdg ait été remplacé par /dev/sdh lors de ce démarrage particulier.
Cependant, pour lire ces appareils, ASM doit avoir l'autorisation de lire ces appareils. Cela signifie qu'ASM doit avoir la propriété d'un utilisateur ou d'un groupe sur tous les périphériques /dev/sd*, y compris tous les disques système. La plupart des administrateurs système ne souhaitent pas que l'utilisateur oracle possède ses propres disques système afin qu'ASM puisse les ignorer. Le risque d'erreurs (écriture DBA sur le volume /home, etc.) est bien trop élevé.
ASMLib contre UDev ou DevLabel
Il existe différentes méthodes pour fournir des noms qui ne changent pas, notamment devlabel et udev. Que fournit ASMLib que ces solutions ne fournissent pas ?
Le plus gros problème n'est pas spécifiquement un nom persistant - il fait correspondre ce nom à un ensemble d'autorisations. Peu importe si /dev/sdg est maintenant /dev/sdh, tant que le nouveau /dev/sdh a la propriété oracle:dba et que le nouveau /dev/sdg - qui était auparavant /dev/sdf - a le propriété de l'ancien /dev/sdf. Le moyen le plus simple de s'assurer que les autorisations sont correctes est le nommage persistant. Si un disque apparaît toujours sous le même nom, vous pouvez toujours lui appliquer les mêmes autorisations sans vous inquiéter. De plus, vous pouvez ensuite exclure les noms qui correspondent aux disques système. Même si les autorisations sont correctes, un administrateur système ne voudra pas qu'ASM analyse les disques système à chaque fois.
Désormais, udev ou devlabel peuvent gérer le maintien de sdg en tant que sdg (ou /dev/mydisk, peu importe). Qu'ajoute ASMLib ? Quelques trucs, en fait. Avec ASMLib, il existe une commande simple pour étiqueter un disque pour ASM. Avec udev, vous devrez modifier le fichier de configuration udev pour chaque disque que vous ajoutez. Vous devrez déterminer un identifiant unique correspondant au disque et apprendre la syntaxe de configuration udev.
Le nom est également lisible par l'homme. Avec un Apple XServe RAID, pourquoi avoir un disque nommé /dev/sdg alors qu'il peut s'agir de DRAWER1DISK2 ? ASMLib peut également lister tous les disques, avec udev vous devez soit savoir dans votre tête que sdg, sdf et sdj sont pour ASM, soit vous devez fournir des noms. Avec ASMLib, il n'y a aucune chance qu'ASM analyse lui-même les disques système. En fait, ASMLib ne modifie jamais les noms du système pour les disques. ASMLib n'utilise jamais le nom "/dev/sdg". Après avoir interrogé les disques au démarrage, il fournit son propre accès aux périphériques avec des autorisations pour Oracle. /dev/sdg appartient toujours à root:root, et l'utilisateur oracle ne peut toujours pas accéder à l'appareil avec ce nom.
La configuration est persistante. Réinstallez un système et votre configuration udev a disparu. Les étiquettes d'ASMLib ne le sont pas. Avec udev, vous devez copier la configuration sur les autres nœuds d'un RAC. Si vous avez seize nœuds, vous devez copier chaque modification de configuration sur les seize nœuds. Que vous utilisiez udev ou devlabel, vous devez définir correctement les autorisations sur les seize nœuds. ASMLib nécessite juste une invocation de "/etc/init.d/oracleasm scandisks" pour récupérer toutes les modifications apportées sur l'autre nœud.
Ce ne sont là que quelques-uns des avantages qu'ASMLib apporte à la persistance des appareils.