10 Dec 2015
Nous allons voir dans cet article les différentes étapes pour agrandir un LUN présenté à un serveur Linux. La méthode a le grand avantage de pouvoir se faire en ligne ce qui est plutôt confortable si on aime bien pouvoir rentrer chez soi le soir ou le weekend…
Pour résumer, l’opération se déroulera en 4 étapes:
- Agrandir le LUN sur la baie SAN
- Faire en sorte que le serveur Linux voit les modifications au niveau multipathing
- Agrandir tous les éléments des LVM (PV/VG/LV)
- Agrandir le système de fichiers
Je ne traiterai pas de tout ce qui concerne la baie SAN car l’opération est différente en fonction des constructeurs / baies. Nous allons nous concentrer sur la partie Linux.
Pour rappel: Pensez à faire des sauvegardes !!!
Configuration du serveur de test
Le serveur utilisé pour les tests est un HP proliant DL380 G6. L’OS utilisé est une Red Hat Enterprise Linux 6.3. Le serveur est nommé SRV01. La baie SAN est une EMC VNX5300.
Le volume qui sera agrandi est vu par l’OS en tant que /dev/mapper/mpathj. La gestion de la redondance des liens est gérée par multipathd. Le volume est géré par LVM et est simplement composé d’un PV, un VG et un LV.
La taille d’origine est 10 Go, nous allons l’agrandir jusqu’à 50 Go.
Liste des commandes
Prise en compte par l’OS de l’agrandissement du LUN
Lancer la commande multipath -ll. Prenez note des différents devices qui pointent vers le LUN (ici sdg, sdm,sds et sdy).
srv01:root:/root> multipath -ll mpathj
mpathj (36006016072312f00563e92d8039de511) dm-4 DGC,VRAID
size=10G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| |- 3:0:0:14 sdg 8:96 active ready running
| `- 4:0:0:14 sdm 8:192 active ready running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 3:0:1:14 sds 65:32 active ready running
`- 4:0:1:14 sdy 65:128 active ready running
Faire un rescan de ces devices pour que l’OS voit que le LUN a été agrandi.
srv01:root:/root> echo 1 > /sys/block/sdg/device/rescan
srv01:root:/root> echo 1 > /sys/block/sdm/device/rescan
srv01:root:/root> echo 1 > /sys/block/sds/device/rescan
srv01:root:/root> echo 1 > /sys/block/sdy/device/rescan
Recharger la configuration du multipathing pour la prise en compte des modifications.
srv01:root:/root> multipath -r
En relançant la commande multipath -ll on peut valider que la taille du volume est bien de 50 Go.
srv01:root:/root> multipath -ll mpathj
mpathj (36006016072312f00563e92d8039de511) dm-4 DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| |- 3:0:0:14 sdg 8:96 active ready running
| `- 4:0:0:14 sdm 8:192 active ready running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 3:0:1:14 sds 65:32 active ready running
`- 4:0:1:14 sdy 65:128 active ready running
Agrandissement du PV / VG / LV
Maintenant que l’OS est au courant des changements, il reste à agrandir tous les éléments gérés par LVM. La commande pvs affiche des informations sur les PV existants.
srv01:root:/root> pvs /dev/mapper/mpathj
PV VG Fmt Attr PSize PFree
/dev/mapper/mpathj vg05 lvm2 a- 9,00g 0
La commande pvresize permet d’agrandir le PV en utilisant tout l’espace disponible sur le device.
srv01:root:/root> pvresize /dev/mapper/mpathj
Physical volume "/dev/mapper/mpathj" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
En relançant la commande pvs, on peut voir que la taille du PV à bien augmenté.
srv01:root:/root> pvs /dev/mapper/mpathj
PV VG Fmt Attr PSize PFree
/dev/mapper/mpathj vg05 lvm2 a- 49,00g 40,00g
Augmenter la taille du PV entraine automatiquement l’agrandissement du VG. On peut le vérifier avec la commande vgs.
srv01:root:/root> vgs vg05
VG #PV #LV #SN Attr VSize VFree
vg05 1 1 0 wz--n- 49,00g 40,00g
Reste maintenant à augmenter la taille du LV, lvs permet d’obtenir des infos sur les LV existants.
srv01:root:/root> lvs lv05
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv05 vg05 -wi-ao 9,00g
lvextend avec l’argument -l +100%FREE va agrandir le LV en prenant tout l’espace disponible sur le VG.
srv01:root:/root> lvextend -l +100%FREE /dev/vg05/lv05
Extending logical volume lv05 to 49,00 GiB
Logical volume lv05 successfully resized
On peut vérifier que le LV a bien été agrandi avec, encore une fois, la commande lvs.
srv01:root:/root> lvs lv05
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
lv05 vg05 -wi-ao 49,00g
Resize du file system
Dernière étape ! On va agrandir le file system. La commande df -h permet d’avoir des informations sur les files systems existants.
srv01:root:/root> df -h
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
/dev/sda2 58G 6,2G 49G 12% /
tmpfs 48G 0 48G 0% /dev/shm
/dev/sda1 194M 89M 95M 49% /boot
/dev/mapper/vg01-lv01
492G 459G 7,9G 99% /u01
/dev/mapper/vg02-lv02
1,5T 1,4T 75G 95% /u02
/dev/mapper/vg03-lv03
492G 56G 411G 12% /u03
/dev/mapper/vg04-lv04
8,9G 6,6G 1,9G 78% /u04
/dev/mapper/vg05-lv05
8,9G 3,4G 5,2G 40% /u05
resize2fs va agrandir le file system de manière transparente pour les utilisateurs. Notez bien qu’il faut utiliser le device généré par LVM /dev/mapper/vg05-lv05 au lieu de celui géré par multipathd. /dev/mapper/mpathj.
srv01:root:/root> resize2fs /dev/mapper/vg05-lv05
resize2fs 1.41.12 (17-May-2010)
Le système de fichiers de /dev/mapper/vg05-lv05 est monté sur /u05 ; le changement de taille doit être effectué en ligne
old desc_blocks = 1, new_desc_blocks = 4
En train d'effectuer un changement de taille en ligne de /dev/mapper/vg05-lv05 vers 12845056 (4k) blocs.
Le système de fichiers /dev/mapper/vg05-lv05 a maintenant une taille de 12845056 blocs.
On vérifie avev la commande df que le file system a bien la taille désirée.
srv01:root:/root> df -h /dev/mapper/vg05-lv05
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
/dev/mapper/vg05-lv05
49G 3,4G 43G 8% /u05
Si vous avez des questions ou un commentaire à faire, n’hesitez pas à laisser un message ci-dessous. Si vous avez aimé cet article, vous pouvez
le partager avec vos followers
ou bien
me suivre sur Twitter!
23 Nov 2015
Je vous propose de détailler le fonctionnement de la commande pvmove qui permet, comme son nom l’indique, de déplacer des données d’un volume physique (PV) à un autre. Cette méthode a le grand avantage de pouvoir s’exécuter à chaud. Les cas d’usages possibles sont par exemple de faciliter le remplacement d’un disque ou bien déplacer les données d’une baie SAN à une autre.
Avant de commencer à jouer avec des données de production je vous conseille fortement de réaliser des tests pour être complètement à l’aise avec les commandes LVM. Faire une sauvegarde pourrait être aussi une bonne idée !
Vous aurez deviné que la commande pvmove n’est utilisable que si votre stockage est géré par LVM. Si vous n’êtes pas famillier avec ces notions, il existe une multitude d’articles sur le sujet.
Configuration du serveur de test
Pour les besoins de la démonstration j’utilise une machine virtuelle sur laquelle j’ai installé une CentOS 7.1. Les données sont stockées sur le device /dev/sdb qui fait partie du VG vgtest. Le but de l’opération est de tout déplacer vers un nouveau device /dev/sdc puis de supprimer /dev/sdb.
Méthodologie
Un (bon) schéma étant souvent plus parlant qu’un long texte, j’ai résumé les différentes étapes dans l’image ci-dessous:
Liste des commandes
Découverte du nouveau device cible
# for x in `ls /sys/class/scsi_host/`; do echo "- - -" > /sys/class/scsi_host/$x/scan ; done
Création d’un PV sur le nouveau device (/dev/sdc)
# pvcreate /dev/sdc
Physical volume "/dev/sdc" successfully created
Ajout du nouveau device dans le VG
# vgextend vgtest /dev/sdc
Volume group "vgtest" successfully extended
Déplacement des données de /dev/sdb vers /dev/sdc
L’argument -b permet d’exécuter la commande en tâche de fond.
# pvmove -b /dev/sdb /dev/sdc
Suivi de l’évolution de la copie des données
La colonne Cpy%Sync indique le pourcentage des données déjà déplacées.
# watch lvs -a -o+devices
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices
root centos -wi-ao---- 13.91g /dev/sda2(410)
swap centos -wi-ao---- 1.60g /dev/sda2(0)
lvtest vgtest -wI-ao---- 10.00g pvmove0(0)
[pvmove0] vgtest p-C-aom--- 10.00g /dev/sdb 7.89 /dev/sdb(0),/dev/sdc(0)
Suppression de l’ancien device /dev/sdb du VG
# vgreduce vgtest /dev/sdb
Removed "/dev/sdb" from volume group "vgtest"
Suppression du PV du device /dev/sdb
# pvremove /dev/sdb
Labels on physical volume "/dev/sdb" successfully wiped
Suppression du device /dev/sdb
# echo 1 > /sys/block/sdb/device/delete
Si vous avez des questions ou un commentaire à faire, n’hesitez pas à laisser un message ci-dessous. Si vous avez aimé cet article, vous pouvez
le partager avec vos followers
ou bien
me suivre sur Twitter!
24 Jul 2015
La préparation d’une VM Linux Centos / RHEL pour la transformer en template est une tache souvent négligée. ll n’est pas rare, après avoir déployé la VM, de pouvoir accéder aux commandes exécutées par l’administrateur lors de la préparation du template… Je ne sais pas pour vous mais je n’aime pas forcement l’idée que quelqu’un d’autre voit mes différentes tentatives pour taper correctement une commande ! Sans parler de toutes les informations qui peuvent se retrouver dans les logs…
Je vous propose donc une liste de commandes que j’utilise. Elles ont été testées sur une CentOS 6.6 minimal mais elles devraient être compatibles avec les autres ditros de la même famille (RHEL, Oracle Linux…).
Je pars du principe que l’OS est installé et qu’un accès à internet est possible pour les mises à jours avec yum. Vous verrez dans les commandes que j’ai fait le choix d’installer les VMware Tools depuis le repository VMware. Je vous invite à lire cet article pour savoir pourquoi.
J’ai scindé le script en 2 car il est nécessaire de rebooter l’OS pour prendre en compte les mises à jour.
Première partie
Deuxième partie
Après tout ça vous n’aurez plus qu’à transformer votre VM en template. Attention, si vous devez redémarrer votre VM il faudra repasser les commandes du deuxième script.
J’espère que ces informations vous aurons été utiles ! Vous pouvez vous attendre à voir un prochain article dédié à la préparation d’une VM CentOS / RHEL 7.X.
Sources
Qu’on se le dise, je n’ai aucunement la prétention d’être un gourou Linux ! La plupart des commandes présentent dans cet article proviennent de différents blogs. Malheureusement je n’ai aucune trace des noms des auteurs qui ont pu “m’inspirer”… Si vous avez des infos, n’hésitez pas à me les communiquer.
Si vous avez des questions ou un commentaire à faire, n’hesitez pas à laisser un message ci-dessous. Si vous avez aimé cet article, vous pouvez
le partager avec vos followers
ou bien
me suivre sur Twitter!
23 Jul 2015
Il existe plusieurs méthodes pour installer les VMware Tools sur un OS CentOS / RHEL 6.6. Vous pouvez les déployer soit:
- via le web client ou le viclient
- depuis un repository géré par VMware
Je préfère la deuxième méthode car l’installation et la mise à jour se font grâce aux gestionnaires de packages de votre distribution (yum, apt-get…). De plus l’empreinte sur le système est bien moins importante. Bien sûr VMware supporte officiellement cette méthode d’installation tant que l’OS est présent dans la VMware Compatibility Matrix.
La méthode présenté ci-dessous concerne bien que les version 6.X de CentOS / RHEL. A partir de la version 7.0 les packages open-vm-tools sont disponibles de base dans les repository des distribs.
Installation des clés du repository VMware
rpm --import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-DSA-KEY.pub
rpm --import http://packages.vmware.com/tools/keys/VMWARE-PACKAGING-GPG-RSA-KEY.pub
Création du fichier de configuration du repository
cat << EOF > /etc/yum.repos.d/vmware-tools.repo
[vmware-tools]
name=VMware Tools
baseurl = http://packages.vmware.com/tools/esx/latest/rhel6/\$basearch
enabled = 1
gpgcheck = 1
EOF
L’adresse indiquée dans baseurl est à modifier en fonction de votre environnement. Par exemple pour avoir la dernière version des VMware Tools pour une infrastructure vSphere 5.5 il faudra fournir l’adresse suivante:
http://packages.vmware.com/tools/esx/5.5latest/rhel6/\$basearch
yum install -y vmware-tools-esx-nox
Les packages suivants seront installés
Dependencies Resolved
==========================================================================================================
Package Arch Version Repository Size
==========================================================================================================
Installing:
vmware-tools-esx-nox x86_64 9.10.1-1.el6 vmware-tools 3.1 k
Installing for dependencies:
perl x86_64 4:5.10.1-136.el6_6.1 updates 10 M
perl-Module-Pluggable x86_64 1:3.90-136.el6_6.1 updates 40 k
perl-Pod-Escapes x86_64 1:1.04-136.el6_6.1 updates 32 k
perl-Pod-Simple x86_64 1:3.13-136.el6_6.1 updates 212 k
perl-libs x86_64 4:5.10.1-136.el6_6.1 updates 578 k
perl-version x86_64 3:0.77-136.el6_6.1 updates 51 k
vmware-tools-core x86_64 9.10.1-1.el6 vmware-tools 4.0 M
vmware-tools-foundation x86_64 9.10.1-1.el6 vmware-tools 107 k
vmware-tools-guestlib x86_64 9.10.1-1.el6 vmware-tools 62 k
vmware-tools-libraries-nox x86_64 9.10.1-1.el6 vmware-tools 4.2 M
vmware-tools-plugins-autoUpgrade x86_64 9.10.1-1.el6 vmware-tools 5.6 k
vmware-tools-plugins-deployPkg x86_64 9.10.1-1.el6 vmware-tools 44 k
vmware-tools-plugins-grabbitmqProxy x86_64 9.10.1-1.el6 vmware-tools 404 k
vmware-tools-plugins-guestInfo x86_64 9.10.1-1.el6 vmware-tools 21 k
vmware-tools-plugins-hgfsServer x86_64 9.10.1-1.el6 vmware-tools 5.7 k
vmware-tools-plugins-powerOps x86_64 9.10.1-1.el6 vmware-tools 7.3 k
vmware-tools-plugins-timeSync x86_64 9.10.1-1.el6 vmware-tools 9.8 k
vmware-tools-plugins-vix x86_64 9.10.1-1.el6 vmware-tools 97 k
vmware-tools-plugins-vmbackup x86_64 9.10.1-1.el6 vmware-tools 14 k
vmware-tools-services x86_64 9.10.1-1.el6 vmware-tools 363 k
vmware-tools-vgauth x86_64 9.10.1-1.el6 vmware-tools 429 k
Transaction Summary
==========================================================================================================
Install 22 Package(s)
Total download size: 21 M
Installed size: 64 M
Les services sont gérés par Upstart et non pas le démon init. La syntaxe à utiliser est la suivante:
status vmware-tools-services
stop vmware-tools-services
start vmware-tools-services
Si vous avez des questions ou un commentaire à faire, n’hesitez pas à laisser un message ci-dessous. Si vous avez aimé cet article, vous pouvez
le partager avec vos followers
ou bien
me suivre sur Twitter!
13 Jul 2015
Mise à jour 23/03/2016: Script modifié suite à la découverte d’un bug.
La lecture de cet article écrit par Cody Hosterman m’a amené à revoir le script PowerCLI que je vous avais présenté dans un précèdent post.
Cody y explique que le comportement de la primitive UNMAP a changé depuis les derniers patchs ESXi 5.5 (patch 3 build 2143827 pour être exacte) ainsi que dans ESXi 6.0. Ces modifications ont été apportées afin d’éviter un purple screen (sic) lorsque qu’on utilise la primitive UNMAP en changeant le nombre de blocs à réclamer. La solution proposée par VMware a été de fixer ce nombre de blocs à 1% de l’espace libre restant sur le datastore.
J’ai modifié le script pour prendre en compte le pourcentage recommandé par VMware. Vous pourrez l’executer même si vous n’avez pas la dernière version de patch. Il est bien sur fortement recommandé de mettre à jour vos serveurs ESXi.
| Le fonctionnement du script a légerement changé. Il va automatiquement choisir un des hosts qui a accès au datastore pour executer la primitive UNMAP. Le ou les datastores peuvent être indiqués avec l’argument -Datastore ou bien par le pipeline *Get-Datastore |
.\ReclaimUnusedSpace.ps1* |
Bien entendu vous trouverez le script complet sur GitHub.
Si vous avez des questions ou un commentaire à faire, n’hesitez pas à laisser un message ci-dessous. Si vous avez aimé cet article, vous pouvez
le partager avec vos followers
ou bien
me suivre sur Twitter!