Temps de lecture estimé: 4 minutes
Comme annoncé précédemment dans mon article pour améliorer les performances de mon serveur web, j’avais dans ma todo la mise en place d’un disque dur SSD dans mon serveur Vmware Esxi pour faire tourner la machine virtuelle du serveur web.
Installation Physique dans le Mac Mini
Bon, pour mettre un SSD dans un mac, il faut bien entendu un disque dur SSD.
Dans mon cas un simple Sandisk 480go.
J’ai voulu l’installer le jour où je l’ai reçu. Mais c’était avant de m’apercevoir qu’il me manquait quelque chose.
Mais si, tu sais, cette pièce que j’avais décidé de jeter en me disant que de toute façon je ne remettrais jamais de disque dans mon mac…
Le connecteur Sata nécessaire dans les machines Apple et pour mon Mac mini. J’ai dû en recommandé un nouveau…
Bon! Une fois reçu, j’ai pu l’installer dans le Mac (détaillé pas à pas dans cet article ou en vidéo).
Création d’un nouveau vmfs pour Vmware Esxi 7.0
Maintenant qu’il est installé, il suffit ensuite de créer un datastore / un vmfs . on peut le faire de 2 manières:
l’option facile depuis l’interface
L’option en ligne de commande:
D’abord, j’identifie le nouveau disque dur:
esxcli storage core path list
Ce qui me donne:
sata.vmhba0-sata.0:1-t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________
UID: sata.vmhba0-sata.0:1-t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________
Runtime Name: vmhba0:C0:T1:L0
Device: t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________
Device Display Name: Local ATA Disk (t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________)
Adapter: vmhba0
Channel: 0
Target: 1
LUN: 0
Plugin: NMP
State: active
Transport: sata
Adapter Identifier: sata.vmhba0
Target Identifier: sata.0:1
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 33554432
usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
UID: usb.vmhba32-usb.0:0-mpx.vmhba32:C0:T0:L0
Runtime Name: vmhba32:C0:T0:L0
Device: mpx.vmhba32:C0:T0:L0
Device Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
Adapter: vmhba32
Channel: 0
Target: 0
LUN: 0
Plugin: NMP
State: active
Transport: usb
Adapter Identifier: usb.vmhba32
Target Identifier: usb.0:0
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
Maximum IO Size: 32768
Dans mon cas c’est assez explicite. Ça me permet assez facilement de l’identifier dans le dossier /vmfs/devices/disks/ avec:
ls /vmfs/devices/disks/
Puis ça me permet de récupérer le secteur de début et de fin du disque, ce qui va me servir à créer une partition:
partedUtil getptbl "/vmfs/devices/disks/t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________"
58369 255 63 937703088
J’ai toutes les infos pour calculer le secteur de fin pour créer une partition. Je me suis aidé de l’étape 7 d’un article sur virten.net. Donc, dans mon cas:
58369 * 255 * 63 -1 = 937697984
Je crée la table des partitions:
partedUtil setptbl "/vmfs/devices/disks/t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________" gpt "1 2048 937697984 AA31E02A400F11DB9590000C2911D1B8 0"
Et une fois que la partition est créée, on peut créer le Datastore vmfs au format vmfs6 avec des blocs de 1M sur l’unique partition :1 créé ci dessus :
vmkfstools -C vmfs6 -b 1M -S VM-Store-SSD /vmfs/devices/disks/t10.ATA_____SanDisk_SSD_PLUS_480GB__________________2013E0446615________:1
Voilà!! un Datastore tout neuf sur lequel je vais pouvoir déplacer mes machines virtuelles.
Déplacement des machines virtuelles
Ce qu’il ne faut pas faire:
J’ai ensuite fait quelque chose que je n’aurais pas du faire… J’ai déplacé la VM du 1er Datastore au SSD avec un simple mv:
mv /vmfs/volumes/VM-Store/[VM-Store\]\ Ubuntu\ Web\ Server/ /vmfs/volumes/VM-Store-SSD/[VM-Store\]\ Ubuntu\ Web\ Server/
et bien cette étape m’a valu quelques frayeurs et une galère.
J’ai été offline 2 gros jours parce qu’en déplaçant la VM:
J’ai eu des coupures => J’ai recommencé plusieurs fois => J’ai perdu des fichiers vmdk
Easy!! Je me suis dit: “ce n’est pas grave j’ai une solution de Backup exprès pour ça!” C’est donc là que je me suis aperçu que depuis mon passage à Esxi 7, ma solution de backup journalière Nakivo Backup n’était plus compatible… Donc, pas de backup depuis le 17 / 04.
J’ai fait plusieurs tentatives de récupération de fichier, de régénération de vmdk sans succès…
Bon, cette histoire se finit (quand même) bien puisqu’au final, je me suis rappelé que je pouvais utiliser ma sauvegarde journalière du NAS ( dans laquelle il y a le Datastore Esxi , dans lequel il y a la VM..) … ouf!!!
Donc cet aparté pour dire que j’aurai dû copier la vm et m’assurer que tout va bien avant de supprimer l’ancienne.
Ce qu’il faut faire:
Une fois le backup récupéré et fonctionnel, j’ai tout d’abord consolidé les disques vmdk de la machine virtuelle via l’interface web.
Niveau perf, c’est pas fou, 8h de consolidation de 10 snapshots d’un disque de 200go:
Après cette longue attente, j’ai ensuite cloner le vmdk fraîchement consolidé. Ce qui m’a pris encore quelques longues minutes heures.
vmkfstools -i /vmfs/volumes/VM-Store/old.vmdk -d thin /vmfs/volumes/VM-Store-SSD/new.vmdk
et pour finir, j’ai recréé une nouvelle VM en utilisant le nouveau disque cloné.
Toute cette aventure pour la promesse de meilleure performance.
Pour une consolidation de disque, je n’ai pas testé avec de gros changements, mais le SSD ne pourra pas être pire que les 8 heures en NFS sur le NAS.
Pour le démarrage du serveur sous Ubuntu 20.04, je n’ai pas de chiffre précis mais j’ai noté de grandes améliorations. Je suis passé de plusieurs minutes de démarrage à quelques secondes.
Et pour prende un snapshot du disque de la machine, je suis passé de 3min en moyenne avant le SSD à 1min 10s après.