LVM HP
De DocUnix.
Sommaire |
Serveurs STAND ALONE
Pré requis
- Le volume groupe vg00 doit être réservé pour le système.
- De préférence, on ne crée pas de volume logique (LV) pour des logs sur un disque où il y a des datas.
- On spécifie toujours le disque sur lequel on étend un LV ainsi que son miroir (s’il y a lieu d'être).
- Dans le doute, consulter un ingénieur qualifié ou le support.
Création d’un FS
- Initialisation du LV :
lvcreate –n lv_name /dev/vg_name
sur une baie disque, il ne faut pas autoriser la ré-allocation des bad blocks :
lvcreate –r N –n lv_name /dev/vg_name
- Définition de la taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz
- Création du miroir (si nécessaire) :
lvextend –m 1 /dev/vg_name/lv_name /dev/dsk/cxtydz_miroir
- Création du FS :
Par sécurité, on autorise le largefiles
newfs –F vxfs –o largefiles /dev/vg_name/rlv_name
- Création du point du point de montage :
mkdir <point de montage>
- Ajout de l’entrée dans le fichier /etc/fstab :
/dev/vg_name/lv_name <point de montage> vxfs delaylog 0 2
- Montage du FS :
mount <point de montage>
- Vérification :
bdf (ce doit être le dernier filesystem monté).
- Vérification des droits :
ls -la <point de montage>
Augmentation d’un FS
- Définition de la nouvelle taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz /dev/dsk/cxtydz_miroir avec cxtydz primaire et cxtydz_miroir le disque miroir (si nécessaire)
- Augmentation du FS :
fsadm –F vxfs –b (taille en MO*1024) <point de montage>
- Vérification :
bdf
Reduction d’un FS
- Défragmentation du filesystem :
fsadm -F vxfs -deDE <point de montage>
- Réduction du filesysteme :
fsadm -F vxfs -b (taille en MO*1024) <point de montage> ou fsadm -F vxfs -b (taille en méga)M <point de montage>
- Vérification :
bdf
- Réduction du lv :
lvreduce -L (taille en mega) /dev/vg_name/lv_name
Modification des options de montage à chaud
Attention, il faut penser à changer les options de montage dans /etc/fstab
mount -o remount,<options> <point de montage>
Typiquement, pour améliorer les I/O pour Oracle en activant le directe I/O
mount -o remount,delaylog,nodatainlog,mincache=direct,convosync=direct <point de montage>
exemple d'autre utilisation : basculer /opt et /usr entre read-only et read-write
Suppression d’un FS
- Démontage du FS :
umount <point de montage>
- Suppression du LV :
lvremove /dev/vg_name/lv_name
- Suppression de la ligne concernée dans le fichier /etc/fstab
- Suppression du point de montage.
Création d’un RAW DEVICE pour SYBASE
- Initialisation du LV :
lvcreate –n lv_name /dev/vg_name
avec une baie disque, il ne faut pas autoriser le ré-allocation bad-blocks
lvcreate –r N –n lv_name /dev/vg_name
- Définition de la taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz
- Création du miroir (si nécessaire)
lvextend –m 1 /dev/vg_name/lv_name /dev/dsk/cxtydz_miroir
- Ajout des droits SYBASE :
chown <user sybase>:<group sybase> /dev/vg_name/r*
Suppression d’un RAW DEVICE pour SYBASE
- Suppression du LV :
lvremove /dev/vg_name/lv_name
Clusters MC SERVICE GUARD
Pré requis
- Le volume groupe vg00 doit être réservé pour le système
- On ne crée jamais de volume logique pour des logs sur un disque où il y a des datas
- On spécifie tjs le disque sur lequel on étend un LV ainsi que le miroir
- On doit exporter la map du vg ssi on crée/supprime un LV.
- Lors d’un ajout d’un raw device, ne pas oublier de lui attribuer les bons droits.
- Dans le doute, consulter une ingénieur ou le support.
Création d’un FS
- Initialisation du LV :
lvcreate –n lv_name /dev/vg_name
avec une baie disque, il ne faut pas autoriser le ré-allocation bad-blocks
lvcreate –r N –n lv_name /dev/vg_name
- Définition de la taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz
- Création du miroir (si nécessaire)
lvextend –m 1 /dev/vg_name/lv_name /dev/dsk/cxtydz_miroir
- Initialisation du filesystem
newfs –F vxfs –o largefiles /dev/vg_name/rlv_name
- Mise à jour du fichier control.sh
Ouvrir avec vi le fichier /etc/cmcluster/package_name/control.sh Se rendre à la derniere ligne du type LV[xx]… La dupliquer sur la ligne en dessous en l’ajoutant. Sur la ligne dupliquée ajouter 1 a tous les index et renseigner les champs LV[xx]= et FS[xx] Exemple : LV[26]="/dev/vg_package2/lv_toto1"; FS[26]="/apps/package2/toto1"; FS_MOUNT_OPT[26]="" LV[27]="/dev/vg_package3/lv_toto2"; FS[27]="/apps/package3/toto2"; FS_MOUNT_OPT[27]=""
- Création du point du point de montage :
mkdir <point de montage>
- Monter le filesystem en copiant/collant la ligne du control.sh
mount <lv_name> <point de montage>
- Appliquer les droits sur le filesystem
chown user_name:group_name <point de montage>
- Mise à jour de la map du vg
vgexport –p –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name
- Recopie de la map sur les autres nœuds du cluster via ftp (répertoire équivalent)
- Mise à jour du vg sur les autres nœuds :
vgexport /dev/vg_name mkdir /dev/vg_name chmod 755 /dev/vg_name mknod /dev/vg_name/group c 64 même_mineur_du_vg_source (ex : 0x010000) vgimport –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name chown <user sybase>:<group sybase> /dev/vg_name/r* mkdir <point de montage>
- Reproduire les modifications appliquées au fichier control.sh de l’autre noeud :
Ouvrir avec vi le fichier /etc/cmcluster/package_name/control.sh Se rendre à la dernière ligne du type LV[xx]… La dupliquer sur la ligne en dessous. Sur la ligne dupliquée ajouter 1 a tous les index et renseigner les champs LV[xx]= et FS[xx]
Augmentation d’un FS
- Définition de la nouvelle taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz /dev/dsk/cxtydz_miroir avec disque1 le cxtxdx primaire et cxtxdx_bis le disque miroir (si nécessaire)
- Augmentation du FS :
fsadm –b (taille en MO * 1024) <point de montage>
- Vérification :
bdf
Suppression d’un FS
- Démontage du FS :
umount <point de montage>
- Suppression du point de montage du FS :
rmdir <point de montage>
- Suppression du LV :
lvremove /dev/vg_name/lv_name
- Suppression du filesystem dans le fichier control.sh
Ouvrir avec vi le fichier /etc/cmcluster/package_name/control.sh Rechercher à la ligne du type LV[xx]…contenant les informations concernant le filesystem Supprimer la ligne et refaire la numérotation des lignes suivantes (attention 3 champs par ligne). Exemple : LV[26]="/dev/vg_package2/lv_toto1"; FS[26]="/apps/package2/toto1"; FS_MOUNT_OPT[26]="" LV[27]="/dev/vg_package3/lv_toto2"; FS[27]="/apps/package3/toto2"; FS_MOUNT_OPT[27]=""
- Mise à jour de la map du vg
vgexport –p –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name
- Recopie de la map sur les autres nœuds du cluster via ftp (répertoire équivalent)
- Mise à jour du vg sur les autres nœuds :
- Reporter les modification du control.sh du premier nœud sur les autres nœuds
- Supprimer le point de montage
rmdir <point de montage> vgexport /dev/vg_name mkdir /dev/vg_name chmod 755 /dev/vg_name mknod /dev/vg_name/group c 64 même_mineur_du_vg_source (ex : 0x010000) vgimport –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name chown <user sybase>:<group sybase> /dev/vg_name/r*
Création d’un RAW DEVICE SYBASE
- Initialisation du LV :
lvcreate –n lv_name /dev/vg_name
avec une baie disque, il ne faut pas autoriser le ré-allocation bad-blocksavec Symmetrix
lvcreate –r N –n lv_name /dev/vg_name
- Définition de la taille du LV :
lvextend –L «taille en MO» /dev/vg_name/lv_name /dev/dsk/cxtydz
- Création du miroir (si nécessaire)
lvextend –m 1 /dev/vg_name/lv_name /dev/dsk/cxtydz_miroir
- Ajout des droits SYBASE :
chown <user sybase>:<group sybase> /dev/vg_name/rlv_name
- Mise à jour de la map du vg
- Sur le nœud du cluster où les Raw devices on été créés :
/etc/cmcluster/PackageX/export_map_pkgX.ksh
- Sur l’autre nœud du ckuster :
/etc/cmcluster/PackageX/import_map_pkgX.ksh
Suppression d’un RAW DEVICE SYBASE
- Suppression du LV :
lvremove /dev/vg_name/lv_name
- Mise à jour de la map du vg
vgexport –p –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name
- Recopie de la map sur les autres nœuds du cluster via ftp (répertoire équivalent)
- Mise à jour du vg sur les autres nœuds :
vgexport /dev/vg_name mkdir /dev/vg_name chmod 755 /dev/vg_name mknod /dev/vg_name/group c 64 même_mineur_du_vg_source (ex : 0x010000) vgimport –s –m /etc/cmcluster/Packagex/vg_name.map /dev/vg_name chown <user sybase>:<group sybase> /dev/vg_name/r*
Utilisation du PVG
Lorsque des LVs sont mirrorés sur des disques distants (du SAN inter sites par ex.) il faut être vigilant lors de la création ou l'augmentation des filesystems pour ne pas endommager le miroir. Si on mirrore mal (c'est-à-dire en spécifiant des mauvais disques) on se retrouve avec un mirroir incohérent et on a donc des LVs qui contiennent des PEs sur des disques situés un même site. En cas de crash d'une baie ou d'un incendie, on perd donc les disques, les données et le miroir. D'où l'intérêt de mirrorer avec soin.
Par ex. SAM (l'outil de gestion système d'HP-UX) ne sait pas déterminer où sont situés les disques physiquement. Lorsqu'on lui demande d'étendre un LV il prend les premiers disques libres. Et la plupart du temps on se retrouve un miroir incorrect car les n disques utilisés peuvent potentiellement se situés sur un même site. On peut rétablir la situation à coups de lvextend -m 0, lvextend -m 1 et pvmove mais c'est long et moins on a d'espace disque de libre et plus c'est fastidieux à faire.
Si beaucoup de personnes disposent des droits root sur une machine on a donc plus de risques d'obtenir un LVM moisi. Tout le monde ne fait pas forcément attention lors des manipulations LVM. Ou bien d'autres personnes ne savent pas faire ou pensent savoir faire. Pour éviter ça le PVG permet de réduire les risques.
Ci-dessous un résumé des étapes pour mettre en place le PVG :
- Création du fichier /etc/lvmpvg :
VG /dev/vg_data1 PVG PV_siteA /dev/dsk/c1t6d0 /dev/dsk/c2t6d0 PVG PV_siteB /dev/dsk/c3t6d0 /dev/dsk/c4t6d0
Pour le VG vg_data1 on a 2 PVGs composés des disques c[1,2]t6d0 d'une part et c[3,4]t6d0 d'autre part. C'est à dire que lorsqu'on utilise lvextend ou lvreduce le système sait qu'il doit travailler avec 1 disque de chaque PVG.
- Modification des paramètres des LVs :
On utilise l'option PVG-strict de la commande lvchange (c'est le même principe que le strict / superstrict sous AIX) :
lvchange -s /dev/vg_data1/lv_data1
/!\ Attention, il faut passer le LV en PVG-strict avant de lui ajouter un mirroir. Ci qui revient à faire, dans l'ordre, : lvcreate, lvchange puis lvextend.
/!\ Un vgexport met à vide le fichier etc/lvmpvg, il faut penser à le backuper avant de faire des export/import de VG.
C'est tout. Maintenant un simple lvextend sans spécifier de disque fonctionnera en utilisant un disque de chaque PVG. De cette manière on aura un mirroring propre. Par ailleurs on peut également utiliser la méthode en spécifiant manuellement les disques. Enfin quand on rajoute ou supprime un ou plusieurs disques d'un VG il faut penser à mettre à jour le /etc/lvmpvg en conséquence.
Tuning vxfsd
Depuis HP-UX 11i v2, nous constatons une forte augmentation de la charge CPU lié à l'activité de vxfsd, en configuration par "défaut".
A l'heure actuelle, nous sommes à la recherche d'une solution.
Le premier document qui nous semble pertinent est http://docs.hp.com/en/5992-0732/5992-0732.pdf
L'article sera enrichi au fur et mesure des recherches.
Incident sur pvmove
Lors de migration de données de disque à disque, il est très pratique d'utiliser la commande pvmove. Or celle-ci peut échouer et laisser les LV dans des états incohérent.
Pour vérifier passez la commande lvdisplay -v /dev/<vg name>/<lv name> | pg .
Si le résultat fait apparaitre des copies en PX_NOPV, il faut utiliser la commande lvreduce -m <x> /dev/<vg name>/<lv name>, pour supprimer la copie invalide; x exprimant le nombre de copie souhaitée moins 1; soit 0 pour 1 copie, 1 pour deux copies en miroir.
Puis vérifiez l'état du LV en répétant la commande lvdisplay -v /dev/<vg name>/<lv name> | pg ; aucune copie ne doit plus apparaitre en PX_NOPV.
L'article de référence pour ces manipulations est http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1146681
