"Veritas Volume Manager" (ou VxVM) est un gestionnaire de volumes logiques propriétaire et payant, disponible pour de nombreux systèmes Unix, et même pour Windows. En France, on le trouve à peu près une fois sur deux sur les systèmes Solaris, à la place du gestionnaire de volumes logiques de Sun, "Solaris Volume Manager" ou "SVM" (anciennement "Solstice Disk Suite"), qui lui, est offert avec Solaris.
Par rapport à SVM et à beaucoup d'autres concurrents, VxVM apporte :
Certains passages sont illustrés d'exemples ; ces exemples sont tirés d'un serveur Solaris 8 HW 7/03 avec Veritas Volume Manager 3.5.
Précision : cet article est issu de mon expérience personnelle, sur le "terrain", sans avoir reçu de "vraie" formation. Mais certaines commandes m'ont été données par des spécialistes du sujet. Aussi, les méthodes que j'utilise ne sont peut-être pas les meilleures, mais elles fonctionnent.
Avant de commencer quoique ce soit, il est préférable de faire une sauvegarde des données, et surtout une copie du disque système, surtout si des patchs sont nécessaires.
Veritas Volume Manager s'installe avec une clé de licence. Pour obtenir cette clé de licence, il faut contacter Sun (si vous avez acheté la licence chez eux) et leur fournir :
Lorsqu'on met un disque dur sous contrôle de VxVM, on peut encapsuler ou non. Ne pas encapsuler signifie mettre le disque sous contrôle de VxVM en supprimant tout ce qui est dessus, ce qui ne nécessite aucun prérequis. Encapsuler signifie qu'on rajoute la couche VxVM sur un disque en conservant les données existantes, ce qui implique quelques prérequis. Pour qu'un disque soit "encapsulable", il faut qu'il ait deux partitions de libres au sens "format" du terme ; c'est à dire qu'il doit y avoir deux slices inutilisées et quelques Mo de non alloués aux autres slices (à prioris, un ou deux cylindres suffisent).
Ces deux slices seront ensuite utilisés par VxVM et taggués 14 et 15 (visible en faisant prtvtoc /dev/rdsk/cxtydzs2). La partition 15 est la "private", que VxVM utilise pour son fonctionnement interne. La 14 est la "public" qui couvre tout le disque (à l'identique de la slice 2 pour Solaris) et qui représente les données.
Installer les patchs Sun Solaris pré-requis à l'installation des packages Veritas. Ces patchs dépendent de la version de Solaris, de la version de Veritas Volume Manager et des patchs déjà installés. Ils sont détaillés dans la documentation d'installation de Veritas Volume Manager fournie avec le cd d'installation. Les détails dépassent le cadre de ce document.
Avant de passer à la suite, il est préférable de rebooter le serveur et de vérifier que le serveur se comporte correctement, car certains patchs peuvent apporter des problèmes.
Cette étape est facultative : si on ne la rentre pas tout de suite, elle sera demandée plus tard. Pour entrer la clé, taper la commande vxlicinst.
Taper la commande vxinstall et suivre les instructions en répondant aux questions (des explications sont données au fur et à mesure). Il est conseillé de choisir "custom installation". Si on veut mettre le disque système sous contrôle de VxVM, il faut répondre "yes" à la question "Encapsulate boot disk ?". Pour cela, il faut que le disque soit "encapsulable" (voir Préparation des disques durs).
Une fois l'installation terminée, il faudra rebooter le serveur. Ça sera l'occasion de vérifier que rien n'a été cassé par l'installation, et que tout démarre bien dans le cas où on a encapsulé le système.
Pour des raisons évidentes de sécurité, il est intéressant de faire un miroir du disque sytème. Le miroir étant un miroir logiciel géré par VxVM, il est bien sûr impératif que le disque système soit déjà sous contrôle de VxVM.
Dans l'explication qui suit, on considère que le disque système est c0t0d0 et que le disque mirroir est c0t2d0.
Voici les différentes étapes :
On peut taper les commandes "prtvtoc /dev/rdsk/c0t2d0s2" pour vérifier que les tags 14 et 15 ont été créés, preuve que le disque est sous contrôle de VxVM.
Maintenant, il va falloir configurer l'OBP pour pouvoir booter sur l'un ou l'autre des disques. Pour cela, on va créer des alias "rootdisk" et "rootmir" qui vont pointer respectivement sur le disque principal et le mirroir.
Pour commencer, sous Solaris, il faut repérer le chemin long des deux devices :
La partie à retenir, pour cet exemple, est "/pci@1f,4000/scsi@3/sd@0,0" et "/pci@1f,4000/scsi@3/sd@2,0", c'est à dire le chemin sans "../../devices" au début et sans ":" et les caractères suivants à la fin. Si on a oublié de les noter, on pourra les retrouver dans l'OBP en tapant devalias et en repérant les disques "disk 0" et "disk 2".
Ensuite, il faut rebooter le serveur pour se retrouver dans l'OBP : init 0.
Une fois dans l'OBP, taper les commandes suivantes :
Le serveur va alors rebooter. Par défaut, il va booter sur "rootdisk". Pour le forcer à booter sur le miroir (il est conseillé de le faire pour vérifier qu'il marche), il faut taper "boot rootmir" dans l'OBP.
Avant de mettre un disque sous contrôle de VxVM, on peut s'assurer qu'il n'y est pas déjà, ou simplement regarder quels sont les autres disques gérés par VxVM. Pour cela, on utilise la commande "vxdisk list".
Si le disque qu'on veut ajouter est bien vu par "format", mais n'est pas listé par "vxdisk list", alors exécuter les commandes suivantes : "drvconfig", puis "disks", puis "vxdctl enable". Maintenant, "vxdisk list" doit le voir.
Détail des commandes :
La commande à utiliser est vxdiskadd. Elle a pour effet d'associer le disque à un groupe (existant ou nouveau).
Il va alors demander si on veut ajouter le disque à un Disk Group existant (il affiche la liste) ou si on veut en créer un nouveau (il va demander le nom).
Il faut ensuite dire si le disque doit être encapsulé ou pas. Pour rappel, encapsuler consiste à conserver les données existantes, mais nécessite que le disque soit encapsulable (voir Préparation des disques durs). Si le disque ne contient pas de données, il ne faut pas encapsuler.
Il existe une autre possibilité pour faire la même chose : taper "vxdiskadm" et choisir "1. Add or initialize one or more disks" dans le menu, et répondre aux questions comme avec vxdiskadd.
Remarque : lorsqu'un disque est géré par VxVM, son raw device n'est plus vu comme /dev/rdsk/..., mais comme /dev/vx/rdsk..... De même, le spécial devient /dev/vx/dsk/....
Pour créer un volume (une partition logique) dans un disk group (dg), on utilise la commande vxassist. Puis on formate le volume avec newfs ou mkfs, comme pour n'importe quelle partition physique. Pour finir, il faudra l'ajouter dans /etc/vfstab.
Syntaxe :
Exemple :
Création d'un filesystem UFS :
Création d'un filesystem VxFS :
Ajout de la ligne correspondante dans /etc/vfstab :
Remarque : la création d'un filesystem VxFS nécessite une licence Veritas File System.
Syntaxe :
Renvoie la taille en blocs de 512 octets (colonne OFFSET=taille utilisée, LENGTH=taille restante)
Exemple :
Agrandir de 4 Go :
Réduire de 3 Go :
Bien sûr, tout ça se fait à chaud, sans avoir besoin de démonter les partitions. Tout le monde peut continuer à travailler. C'est formidable !
Si vxresize n'est pas dans le PATH, le rechercher avec "grep vxresize /var/sadm/install/contents". Il est normalement dans /usr/lib/vxvm/bin/.
Si on veut changer le nom d'un volume, utiliser la syntaxe suivante :
Lorsqu'on fait vxprint, on remarque que le volume possède des plexes qui lui sont associés. Les plexes sont nécessaires au fonctionnement de VxVM, mais n'ont pas vraiment d'intérêt pour l'administrateur système. Cependant, lorsqu'on créé un volume, les plexes associés sont automatiquement créés avec un nom reprenant le nom du volume, mais renommer le volume ne renomme pas les plexes. Il peut être intéressant de renomer également les plexes pour garder une cohérence, notamment quand on fait un vxprint. La syntaxe pour renomer les plexes est la suivante :
Syntaxe :
Exemple :
Pour retirer un disque, il faut d'abord avoir supprimé tous les volumes qu'il contenait (voir Supprimer un volume), et également supprimer les disk group.
Puis vérifier que ça a bien fonctionné avec :
Pour changer un disque qui est sous contrôle de VxVM (par exemple parce qu'il est en fin de vie), le principe est de :
Les détails sont ci-dessous.
Taper "vxdiskadm", choisir l'option "4. Remove a disk for replacement" et indiquer le volume (ex: datadg01, pour le premier volume du groupe datadg).
On peut maintenant faire une copie brute du disque vers le nouveau avec dd. C'est brutal, mais ça marche.
Taper "vxdiskadm", choisir l'option "5. Replace a failed or removed disk" et indiquer le disque (ex: c1t1d0s2).
Il arrive que cette méthode ne fonctionne pas. Dans ce cas, on peut utiliser les outils en ligne de commande :
Pour finir, remonter les partitions associées avec mount.
Remarque : on peut également faire plus "propre" en copiant d'abord les données du disque, en ne prenant que le contenu des volumes VxVM qui sont sur le disque en question, mais c'est plus long à expliquer et je n'ai pas encore testé.
On utilise la commande vxlicrep.
Avec VxFS, on peut activer ou désactiver la gestion des fichiers de plus de 2 Go. C'est l'option "largefiles" qui gère ça. Cette option se met à la création du filesystem, mais peut bien sûr s'activer ou se désactiver à chaud... Il n'y a donc rien à modifier dans /etc/vfstab.
Seules les versions anciennes de VxFS n'activent pas les largefiles par défaut.
"-F vxfs" est facultatif.
Si on doit faire un fsck sur un filesystem VxFS, la syntaxe est la suivante :
Explications :
Dernière mise à jour : 10 janvier 2010