Bonjour,
Le VMFS ou Virtual Machine File System a été développé dès le début, par VMware, afin d’offrir un système de fichier de cluster.
Il permet de gérer les lock sur les fichiers, tout en offrant la possibilité de partager son espace de stockage à une multitude d’hyperviseur, en même temps.
En version VMFS-1 et VMFS-2, il n’y avait pas de gestion des dossiers, ce qui faisait que les disques virtuels ou fichiers VMDK, étaient tous ensembles.
Afin d’améliorer la gestion des VMs, ils ont rajouté la possibilité de créer des dossiers avec le VMFS-3.
C’est également, dans cette version, que la création des Thin disque a été possible.
Une des grandes forces de ce système de fichier est sa gestion des blocks.
Par le passée, on formatait le VMFS selon la taille maximum des fichiers à poser dessus.
1MB block size = 256GB taille de fichier max
2MB block size = 512GB taille de fichier max
4MB block size = 1024GB taille de fichier max
8MB block size = 2048GB taille de fichier max
Mais même avec un VMFS de 8MB de block size, il était possible de poser des fichiers de petites tailles, telles que le fichier VMX (quelques KB), sans faire de gaspillage.
VMware avait mis en place un système de sub-block dans le VMFS, de 64KB.
L’arrivée du VMFS-5 a passablement révolutionné cette partie.
Il n’existe plus qu’un seul block-size de 1MB, permettant de poser des fichiers allant de 512 B à 2 TB et le sub-block a été diminué à 8KB.
La taille maximum d’un VMFS-5 a passé à ~64TB avec le passage en GPT (GUID Partition Table) pour la gestion du système de fichier.
Contrairement aux versions précédentes, ils est possible d’upgrader le VMFS-3 en VMFS-5, mais attention aux effets de bord :
- Le VMFS-5 continue d’utiliser l’ancien block size et sub-block size.
- La table de partition reste en MBR (Master Boot Record), jusqu’à ce que la partition dépasse les 2 TB, c’est à ce moment-là qui migre la table en GPT, d’une manière transparente.
- Le VMFS reste aligné à 128 kB alors que le VMFS 5 est aligné à 2048 kB.
Je pense qu’il est vivement conseillé de recréer de nouveaux datastores, formatés en VMFS 5 et d’utiliser le storage vMotion, pour vider les anciens , afin de les reformater.
Concernant le Storage vMotion, un des gros avantages du système mono block est de pouvoir utiliser en toutes circonstances le VAAI (vStorage API Array Intergration).
Cette fonctionnalité est apparue avec la version vSphere 4.1 et elle permet d’offloader les migrations de VMs, dans la baie de stockage (cf mon article Le VAAI et les primitives).
En effet, si les blocks du VMFS est de tailles différentes, il faut revenir au modèle de migration conventionnel. (cf article de Stéphane Le storage vMotion hier et aujourd’hui).
Derniers points :
- Les fichiers posés sur le VMFS-5, plus petits que 1KB, seront stocké directement dans les metadata.
- Les RDM (Raw Device Mapping) pourront être de tailles supérieures à 2 TB et au maximum 64 TB.
- Le VMFS-5 supporte jusqu’à plus de 100 000 fichiers
Ce changement d’architecture va apporter beaucoup de souplesse à la gestion des espaces de stockage et certainement va modifier les best practices liés aux tailles des datastore.
Bonne migration !