VMware recommande de ne pas utiliser un snapshot plus de trois jours. La raison principale qui est évoquée est liée à l’utilisation de l’espace disque ; en effet, une machine active peut rapidement générer un très gros snapshot, potentiellement aussi gros que le disque d’origine.
Mais si on lit entre les lignes, on voit aussi qu’il y a potentiellement un problème de performance. Dans cet article nous allons réaliser un petit test pour évaluer l’impact de performance d’un snapshot sur une machine très active niveau disque.
Vous pourriez être surpris !
Précisons les conditions du test. Nous sommes en vSphere 5.5u1, la VM est sous 2008 R2. Dans la VM, sur un disque dédié de 100 Go, nous exécutons IOmeter et mesurons les performances du pattern suivant : blocs de 32k, 80% read, 90% random. Nous testerons avec deux baies de stockage : une Storwize V7000 full SAS, et une autre V7000 disposant de SAS + tiering SSD pour détecter d’éventuelles différences.
Nous commençons par laisser tourner le test pour générer des données de performance initiale. Au bout de quelques minutes, nous faisons un snapshot, puis nous mesurons les performances à nouveau. Enfin, au bout de quelques minutes, nous consolidons le snapshot et mesurons les performances pendant cette consolidation. A l’issue de ces manipulations, nous effectuons une nouvelle mesure de performance.
Baie full SAS
| IO/s | V7000 full SAS |
|---|---|
| Situation intiale | 2450 |
| Perf avec snapshot | 300 |
| Perf pendant consolidation | 180 |
| Situation après consolidation | 2650 |
Pendant le snapshot, les performances disque de la VM ne sont que de 12% des performances initiales, et on atteint 7% pendant la consolidation ! Voici à quoi ressemblent les performances disques depuis l’analyseur de performance du vCenter.
Le snapshot est pris vers 3:22 et les performances se dégradent rapidement jusqu’à atteindre un plateau. Vers 3:35 la consolidation démarre. Les performances semblent augmenter, mais les I/O qu’on voit sont en fait les I/O liées à la consolidation des données dans le .vmdk original. Dans la VM, les performances baissent encore. Vers 3:40, la consolidation est terminée et les performances sont immédiatement bonnes à nouveau (même légèrement meilleures, mais cela n’est pas à attribuer au snapshot). On pourra également remarquer également l’accroissement significatif de la latence disque (en gris clair) durant le snapshot.
Baie SAS + tiering SSD
Reproduisons le test avec une V7000 disposant de disques SAS et de SSD tiering. Les données “chaudes” sont montées sur les SSD selon un cycle de 24 heures. Ainsi, pour notre test, nous avons laissé tourner IOmeter pendant cette durée, les données du disque soumis au test sont donc chaudes ; sur les SSD. En revanche, les nouveaux blocs écrits sur le .vmdk temporaire du snapshot vont aller sur les disques. On s’attend à un écart de performance plus élevé encore… Et en effet :
| IO/s | V7000 SAS + SSD tiering |
|---|---|
| Situation initiale | 11500 |
| Perf avec snapshot | 420 |
| Perf pendant la consolidation | 300 |
| Situation après consolidation | 11500 |
Cette fois-ci lorsque le snapshot est actif nous n’avons même plus 4% des performances initiales (3,65%). Et on tombe à 2,6% durant la consolidation ! Le graphique côté vCenter est plutôt explicite aussi :
Ici aussi, on identifie facilement la chute de performance rapide au moment de la prise du snapshot (vers 3:55), suivie du plateau à 420 IO/s. Lors de la consolidation, on observe à nouveau une hausse lente de la courbe liée à la résorption du snapshot, mais on se rappelle que dans la VM, les performances sont encore dégradées. Puis, vers 4:13, l’opération est terminée et on retrouve instantanément les performances initiales.
Bilan
Quels enseignements tirer de tout cela ? Il y en a plusieurs.
- L’impact de performance des snapshots est largement sous-estimé. Nous avons vu un cas particulier où nous n’avions plus que 3% des performances initiales ! Même si notre test est extrême et a été pensé pour mettre en évidence le phénomène, une machine intensive dans ses accès disque sera toujours très fortement pénalisée par la présence d’un snapshot. Il faut en avoir conscience dans la gestion de son environnement et n’utiliser les snapshots qu’en connaissance de cause.
- L’utilisation de baies de disques mixtes avec un dispositif de “tiering” automatique des données chaudes selon un cycle lent montre ici ses limites : les données de snapshot atterriront toujours en premier sur des disques SAS, aggravant considérablement l’impact de performance (en pourcentage) par rapport aux disques d’origine. C’est d’autant plus gênant que les données chaudes sont justement celles qui ont besoin de performance ! On privilégiera donc des systèmes soit full SSD, soit qui utilisent les SSD en write cache, avec une écriture différée sur les disques SAS uniquement pour des données froides.
- Le mécanisme de snapshot étant utilisé universellement par les outils de backup, cette baisse de performance importante peut causer des problèmes lors de la sauvegarde de machines générant beaucoup d’accès disque en continu (outils de collecte de données…), en créant une situation où les IO/s disponibles dans la VM ne suffisent pas à absorber les données à écrire par le système. Le tarif ? Machine plantée et consolidation impossible.
Bien entendu, on ne s’interdira pas l’utilisation des snapshots ; cela reste quand même irremplaçable ! Mais la gestion des snapshots, qui n’a pas vraiment évolué ces dernières années, mérite certainement un petit coup de jeune. Et ça tombe bien, vSphere 6 arrive avec de grosses améliorations niveau snapshot, paraît-il. Ce qui vous fera une première bonne raison de préparer la migration ! 🙂