Veeam : Optimisation et vérification des performances 

L’optimisation des processus de sauvegarde et de restauration avec Veeam Backup & Replication est l’une des tâches les plus difficiles après le sizing de votre plateforme.

En effet, nous avons toujours le sentiment que la sauvegarde ou la restauration est trop lente par rapport aux ressources matérielles allouées et on se pose toujours la question comment peut-on l’optimiser afin d’atteindre les performances maximales ?

Pour cela, nous avons identifié 3 pistes intéressantes pour optimiser les performances de la plateforme Veeam.

Piste 1 : Détecter les goulots d’étranglement

La première étape dans l’optimisation c’est de détecter les goulots d’étranglement. Pour cela rien de spécial à faire, Veeam pourra nous informer directement dans les statistiques des jobs où l’on trouve une analyse de tous les éléments à savoir :

• Source (Lecture des données à partir du Datastore)
• Proxy (Traitement des données notamment compression et députation)
• Network (réseau de transfert des données entre le proxy et le cible)
• Target (écriture et opération sur le repositry des sauvegardes)

Pour chaque élément nous avons un pourcentage correspondant à l’utilisation.
Ces pourcentages sont calculés d’une manière différente et indépendante et la somme sera dans la plupart des cas supérieure à 100 %.
Ces statistiques sont présentées pour tout le job, mais aussi par VM.

Source : Si nous avons un goulot d’étranglement à la source – c’est-à-dire à la lecture des données à partir du datastore, la cause est différente selon le mode de transport :

Proxy : Pour un goulot d’étranglement proxy, responsable à la lecture des données mais aussi à la compression et déduplication, c’est que le proxy arrive à lire les données rapidement à partir de la source et ne trouve pas les ressources nécessaires par la suite pour faire la compression de ces données d’où les paramètres de notre proxy doivent être vérifiés.

Réseau : Un goulot d’étranglement réseau est probablement lié à l’activité sur le réseau étant donné que le réseau est partagé avec d’autres plateformes. Ainsi idéalement, il est préférable d’utiliser un réseau dédié pour la sauvegarde BNA (Backup Network Area), c’est un canal isolé du réseau de production pour transporter les données sauvegardées.

Target : Finalement pour un goulot d’étranglement target, ceci est lié au type de sauvegarde choisi. En effet, il y a un nombre d’IOPS et des opérations créées sur le repositry comme expliqué dans le tableau ci-dessous :

Piste 2 : Vérifier votre configuration

Upload streams : On commence par la vérification des paramètres du trafic réseau surtout pour les upload streams.

Par défaut, Veeam Backup & Replication utilise le transfert de données multithread pour chaque session de sauvegarde ou de restauration.
Les données sauvegardées / restaurées qui sont transférées de la source vers la cible via 5 connexions TCP / IP.

Toutefois, si vous programmez plusieurs jobs en même temps, la charge sur le réseau peut devenir lourde et ne pourra pas supporter les connexions de transfert de données multiples,
Vous pouvez donc désactiver le transfert de données multithread ou modifier le nombre de connexions TCP / IP.

Latency control : Vérifier les paramètres des contrôles latency dans les options générales. L’intérêt de ce paramètre est de demander à Veeam d’arrêter d’assigner de nouvelles tâches à partir d’un certain seuil de latence (par défaut 20 ms).
Nous avons la possibilité de configurer Datastore par Datastore si notre licence Veeam Backup & Replication est en version entreprise Plus.

Change Block Tracking : S’assurer aussi que Veeam utilise la technologie VMware CBT (change block traking) qui permet de voir les blocs de données modifiés sans parcourir à chaque fois toute la Datastore des données.

Parallel processing : La fonctionnalité parallèle processing qui permet le traitement de job simultanément optimise les performances de l’infrastructure de sauvegarde et augmente l’efficacité de l’utilisation des ressources. Elle réduit également le temps d’exécution des jobs.

Compression Level : Les paramètres des proxys Veeam doivent être vérifiés aussi en commençant par le niveau de compression et ainsi que les nombres des taches en parallèle.

En effet, le proxy est responsable de la compression des données sauvegardées selon 5 niveaux :

1. None : Pas de compression
2. Dedupe-friendly : est un niveau de compression optimisé pour une très faible utilisation du processeur. Vous pouvez sélectionner ce niveau de compression si vous voulez diminuer la charge sur le proxy de sauvegarde (Algorithme de compression RLE)
3. Optimal : est le niveau de compression recommandée. Il fournit le meilleur rapport entre la taille du fichier de sauvegarde et le temps de la procédure de sauvegarde (Algorithme de compression LZ24)
4. High : niveau de compression +10% par rapport au niveau optimal ainsi 10x plus l’utilisation du processeur (Algorithme de compression ZLIB)
5. Extreme : est un niveau de compression qui fournit la plus petite taille du fichier de sauvegarde, mais réduit les performances de sauvegarde. Nous vous recommandons d’exécuter proxy de sauvegarde sur les ordinateurs équipés de processeurs multi-core moderne (6 cœurs recommandés) si vous avez l’intention d’utiliser le niveau de compression extrême. (Algorithme de compression ZLIB élevé)

La différence entre les différents niveaux de compression c’est le temps de traitement de vos jobs et la volumétrie des données sauvegardées.

Max Concurent Tasks : Les nombres de taches en parallèles configurés dans les paramètres du proxy veeam sont également importants à vérifier.

En effet ce paramètre correspond au nombre des taches simultanées exécuter qui correspondent au nombre des cores du CPU de votre proxy.
Par exemple dans le cas où on a un serveur configuré avec 2 processeurs 6 cores au total 12 cores d’où 12 taches simultanées.

Si on dépasse le nombre maximal des cores, on aura un warning, mais il continue à exécuter les jobs et l’impact sera observé sur les performances de vos jobs.

Repository Target : Le repository veeam (Target) peut devenir un goulot d’étranglement, si vous limitez le débit de lecture et l’écriture de données pour un repository Microsoft Windows Server ou si on ne spécifie pas le bon serveur gateway pour un dossier de partage CIFS :

En effet, en cas d’un veeam repository server Windows veeam data mover sera informé par le service veeam pour limiter la vitesse de lecture / écriture à la valeur spécifiée lors de l’exécution d’une tache dans le cas où ce paramètre est configuré.

De plus si on limite le nombre de taches, Veeam Backup & Réplication divise le taux de la vitesse lecture / écriture autorisée entre ces tâches de façon égale.

Par exemple, vous définissez la limite de débit de données à l’option de 2 Mo/s et les taches à 2. Chaque travail traite 1 VM avec 1 VMDK. Dans ce cas, le taux d’écriture de données sera réparti entre ces 2 tâches de façon égale : 1 Mo/s pour une tâche et 1 Mo/s pour l’autre tâche.

Piste 3 : Tester les performances de la plateforme

La dernière étape c’est de vérifier les performances de votre plateforme avec des outils tiers

• Pour mesurer la vitesse de lecture des datastores, Vmware propose un outil gratuit VixDisKLib qui fait partie du VDDK Virtual Disk Development Kit de VMware
• Pour mesurer le débit réseau, le plus fiable des outils c’est Iperf
• Il est aussi intéressant aussi de lancer la vérification de performance en écriture, pour cela nous recommande l’outil DiskSpd

Au final les performances dans tous les cas sont relatives à votre plateforme Veeam et le statut des autres plateformes à l’instant de l’exécution du job.

Vous allez toujours avoir des goulots d’étranglement, mais le plus important est d’utiliser l’ensemble des ressources de votre plateforme et les optimiser au maximum afin d’obtenir la meilleure performance.