OK Computer

Agrandir un LUN présenté à un serveur Linux

2015-12-10T00:00:00+00:00

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!

Déplacer des données gérées par LVM avec pvmove

2015-11-23T00:00:00+00:00

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

Préparation d'une VM Linux CentOS / RHEL 6.6 minimal pour devenir un template

2015-07-24T00:00:00+00:00

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.

Installation des VMware Tools sur une VM CentOS / RHEL 6.6 minimal

2015-07-23T00:00:00+00:00

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

Installation des VMware Tools

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

Arrêter / Démarrer le service VMware Tools

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

Modification du fonctionnement d'UNMAP avec ESXi 5.5 et 6.0

2015-07-13T00:00:00+00:00

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.

Configurer une baie EMC VNX en ligne de commande

2015-05-27T00:00:00+00:00

Pour faire suite à l’article expliquant comment initialiser une baie EMC VNX en CLI à l’aide de l’utilitaire EMC Naviseccli, voici quelques commandes supplémentaires permettant d’aller jusqu’à la présentation des LUN aux hôtes.

Utilisation d’un fichier de sécurité

Dans un premier temps je vous conseille d’enregistrer dans un fichier de sécurité les identifiants du compte Unisphere que vous utiliserez pour configurer la baie. Cela vous évitera de retaper à chaque commande les informations d’identification. Attention, par défaut, le fichier de sécurité est stocké dans votre profil utilisateur.

Créer un fichier de sécurité pour l’utilisateur sysadmin:

naviseccli -AddUserSecurity -Scope 0 -user sysadmin -password sysadmin

Une fois fait, vous pourrez executer vos commandes naviseccli sans fournir d’identifiants.

Quelques remarques sur la syntaxe à utiliser pour Naviseccli

Pour passer une liste en argument (par exemple une liste d’IP), il suffit d’ajouter un espace entre chaque élément (192.168.1.1 192.168.1.2 etc…)
Les disques sont nommés en fonction de leur emplacement dans la baie et sous la forme numérodubus_numérodelenclosure_numéroemplacement. Par exemple si dans Unisphere vous voyez un disque référencé Bus 0 Enclosure 1 Disk 10 l’équivalent pour Navisseccli sera 0_1_10

Etapes de configuration

Passons maintenant à la configuration de la baie. Les différentes étapes seront les suivantes:

Modification des noms des SP (facultatif…)
Synchronisation du temps avec des serveurs NTP
Configuration des serveurs DNS et du domaine
Activation des statistiques (facultatif sauf si l’on souhaite par exemple utiliser EMC Monitoring & Reporting)
Configuration du FastCache (si vous avez la licence…)
Création d’un Storage Pool
Création de LUN
Création d’un Storage Group
Ajout d’un host dans un Storage Group
Ajout d’un LUN dans un Storage Group

Les différentes options des commandes seront bien sur à modifier en fonction de la configuration de votre baie (emplacement des disques) et des IP des différents serveurs de votre infrastructure (NTP, DNS).

Configuration de la baie

Modifier le nom des SP:

naviseccli -h 192.168.1.100 networkadmin -set -name vnx01spa
naviseccli -h 192.168.1.101 networkadmin -set -name vnx01spb

Attention cette commande implique un redémarrage des SP, il est préférable de modifier le nom d’un controleur à la fois.

Configuration NTP:

naviseccli -h 192.168.1.100 ntp -set -start yes -interval 45 -servers 192.168.1.3 192.168.1.4

Configuration DNS:

naviseccli -h 192.168.1.100 networkadmin -dns -set -domain domain.local -nameserver 192.168.1.1 192.168.1.2

Activation des Statistics Logging:

naviseccli -h 192.168.1.100 setstats -on

Configuration du FastCache:

La commande va activer le FastCache sur les disques indiqués via le paramètre -disks (ici 1_0_0 et 1_0_1) le mode du cache est défini par le paramètre -mode (ici en lecture/écriture) et le type de RAID est défini par le paramètre -rtype (ici RAID 1).

naviseccli -h 192.168.1.100 cache -fast -create -disks 1_0_0 1_0_1 -mode rw -rtype r_1

Création d’un storage pool:

La commande va créer un storage pool sur l’ensemble des disques indiqués via le paramètre -disks, le type de RAID est défini par le paramètre -rtype (ici RAID 5) et le nombre de disques contenus dans chaques grappe RAID est défini par le paramètre -rdrivecount (ici 5 ce qui équivaut à 4+1).

naviseccli -h 192.168.1.100 storagepool -create -disks 0_0_4 0_0_5 0_0_6 0_0_7 0_0_8 0_0_9 0_0_10 0_0_11 0_0_12 0_0_13 0_0_14 0_0_15 0_0_16 0_0_17 0_0_18 0_0_19 0_0_20 0_0_21 0_0_22 0_0_23 -rtype r_5 -rdrivecount 5 -name Pool01 -autoTiering scheduled -fastcache on

Création d’un LUN:

L’argument -type permet de spécifier si l’onsouhaite créer un LUN thin ou nonThin (Thick…). L’argument -l permet de définir l’ID du LUN. Attention, il faut bien penser à préciser la taille du LUN avec l’arguement -capacity ainsi que l’unité de mesure souhaité avec l’argument -sq (ici 1024 Go).

naviseccli -h 192.168.1.100 lun -create -type nonThin -poolName Pool01  -capacity 1024 -sq gb -name LUN01 -l 0

Création d’un Storage Group:

naviseccli -h 192.168.1.100 storagegroup -create -gname SG01

Ajout d’un host à un Storage Group:

naviseccli -h 192.168.1.100 storagegroup -connecthost -host esxi01.domain.local -gname SG01

Les hosts doivent êtres vues (zoning configuré, Unisphere Host Agent installé et configuré) par la baie avant d’êtres associés à un storage group

Ajout d’un LUN à un Storage Group:

La particularité de cette commande est que le LUN est identifié par son ID avec l’arguement -alu. l’argument -hlu permet de spécifier quel sera l’ID du LUN présenté aux hôtes.

naviseccli -h 192.168.1.100 storagegroup -addhlu -gname SG01 -hlu 0 -alu 0

Utiliser PowerCLI et la primitive UNMAP pour réclamer de l'espace libre sur des LUN thin

2015-03-26T00:00:00+00:00

Attention cet article n’est plus d’actualité, merci de jeter un oeil à celui-ci

Nous avons vu dans un article précédent comment réclamer l’espace libre en ligne de commande. Cette méthode, bien que fonctionnelle, nécessite de lancer manuellement la commande pour chaque datastore concerné.

Afin d’automatiser le process, je vous propose d’utiliser PowerCLI:

L’idée est de réclamer l’espace libre sur tous les datastores disponibles depuis le serveur ESXi passé en argument -VMHost. La taille du fichier asyncUnmapFileSize est définie en fonction de l’espace libre restant sur le datastore et un pourcentage qui par défaut est de 50% mais qui peut aussi être passé en argument -asyncUnmapFilePourcentage. Il est possible de préciser sur quel datastore on veut exécuter le script grâce à l’argument -Datastore.

Vous trouverez le script complet sur GitHub.

Initialiser une baie EMC VNX en ligne de commande

2015-02-27T00:00:00+00:00

Attention cette procédure ne s’applique qu’aux baies VNX block !

Tous ceux qui ont déjà installé une baie EMC VNX savent que l’outil d’initialisation fournie par EMC (EMC Storage System Initialization) est plutôt capricieux. Réussir à lui faire découvrir la baie sans avoir recours à un switch dédié peut parfois s’avérer compliqué.

Pour contourner ce problème je préfère maintenant initialiser la baie en ligne de commande avec l’outil NaviSecCLI (téléchargeable sur le site support d’EMC). Les 2 contrôleurs ont une IP par défaut qui peut être utilisée pour configurer la baie:

SPA: 1.1.1.1/24
SPB: 1.1.1.2/24
Utilisateur: sysadmin
Mot de passe: sysadmin

La marche à suivre est plutôt simple, il est d’abord nécessaire de mettre son poste de travail dans le même sous réseau que la baie (prendre par exemple l’IP 1.1.1.3) puis de suivre la procédure suivante:

Vérifier que la baie est bien joignable sur les 2 IP

naviseccli -h 1.1.1.1 -user sysadmin -password sysadmin -scope 0 networkadmin -get
naviseccli -h 1.1.1.2 -user sysadmin -password sysadmin -scope 0 networkadmin -get

Vérifier que la baie ne remonte aucune erreur sur les 2 contrôleurs

naviseccli -h 1.1.1.1 -user sysadmin -password sysadmin -scope 0 faults -list
naviseccli -h 1.1.1.2 -user sysadmin -password sysadmin -scope 0 faults -list

Vérifier qu’aucun domaine n’a déjà été configuré

naviseccli -h 1.1.1.1 -user sysadmin -password sysadmin -scope 0 domain -list
naviseccli -h 1.1.1.2 -user sysadmin -password sysadmin -scope 0 domain -list

Initialiser le domaine en créant un utilisateur (ici sysadmin)

naviseccli -h 1.1.1.1 -user sysadmin -password sysadmin -scope 0 security -adduser -user sysadmin -password sysadmin -scope 0 -role administrator -type system

Configurer l’adresse IP cible du SPA

naviseccli -h 1.1.1.1 -user sysadmin -password sysadmin -scope 0 networkadmin -set -ipv4 -address 192.168.1.1 -subnetmask 255.255.255.0  -gateway 192.168.1.254

Configurer l’adresse IP cible du SPB

naviseccli -h 1.1.1.2 -user sysadmin -password sysadmin -scope 0 networkadmin -set -ipv4 -address 192.168.1.2 -subnetmask 255.255.255.0  -gateway 192.168.1.254

Une fois toutes ces opérations réalisées avec succès, vous devriez être en mesure de vous connecter à la baie avec Unisphere. Il ne vous restera plus qu’à finaliser la configuration en spécifant par exemple les serveurs DNS et NTP.

Récupérer de l'espace libre sur des LUN thin avec VMware ESXi et UNMAP

2015-02-26T00:00:00+00:00

VMware a introduit avec la version 5.0 une nouvelle primitive VAAI (UNMAP) qui permet, dans le cas de LUN en thin provisionning, de réaffecter les blocs qui ne sont plus utilisé à l’espace libre. Le but étant de conserver les bénéfices du thin provisionning dans le temps.

En version 5.0, l’invocation de cette primitive était gérée automatiquement par les ESXi mais des problèmes de performance ont poussé VMware à la désactiver. Elle a été de nouveau disponible dans la version 5.0 U1 cependant l’exécution est maintenant manuelle. L’efficacité de la primitive a été améliorée dans la version 5.5.

Le fonctionnement de la primitive est plutôt simple, elle va écrire des 0 sur les blocs qui ne sont plus utilisé par le datastore. Ensuite ce sera à la charge de la baie de stockage de réaffecter ces blocs à l’espace libre.

###Ma baie est-elle compatible avec la primitive ?

Outre le fait que la baie doit être compatible VAAI (ce qui est le cas de toutes les baies SAN récentes) il faut en plus qu’elle supporte la primitive UNMAP. Il est possible de le vérifier pour chaque datastore avec les commandes esxcli suivantes:

esxcli storage core device list | more (noter le uid naa.)
esxcli storage core device vaai status get -d <naa ID> (Vérifier la présence de ligne Zero Status: Supported)

###Quand et pourquoi utiliser cette fonctionnalité ?

Et bien ça dépend… Sur des datastores avec des VM de production il est rare que la volumétrie soit amenée à beaucoup varier. Réclamer l’espace libre sur ce type d’environnement sera certainement une perte de temps. Là ou on pourra y voir un plus grand intérêt c’est dans le cas des environnements de test/dev ou plus généralement quand le contenu des datastores évolue régulièrement.

###VMware ESXi 5.0 U1 et 5.1:

Avec un ESXi en version 5.0 U1 ou 5.1 il faut utiliser la commande vmkfstools:

Se connecter en SSH sur l’ESXi et se positionner sur le datastore concerné

cd /vmfs/volumes/nomdudatastore

Exécuter la primitive

vmkfstools -y 60

####Remarques:

La commande vmkfstools crée un fichier temporaire (.vmfsBalloon+suffix) dans lequel tous les blocks récupérés seront stockés avant d’êtres remis à zéro, le paramètre -y 60 indique que 60% des blocks libres seront remis à zéro, cela implique que le datastore devra disposer de suffisamment d’espace disque libre pour effectuer cette opération. En cas de doute, relancer la commande plusieurs fois avec un % inférieur.
L’exécution de la primitive peut générer beaucoup d’I/O et de l’utilisation CPU, VMware recommande de réaliser ces opérations hors production.

###VMware ESXi 5.5

La commande vmkfstools n’est plus supportée depuis la version 5.5, elle a été remplacée par une commande esxcli:

Se connecter en SSH sur l’ESXi et exécuter la primitive

esxcli storage vmfs unmap -l nomdudatastore -n nombredeblocks

####Remarques:

La commande crée un fichier temporaire (.asyncUnmapFile) mais, à la différence des versions précédentes, la taille du fichier est définie par la valeur du paramètre -n (en Mo)
Une seule exécution de la commande est nécessaire pour libérer l’ensemble des blocks non utilisés
HP recommande de spécifier une valeur importante pour le paramètre -n afin de réduire la durée d’exécution de la primitive
VMware indique que la primitive peut être utilisée pendant les heures de production, il est quand même nécessaire de réaliser des tests au préalable.

###Sources:

####VMware ESXi 5.0 U1 et 5.1:

KB VMware

Jason Boche - Starting thin and staying thin with VAAI Unmap

####VMware ESXi 5.5: Jason Boche - vSphere 5.5 UNMAP Deep dive