Bonjour à tous, le thème du jour Windows Server 2016 ReFS v3 et Veeam Backup & Replication 9.5.
Vous allez me dire : “Gatien, tu es en retard ReFS existe depuis Windows Server 2012R2, rien de bien nouveau par ici”, et bien si! Mais commençons bien, ReFS c’est quoi?
ReFS : Resilient File System, un système de fichier basé sur des metadata et non plus une table de fichiers. Microsoft espère que d’ici à 8ans ce système de fichiers remplacera NTFS, quand on connait le temps qu’il a fallu à NTFS pour remplacer FAT32, cela ne va pas être simple!
Parlons des améliorations de ReFS v3 plutôt que de l’ensemble des changements!
ReFS proposait déjà une fonctionnalités permettant de détecter et corriger les blocs corrompus, Integrity Streams. Le problème majeur était l’énorme perte de performance induite par ces contrôles d’intégrités réguliers et notamment avec Hyper-V par exemple, totalement refondue et repensée elle est beaucoup plus efficace désormais. Cette résilience est calculée par un procédé “Allocation On Write” des metadatas, permettant d’allouer les blocs à chaque nouvelle écriture. La finalité : dans le cas de corruption d’un fichier et de ses metadatas, le fichier peut être supprimé sans inquiétudes que ce soit l’ensemble du volume qui soit corrompu.
Mais la principale nouveauté qui nous intéresse dans le cadre de la virtualisation et du backup c’est le “Disk Block Cloning”, intégré dans ReFS v3. Cette fonctionnalité permet un cloning des metadatas, ce qui ne nécessite aucunes opération de déplacements tant qu’une nouvelle écriture n’est pas effectuée, cette opération est connue dans d’autres sytèmes et plus communément appelée appelée copy-on write. Conséquence ? La création et la suppression d’un snapshot est quasi instantanée et permet donc une amélioration des performances et un impact quasi-nul lors d’opérations nécessitant la manipulation de données existantes. Ceci est particulièrement intéressant dans le use case qui nous intéresse.
Et Veeam dans tout ça? Veeam supporte officiellement le ReFS v3 dans sa version 9.5 qui sortira courant Novembre. Pré-requis, un serveur B&R sous 9.5, les repository doivent être installés en Windows Server 2016 et formatés en ReFS bien sûr. Les personnes utilisant VEEAM et les différents modes de backup vont tout de suite comprendre l’intérêt de ce FileSystem.
Côté VEEAM, l’utilisation de ReFS permet une fonctionnalité appelée Spaceless Full Backup Technology, qui permet à plusieurs backup Full résidant sur le même repository de partager les mêmes block de données, ce qui se traduit par une utilisation moindre de la capacité de stockage, à la manière de certaines appliances de déduplication.
La méthode en Forward Incremetal-Forever. On commence par un backup Full puis chaque jour une incrémentale. Au bout du cycle de rétention, la Full absorbe le premier incrément effectué, ainsi de suite. Exemple avec 3 points de rétention :
La méthode en Reverse Incremental. On commence par un backup Full puis chaque jour, la Full absorbe l’incrément et laisse derrière elle un incrément avec les anciennes versions des blocs modifiés. Vous avez donc toujours la Full en dernier point. Puis on supprime les incréments inutiles. Exemple avec 4 points de rétention :
Passons maintenant à notre intérêt de ReFS v3. Plusieurs tests ont été effectués par un bloggeur, architecte de métier, les tests sont très intéressants, je cite :
La source de données du backup est d’environ 435GB dont 300Gb utilisés, la taille du backup FULL est de 120GB après compression. Pour ces tests, la fonctionnalité Per-VM Backup File est activée (ce qui permet la création de fichiers uniques pour chaque VM au lieu d’un seul fichier d’archive). Le taux de change est d’environ 100GB bruts par jour, 25-30GBdans les fichiers incrémentiels après compression et dé-duplication. Matériel et VMs sont les mêmes bien sur pour tous les tests. Quatre repository de destinations ont été testés :
NTFS — Forward Incremental
NTFS — Reverse Incremental
ReFS — Forward Incremental
ReFS — Reverse Incremental
Les performances des FULL, dans les 4 cas ont été similaires sans surprises, avec ReFS 3 à 5% plus lent mais les nombreux tests lancés ont présentés une variation, cela est donc mineur. Les temps des backup incrémentiels sont en revanche bien plus intéressants sur les 7 jours qui ont suivis et donne un aperçu des différences de performances. Le temps de prise de snapshot est séparé du temps de backup sur les jobs incrémentiels afin de les différences avec les temps de prises de snapshot.
rencontre black à livry gargan All Jobs
Average Data Read/day: ~90GB
Average backup size/day: ~30GB
Worst case was a change rate of nearly 135GB
incontri coppie per singoli NTFS — Forward Incremental
Average time to backup all 7 VMs/day: ~11min (worst case was ~20 min)
Average merge time/day: ~24min (worse case was ~44 min)
Average total time/day: ~35min
rencontre trans sur vallauris NTFS — Reverse Incremental
Average time to backup all 7 VMs/day: ~45min (worst case was ~70 min)
ReFS — Forward Incremental
Average time to backup all 7 VMs/day: ~11min (worst case was ~20 min)
Average merge time/day: ~2m: (worse case was ~3 min)
Average total time/day: ~13min
ReFS — Reverse Incremental
Average time to backup all 7 VMs/day: ~13min (worst case was ~20 min)
Comme vous pouvez le voir, même avec une petite infrastructure de démonstration, les process de Reverse Incremental ont été 3,5x plus rapide en ReFS vs NTFS, et ce avec le même stockage sous-jacent, ce qui est est plutôt impressionnant. Cela est d’autant plus bénéfique avec l’utilisation de stockage formaté en RAID6, les performances d’écriture séquentielle étant encore meilleure.