Veillez à prendre en compte les pics en lecture et écriture dans votre cahier des charges.

Une entreprise était confrontée à un manque de disponibilité de ses lecteurs et doutait, donc, des performances de son équipement.

Equipé d’une librairie IBM TS4500 avec 4 lecteurs TS1150/3592JD, le responsable informatique nous a confié les capacités des sauvegardes quotidiennes effectuées la nuit ainsi que des statistiques sur le nombre de rappels de données réalisés dans la journée.

Il nous a, d’abord, confirmé  que le taux de transfert moyen que nous souhaitions utiliser pour nos calculs de temps de sauvegarde, soit 150MB/s, était comparable, voire un peu inférieur, à ce qu’ils expérimentaient dans la réalité.

Pour calculer un temps de sauvegarde, nous estimons la vitesse d’écriture à 70% du taux de transfert officiel du lecteur lorsque la taille de son buffer est de 2GB, ce qui est le cas pour les lecteurs TS1150. Cette estimation est valide pour des fichiers de l’ordre de 1GB. Pour des fichiers de plus gros, ce qui était, en moyenne,  le cas pour cet utilisateur, la vitesse d’écriture pourra être  plus élevée, mais nous souhaitions prendre une estimation pessimiste pour nos calculs. Par exemple, pour des fichiers de 20GB la vitesse d’écriture pourra atteindre 95% du taux de transfert officiel.
(voir notre dossier technique : « La différence entre le taux de transfert officiel et la vitesse opérationnelle »)

Nous avons alors étudié les informations qui nous avaient été confiées. D’après nos calculs :

  • Avec ses 4 lecteurs dédiés à l’écriture la nuit pour 150TB écrits par mois, les sauvegardes prenaient, en moyenne, 2h06mn par jour, à raison de 20 jours par mois, il ne semblait donc pas y avoir de problème de fenêtre de sauvegarde.
  • Estimer le temps de rappels de données est plus complexe car de nombreux paramètres peuvent entrer en compte, par exemple,  est-ce que plusieurs fichiers à rappeler sont sur une même bande ?  Dans ce cas, le temps de chargement de la bande dans le lecteur et de localisation des fichiers ne devraient être comptabilisés qu’une fois.

Pour cette étude, nous avons établi, en guise de prérequis, que chaque fichier rappelé était sur une bande différente. Nous avons donc intégré au calcul de chaque rappel : le temps de chargement de la bande dans le lecteur d’environ 30 secondes, le temps de latence entre le chargement et le démarrage  du lecteur d’environ 15 secondes…De plus, nous n’avons pas pris en compte les fonctionnalités avancées des lecteurs 3592 telles que le RAO (Recommended Access Ordering) et le HRTD (High Resolution Tape Directory) qui réduisent, de façon importante, le temps d’accès aux données sur ces lecteurs. D’après notre estimation, cet utilisateur aurait pu faire tous ses rappels, soit près de 3 000 par mois, sur 1 seul lecteur en 4 heures 48mn par jour à raison de 25 jours par mois.

Nous avons partagé le résultat de notre étude  avec l’utilisateur, qui a été grandement rassuré sur les performances de son équipement. Et quand nous avons expliqué notre calcul, qui impliquait un « lissage » des rappels sur la journée, il nous a confirmé ne pas avoir pris en compte, lors de la configuration de sa librairie, les pics en rappels de fichiers auxquels il faisait face régulièrement. En effet, de part son activité, ceux-ci ne sont pas lissés sur la journée, mais se concentrent sur quelques heures par jour. Il envisage donc d’ajouter un lecteur à sa librairie pour fluidifier ses opérations de restauration et limiter les fils d’attente.