Avamar : Comportement et théorie relatifs aux performances de sauvegarde

L’objectif de cet article est de décrire ce qui se passe lors d’une sauvegarde Avamar, dans le but d’aider le lecteur à comprendre le comportement des performances de sauvegarde.

Cet article accompagne les articles suivants :

• Avamar : Dépannage des performances de sauvegarde lentes
• Avamar : Réglage des sauvegardes pour qu’elles se terminent rapidement

Que se passe-t-il lors d’une sauvegarde Avamar ?

Le processus de sauvegarde avtar :

1) Charge les fichiers et les fichiers du cache de hachage dans la mémoire

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) Crée des snapshots VSS (sous Windows) :

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Parcourt tous les fichiers définis par le jeu de données Pour tous les fichiers du jeu de données source, avtar prend le chemin complet et le combine avec les métadonnées de type statistique pour calculer un hachage afin d’identifier le fichier de
manière unique.

Pour plus d’informations, consultez Avamar : Que se passe-t-il lorsque avtar lit un fichier pendant la phase d’analyse des fichiers.

4) Comparer les hachages calculés avec ceux des caches des clients locaux Avtar recherche le hachage du fichier dans le cache de fichiers

. Il vérifie s’il s’agit d’une nouvelle sauvegarde ou si elle a été modifiée depuis la sauvegarde précédente.

Si la recherche dans le cache de fichiers réussit, le fichier existe et n’est pas modifié.

Si la recherche échoue, le fichier est nouveau ou a été modifié. Elles doivent être lues et traitées.

Pour plus d’informations, consultez Avamar Client - What needs change before avtar consider a file as been modified ?

5) Traiter les nouveaux fichiers et les fichiers modifiés

Pour tout fichier nouveau ou modifié, avtar doit :

• Lire l’intégralité du fichier
• Divisez-le en morceaux de taille variable
• Compression de chaque fragment
• Calculer un hachage pour chaque fragment

6) Vérifiez si des hachages manquants sont présents sur l’instance d’Avamar Server.

Avtar envoie les données des hachages manquants sur le réseau à l’instance d’Avamar Server pour vérifier s’ils existent déjà. C’est ce que l’on appelle les demandes

« ispresent ».7) Les données sont écrites sur l’instance d’Avamar Server (et, le cas échéant, sur Data Domain). 

Pour plus d’informations sur le workflow, reportez-vous au Avtarprocess.pdf joint.


Présentation d’une sauvegarde Avamar du point de vue des performances :

En prenant les étapes ci-dessus, nous les divisons en « phases » ayant le plus grand impact sur les performances de sauvegarde : Phase

0. Créez des snapshots VSS.

Le service VSS (Volume Shadowcopy Service) crée des snapshots des volumes spécifiés dans le jeu de données source. Les applications peuvent continuer à écrire sur le volume pendant l’exécution de la sauvegarde.
Avamar sauvegarde le snapshot « figé » en lecture seule du volume plutôt que le volume inscriptible. Cela garantit qu’il dispose d’un ensemble cohérent de données à sauvegarder.

Les snapshots VSS prennent quelques secondes. Si un client rencontre des problèmes VSS, cela retarde ou empêche la poursuite de la sauvegarde.

Étape 1. Phase d’analyse des fichiers. Le processus avtar établit une statistique sur tous les fichiers du jeu de données

ciblePour les clients disposant de millions de fichiers, cette phase peut être la plus longue.
Les données de la base de données contiennent peu de fichiers volumineux, de sorte que la phase d’analyse des fichiers prend peu de temps. Les clients de base de données consomment généralement leur temps pendant la phase #2.

Pour un client avec disques rotatifs en configuration RAID 5, des performances d’analyse de fichiers de ~1 million de fichiers par heure sont standard. Cela varie de 300 000 à 3 millions par heure. Cela dépend de l’environnement du client et des caractéristiques des données sauvegardées.

À partir de la version 7.3, les clients Linux qui sauvegardent sur Data Domain peuvent tirer parti de la fonctionnalité Linux Fast Incremental (LFI). Cela évite d’analyser l’ensemble du jeu de données à chaque exécution de la sauvegarde.

Ressources critiques : performances de recherche aléatoire du disque sur lequel les données de sauvegarde sont stockées.

Étape 2. Avtar lit les fichiers modifiés, puis fragmente, compresse et hache les données.

De nombreux calculs sont effectués au cours de cette phase. Pour chaque fichier modifié ou nouveau, avtar le divise en petits morceaux. Il compresse chaque fragment et calcule un hachage sous la forme d’une « empreinte digitale » pour identifier le fragment.

Les fichiers des sauvegardes de base de données sont souvent volumineux et ont tendance à changer quotidiennement. Avtar passe la plupart de son temps dans cette phase. Il est préférable d’utiliser les plug-ins de base de données Avamar officiels pour gérer la base de données efficacement, en tirant parti de la fonctionnalité de sauvegarde incrémentielle, des fichiers log des transactions, etc.

Les performances de traitement des fichiers sont généralement d’environ 100 Go par heure, mais peuvent varier jusqu’à 300 Go par heure. Cela dépend de l’environnement.

Ressources stratégiques : Disque et processeur

client Pour les sauvegardes LAN où il n’y a pas de goulot d’étranglement dans l’envoi des données à Avamar Server, les phases #1 et #2 prennent le plus de temps.

Dans le graphique suivant, tenez compte du fait que la surface dans les barres du graphique correspond à la durée de la sauvegarde. Les fichiers modifiés peuvent augmenter considérablement le temps nécessaire, en particulier s’ils sont volumineux.

Pour les jeux de données de système de fichiers, attendez-vous à ce que ~0 à 3 % des fichiers changent quotidiennement.

Avtar doit 'stat()' chaque fichier qui change en effectuant deux opérations d’E/S, l’une pour vérifier les attributs du fichier, l’autre pour les attributs de sécurité.

Pour atteindre le taux d’analyse de référence de ~1 million de fichiers/heure pour les sauvegardes du système de fichiers, avtar nécessite environ deux millions d’opérations de recherche par heure, soit 600 opérations de recherche par seconde.

Par exemple : Si une sauvegarde a un taux de modification de 3 %, 97 fichiers sur 100 nécessitent des opérations de recherche de deux disques afin d’identifier s’ils ont été modifiés. Les trois autres qui ont changé doivent être analysés, découpés en morceaux, compressés et hachés.

Cela ne prend en compte que la phase d’analyse des fichiers et ne prend pas en compte les ressources d’E/S requises pour traiter les fichiers qui ont été modifiés.
Plus il y a de données dans les fichiers modifiés, plus le travail nécessaire pour terminer la sauvegarde est important.

Étape 3. Vérification de l’existence de hachages sur l’instance d’Avamar Server

Les phases #1 et #2 produisent des hachages qui pointent vers des éléments de la sauvegarde. Il peut s’agir de fragments de fichiers uniques, de systèmes de fichiers ou de sauvegardes complètes.

Les hachages sont écrits dans les fichiers de cache du client et comparés aux hachages présents sur Avamar Server pour vérifier si de nouvelles données doivent être ajoutées. Cela s’applique qu’un serveur Avamar ou un Data Domain soit le stockage cible.

Les comparaisons de hachage entre le client et le serveur Avamar sont généralement rapides. Ils ne doivent pas goulet d’étranglement la sauvegarde si l’instance d’Avamar Server est :

• Sain
• Sous des niveaux de charge réguliers
• Situé sur le même segment LAN que le client

Étant donné que les hachages ne font que 20 octets, cette phase est davantage influencée par la latence réseau que par la bande passante réseau. Lorsque le hachage arrive sur Avamar Server, la charge générale et les performances de recherche aléatoire du sous-système de disque des nœuds de données déterminent la rapidité avec laquelle le hachage est récupéré et comparé à celui envoyé par le client.

Ressources stratégiques : Temps de réponse du réseau et performances de recherche aléatoire des nœuds de données Avamar.

Les performances de recherche aléatoire d’une instance Avamar physique s’adaptent au nombre et à la taille des nœuds de données. Les systèmes AVE fonctionnent moins bien, comparables à ceux d’un système à nœud unique.

Étape 4. Envoi du nouveau fragment sur le réseau à Avamar Server ou Data Domain

Lorsqu’un client envoie un nouveau fragment unique (d’une taille maximale de 64 Ko) au serveur, les performances dépendent principalement de la bande passante réseau. Cela affecte principalement les clients WAN qui génèrent une grande quantité de données modifiées chaque jour. Cela peut également affecter ceux qui fonctionnent sur des liaisons réseau encombrées. 

Vous trouverez ci-dessous des schémas montrant le flux de données dans lequel un client envoie des données à un système Avamar et à un système intégré Avamar - Data Domain.






Ressources stratégiques : Bande passante réseau entre le client et le serveur

Phase 5. Données écrites sur Avamar Server ou Data Domain

Les données de sauvegarde doivent être écrites sur le serveur Avamar ou le système Data Domain.

Ressources stratégiques : Performances d’écriture sur le disque du serveur Avamar et chargement général.