Veritas Volume Manager (VxVM)

Introduction

"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 :

• pas de problème de nombre d'Inodes : il sont illimités sur VxVM
• transforme le niveau de Raid à chaud
• possibilité d'ajouter une patte en stripping (raid 0) à chaud
• réduction à chaud des partitions (uniquement si elles ont été formattées en VxFS – système de fichiers Veritas. Ne marche pas avec UFS – système de fichiers par défaut de Solaris).

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.

Installation

Avant d'installer

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.

Licence

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 :

• le product name (inscrit sur le certificat de licence fournit avec le cd)
• le numéro de série (inscrit sur le certificat de licence fournit avec le cd)
• l'adresse de votre société
• un contact dans votre société (nom + téléphone + mail)
• le hostid du serveur (taper hostid sous Solaris)

Préparation des disques durs

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.

Patcher Solaris

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.

Installer les packages Veritas Volume Manager

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.

# vxlicinst 					

VERITAS License Manager vxlicinst utility version 3.00.007d 					
Copyright (C) VERITAS Software Corp 2002. All Rights reserved. 					

Enter your license key : XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX 					

License key successfully installed for VERITAS Volume Manager 					

Installer / configurer Veritas

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 chapitre 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.

Mirrorer le disque système

Présentation

Pour des raisons évidentes de sécurité, il est intéressant de faire un miroir du disque systè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 miroir est c0t2d0.

Créer le mirroir

Voici les différentes étapes :

• ajouter un nouveau disque dans le serveur
• vérifier avec format qu'il est bien reconnu par Solaris. S'il ne l'est pas, forcer la reconnaissance du nouveau matériel avec "devfsadm -v".
• vérifier qu'il est vu par VxVM avec "vxdisk list". S'il ne l'est pas, taper les commandes suivantes "drvconfig", puis "disks", puis "vxdctl enable". Vérifier que cette fois il est bien reconnu.
• mettre le nouveau disque sous contrôle de VxVM, l'appeler "rootmir" et le faire appartenir au même disk group (dg) que le disque système (si on a conservé les choix par défaut, le disque système s'appelle "rootdisk" et appartient au groupe "rootdg"). La commande à utiliser est "vxdiskadd c0t2d0" ; il suffit de répondre aux questions.
• Mirrorer les disques avec la commande interactive "vxdiskadm" :
  • dans le menu, valider le choix "6 Mirror volumes on a disk"
  • faire "list" pour vérifier qu'on voit bien "rootdisk" et "rootmir"
  • lorsqu'il demande le disque à mirrorer, lui dire "rootdisk"
  • lorsqu'il demande le disque de destination, lui dire "rootmir"
  • confirmer. Il va alors mirrorer chaque volume existant d'un disque à l'autre, en affichant la progression.

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.

# prtvtoc /dev/rdsk/c0t2d0s2 					
* /dev/rdsk/c0t2d0s2 partition map 					
* 					
* Dimensions: 					
*     512 bytes/sector 					
*     135 sectors/track 					
*      16 tracks/cylinder 					
*    2160 sectors/cylinder 					
*    3882 cylinders 					
*    3880 accessible cylinders 					
* 					
* Flags: 					
*   1: unmountable 					
*  10: read-only 					
* 					
* Unallocated space: 					
*       First     Sector    Last 					
*       Sector     Count    Sector 					
*     2095200 4292874256      2159 					
*     8380800 4288681696   2095199 					
*     3144960    615600   3760559 					
*     7497360    883440   8380799 					
* 					
*                          First     Sector    Last 					
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory 					
 0      2    00       2160   2093040   2095199 					
 1      3    01    2095200   1049760   3144959 					
 2      5    01          0   8380800   8380799 					
 3     15    01          0      2160      2159 					
 4     14    01       2160   8378640   8380799 					
 6      4    00    3760560   2097360   5857919 					
 7      7    00    5857920   1639440   7497359 					

Configurer l'Openboot Prom (OBP)

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 :

# ls -l /dev/rdsk/c0t0d0s2 /dev/rdsk/c0t2d0s2
lrwxrwxrwx   1 root     root          45 Oct 27 15:31 /dev/rdsk/c0t0d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@0,0:c,raw
lrwxrwxrwx   1 root     other         45 Oct 27 15:31 /dev/rdsk/c0t2d0s2 -> ../../devices/pci@1f,4000/scsi@3/sd@2,0:c,raw

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 :

setenv use-nvramrc? True
nvalias rootdisk /pci@1f,4000/scsi@3/sd@0,0
nvalias rootmir /pci@1f,4000/scsi@3/sd@2,0
setenv boot-device rootdisk rootmir
reset-all

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.

Mettre un disque non système sous contrôle de VxVM

Lister les disques sous contrôle de VxVM

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".

# vxdisk list 					
DEVICE       TYPE      DISK         GROUP        STATUS 					
c0t0d0s2     sliced    rootdisk     rootdg       online 					
c0t1d0s2     sliced    -            -            error 					
c0t2d0s2     sliced    rootmir      rootdg       online 					
c0t3d0s2     sliced    -            -            error 					
c2t0d0s2     sliced    -            -            error 					
c2t3d0s2     sliced    -            -            error 					
c3t3d0s2     sliced    -            -            error 					

Si le disque n'est pas vu par VxVM

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 :

• drvconfig : scanne la chaîne scsi et détecte les nouveaux disques
• disks : créé les fichiers device dans /dev
• vxdctl enable : demande à VxVM de prendre les disques en compte

Mettre le disque sous contrôle de VxVM (disk group)

La commande à utiliser est vxdiskadd. Elle a pour effet d'associer le disque à un groupe (existant ou nouveau).

vxdiskadd c2t0d0

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 chapitre 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/....

Gestion des volumes

Créer un volume

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 :

vxassist -b -g nom_disk_group make nom_volume taille

Exemple :

vxassist -b -g dbdg make oraclelv 20g

Création d'un filesystem UFS :

newfs /dev/vx/rdsk/nom_disk_group/nom_volume

Création d'un filesystem VxFS :

mkfs -F vxfs /dev/vx/rdsk/nom_disk_group/nom_volume

Ajout de la ligne correspondante dans /etc/vfstab :

/dev/vx/dsk/nom_disk_group/nom_volume       /dev/vx/rdsk/nom_disk_group/nom_volume      /point_de_montage      vxfs       defaults      1 2

Remarque : la création d'un filesystem VxFS nécessite une licence Veritas File System.

Vérifier l'espace restant sur un volume

Syntaxe :

vxdg [-g groupe] free

Renvoie la taille en blocs de 512 octets (colonne OFFSET=taille utilisée, LENGTH=taille restante)

Exemple :

# vxdg -g rootdg free 					
DISK         DEVICE       TAG          OFFSET    LENGTH    FLAGS 					
rootdisk     c0t0d0s2     c0t0d0       71109846  11556     n 					
rootmir      c1t0d0s2     c1t0d0       24576723  5778      - 					
rootmir      c1t0d0s2     c1t0d0       24588278  1         - 					
rootmir      c1t0d0s2     c1t0d0       71121402  2889      -

Agrandir ou réduire un volume

Agrandir de 4 Go :

vxresize -g nom_disk_group nom_volume +4g

Réduire de 3 Go :

vxresize -g nom_disk_group nom_volume -3g

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/.

Renommer un volume (et renommer ses plexes)

Si on veut changer le nom d'un volume, utiliser la syntaxe suivante :

vxedit rename oldlv newlv

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 renommer également les plexes pour garder une cohérence, notamment quand on fait un vxprint. La syntaxe pour renommer les plexes est la suivante :

vxedit -g rootdg -p rename oldlv-01 newlv-01

Supprimer un volume

Syntaxe :

vxassist -g nom_groupe remove volume nom_volume

Exemple :

vxassist -g dbdg remove volume oraclelv

Voir la liste de tous les dg

# vxdg list 					
NAME         STATE          ID 					
rootdg       enabled              1247755677.135.uyqev3 					
exploitdg    enabled              1151484964.148.uyqev3 					
tkappli00dg  enabled              1142590040.99.uyqev3 					
tk00dg       enabled              1142591823.119.uyqev3 					
tk01dg       enabled              1171641444.4311.bakctl01 					
zonedg       enabled              1141381993.11.uyqev3

Retirer un disque d'un DG

Nous allons suivre l'exemple d'un DG qui est réparti sur deux disques. La totalité des volumes occupe moins de place que la taille d'un disque. Nous allons donc migrer les volumes d'un disque pour tous les placer sur le même disque, puis retirer le disque qui n'a plus de données. Ainsi on pourra réutiliser le disque pour autre chose.

Dans l'exemple qui suit, le DG s'appelle exampledg composé de exampledg_01 et exampledg_02.

On regarde l'espace utilisé sur chacun des disques :

# vxdg -g exampledg free
DISK         DEVICE       TAG          OFFSET    LENGTH    FLAGS
exampledg exampledg_01 emcpower108s2 emcpower108  34213888  175484928 -
exampledg exampledg_02 emcpower109s2 emcpower109  134217728 75481088  -

Maintenant on va déplacer les données de exampledg_01 vers exampledg_02 :

/etc/vx/bin/vxevac -g exampledg exampledg_01 exampledg_02

Ca peut être long. On peut regarder l'avancement avec "vxtask list".

Une fois que c'est fini, on vérifie que tout l'espace a bien été libéré :

# vxdg -g exampledg free
DISK         DEVICE       TAG          OFFSET    LENGTH    FLAGS
exampledg_01 emcpower108s2 emcpower108  0         209698816 -
exampledg_02 emcpower109s2 emcpower109  168431616 41267200  -

On peut maintenant retirer le disque du DG :

# vxdg -g exampledg rmdisk exampledg_01

Et on vérifie qu'il ne fait plus partie du DG :

# vxdg -g exampledg free
DISK         DEVICE       TAG          OFFSET    LENGTH    FLAGS
exampledg_02 emcpower109s2 emcpower109  168431616 41267200  -

Retirer un disque du contrôle de VxVM

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.

Détruire un disk group

vxdg destroy mon_dg

Retirer le disque

vxdisk rm c3t0d0

Puis vérifier que ça a bien fonctionné avec :

vxdctl enable 					
vxdisk list

Échanger physiquement un disque sous contrôle de VxVM

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 :

• avertir VxVM qu'on va changer le disque
• faire une copie du disque
• remettre le disque sous contrôle de VxVM

Les détails sont ci-dessous.

Avertir VxVM qu'on va changer le disque

Taper "vxdiskadm", choisir l'option "4. Remove a disk for replacement" et indiquer le volume (ex: datadg01, pour le premier volume du groupe datadg).

Faire une copie du disque

On peut maintenant faire une copie brute du disque vers le nouveau avec dd. C'est brutal, mais ça marche.

Remettre le disque sous contrôle de VxVM

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 :

• /etc/vx/bin/vxreattach -b
• si ça ne marche pas : vxdg -g datadg -k adddisk datadg01=c1t1d0s2
• on vérifie que les volumes sont ENABLE : vxprint -Ath
• s'ils ne sont pas ENABLE, faire : vxvol -g datadg startall et si toujours pas ENABLE, forcer avec vxvol -g datadg -f startall

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é.

Export/import

Les disk group peuvent facilement s'exporter d'un serveur pour s'importer sur un autre serveur. Voici rapidement les différentes étapes sur un dg "testdg".

Sur le serveur source

1/ démonter les points de montage associés au dg

umount /directories

2/ stopper les volumes

vxvol -g testdg stopall

3/ exporter le dg

vxdg deport testdg

4/ déconnecter physiquement le disque ou la LUN du serveur

Sur le serveur cible

5/ connecter physiquement le disque ou la LUN sur le serveur

6/ importer le dg (veritas est capable tout seul de retrouver le dg sur le nouveau volume)

vxdg import testdg

7/ démarrer tous les volumes sur le nouveau système et resynchroniser les mirroirs en arrière plan

vxrecover -g testdg -sb

8/ monter les répertoires (créer si nécessaire les points de montage et éventuellement mettre à jour la vfstab)

Et voilà. C'est à peine plus compliqué que de passer une clé usb d'un pc à un autre !

Les quotas

Les quotas s'appliquent pour un utilisateur ou un groupe. Pour un fs, on fixe une limite soft et hard en nombre de blocs et/ou en nombre d'inodes.

Afficher la valeur actuelle

Pour afficher les quotas, on utilise la commande vxquota avec le nom ou l'uid.

vxquota -v 1399
Disk quotas for (no account) (uid 1399):
Filesystem     usage  quota  limit     timeleft  files  quota  limit     timeleft
/export/home   41304 250000 250000                  33      0      0           

Modifier les valeurs

On utilise vxedquota avec le nom ou l'uid. On se retrouve dans un editeur.

vxedquota -u 1399
==>
fs /export/home blocks (soft = 250000, hard = 250000) inodes (soft = 0, hard = 0)

Divers

Afficher la licence Veritas

On utilise la commande vxlicrep.

# vxlicrep 					
 
VERITAS License Manager vxlicrep utility version 3.00.007d 					
Copyright (C) VERITAS Software Corp 2002. All Rights reserved. 					
 
Creating a report on all VERITAS products installed on this system 					
 
 -----------------***********************----------------- 					
 
 License Key                         = XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXX 					
 Product Name                        = VERITAS Volume Manager 					
 Serial Number                       = 9547 					
 License Type                        = PERMANENT_NODE_LOCK 					
 OEM ID                              = 7 					
 Node Lock Type                      = (Hostid and Architecture ID) 					
 
 Features := 					
 
 VxVM                                = Enabled 					
 CPU Count                           = Not Restricted 					

Gestion des largefiles (fichiers de plus de 2 Go)

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.

Voir si les largefiles sont activés

# fsadm -F vxfs /point/de/montage 						
nolargefiles

"-F vxfs" est facultatif.

Les activer

# fsadm -o largefiles /point/de/montage

Les déactiver

# fsadm -o nolargefiles /point/de/montage

Faire un fsck d'un filesystem VxFS

Si on doit faire un fsck sur un filesystem VxFS, la syntaxe est la suivante :

/usr/sbin/fsck -F vxfs -o nolog,full /dev/vx/rdsk/mon_dg/mon_volume

Explications :

• nolog : demande à fsck d'accéder directement au filesystem sans passer par le log
• full : force à vérifier le filesystem en entier

Voir la liste des tâches en cours

Pour voir la liste des actions en cours par Veritas (ainsi que la progression en poucentage), taper :

# vxtask list

On obtient également le numéro de tâche. Avec, on peut mettre en pause la tâche avec "vxtask pause task_id" et la relancer avec "vxtask resume task_id".