FLASH INFORMATIQUE FI



public averti Backup 2009-2010, l’intégration du backup sur disque


Lifting du service de sauvegarde centralisé de l’EPFL



A new look for centralized Backup@EPFL


Aristide BOISSEAU


Voici la nouvelle architecture de backup introduite au DIT en 2009 : l’intégration sur disque (B2D &PGCC). Tout d’abord un petit rappel de l’architecture précédente suivi d’un état des lieux du service et enfin de la solution retenue avec les évolutions à court terme (2010).

JPEG - 13.7 ko
fig. 1
architecture début 2009

Architecture précédente

L’architecture précédente, voir la figure 1, était composée de serveurs SUN :

  • d’un master serveur (Sun Fire 280R) avec les catalogues associés (unité appelée 3310 qui conserve la liste des données sauvegardées et leurs emplacements, ie sur quelles bandes !), serveur en production depuis novembre 2002 ;
  • de trois médias serveurs (Sun Fire v240) pour les backups non NDMP, c’est à dire les sauvegardes que nous appellerons standards, ces médias serveur ont été mis en production entre 2004 et 2005 ;
  • un autre média serveur filer EMC-NAS dédié aux backups de type NDMP. Ce serveur est dans l’architecture de sauvegarde depuis mai 2005 ;
  • un serveur T1000 pour faire l’interface avec la librairie SL8500.

Pour la partie stockage :

  • une librairie SL8500 Sun/Storagetek avec une capacité de 3000 slots depuis janvier 2007 ;
  • huit lecteurs/drives 9940Bs, chaque média pouvant contenir 200GB non compressés, avec un débit d’écriture de 30MB/s ou 105GB/h. Ces lecteurs sont dédiés aux backups standards (non NDMP) ;
  • quatre lecteurs T10000B de chez SUN, chaque média pouvant contenir 1000GB non compressés, avec un débit d’écriture de 120MB/s ou 420GB/h. Deux de ces lecteurs sont dédiés aux backups NDMP depuis 2007, les deux autres sont réservés aux backups du projet  CADMOS.

Pour la partie logiciel :

  • Symantec Netbackup 6.5.3.1.

Depuis 2007, les serveurs de backups et leur stockage (les lecteurs/drives) associés sont connectés via le  SAN du DIT, l’intégration du SAN dans l’architecture a permis le partage des lecteurs entre les serveurs de backups, d’où une meilleure utilisation des ressources. Précédemment les lecteurs étaient directement rattachés au serveur, il n’y avait pas de partage des lecteurs entre les serveurs. L’ensemble de clients début 2009 était d’environ 120, pour une volumétrie de 8.5TB en moyenne par jour. La volumétrie était répartie entre les backups NDMP et les backups standards. Les clients standards sont de type Solaris, Linux, Windows, Mac et autres [1] .

Constats

Grâce à la surveillance/monitoring du service, certaines métriques nous permettent de mieux connaître le comportement de notre infrastructure. Ces métriques nous aident à prendre les décisions sur l’évolution de l’infrastructure, elles sont présentées ci-dessous. La plupart des métriques sont disponibles pour les clients du service sur le site.

Serveurs

Les serveurs du service de backup ont plusieurs années de services derrières eux (plus de six ans pour le master serveur). Avec l’augmentation du nombre de clients du service, les serveurs étaient de plus en plus sollicités comme le montrent les charges CPUs des figures 2, 3 et 4. De plus, SUN arrête de les vendre (product End Of Life), nous les renouvelons donc pour pouvoir absorber l’augmentation des demandes de services et maintenir un service pérenne.
JPEG - 24.4 ko
fig. 2 –
master server CPU load janvier-mars 2009
JPEG - 23.6 ko
fig. 3
média serveur 1 CPU load janvier-avril 2009
JPEG - 21.2 ko
fig. 4 –
média serveur 2 CPU load janvier-mai 2009

Capacités du service

Nous dissocions les backups NDMP des backups standards, ils le sont de facto, car ils utilisent des ressources différentes (types de lecteurs différents). Sur les six premiers mois de l’année 2009, le volume des backups NDMP (serveurs de fichiers EMC2, NetApp) représente environ un tiers (2.7TB) de la volumétrie globale (8.6TB) comme le montrent les figures 5 et 6.

JPEG - 20.2 ko
fig. 5 -
NDMP gigabytes sauvegardés
JPEG - 17 ko
fig. 6 -
volumétrie globale sauvegardée en gigabytes

Capacité librairie SL8500

Comme le montre la figure 7, la librairie SL8500 début 2009 était quasiment pleine de bandes. Pour augmenter la capacité de stockage du service de backup sans modification de la librairie SL8500, le seul moyen était de remplacer les lecteurs 9940B par les lecteurs de dernière génération avec des capacités de stockages supérieures (1TB versus 200GB par bande). Pour la même surface au sol la capacité de stockage est 5 fois supérieure avec les nouvelles bandes utilisées par les T10000B.

JPEG - 11.8 ko
fig. 7 -
historique capacité librairie SL8500

En fonction du type de bandes/médias utilisé, la capacité globale du stockage disponible pour le backup évolue (dans notre cas d’un facteur 5) :
Capacité librairie avec des médias pour 9940B :
3000 * 200GB = 0.58PB
Capacité librairie avec des médias pour T10000B :
3000*1TB = 2.92 PB

Capacité théorique de backup

La capacité globale des 9940Bs à sauvegarder sur une tranche de 24h est d’environ 20TB (8 lecteurs à 30MB/s en écriture).
La capacité globale des deux T10000B à sauvegarder sur une tranche de 24h est d’environ 20TB (2 lecteurs à 120MB/s en écriture).

Utilisation des lecteurs

Les lecteurs 9940B ont été utilisés 7 heures en moyenne par jour sur le premier semestre 2009. Le volume journalier moyen à sauvegarder est de 6TB (voir fig. 5 et 6), le débit moyen observé est donc de 31MB/s ce qui représente une bonne utilisation des lecteurs au regard de leur performance théorique d’écriture de 30MB/s.
Les deux lecteurs T10000B sont quant à eux utilisés en moyenne 15h par jour pour sauvegarder un volume de 2.7TB, soit un débit moyen de 25MB/s en regard d’un débit théorique de 120MB/s. Les lecteurs T10000 sont donc sous-utilisés, les clients n’arrivent pas à fournir le débit pour une utilisation optimale en écriture des lecteurs.

Bilan

  • Une librairie pleine d’anciennes bandes avec un besoin toujours croissant de capacité pour le service de sauvegarde nous amène irrémédiablement à changer l’ensemble des lecteurs 9940B par des T10000. Nous avons vu le gain en terme de capacité au paragraphe Capacité librairie SL8500.
  • Les lecteurs T10000 sont plus rapides (écriture/lecture) que les 9940B, on peut supposer qu’il en faudra moins pour assurer la sauvegarde de la volumétrie globale du service. Par contre, il faut trouver un moyen pour optimiser les débits sur ces lecteurs, on a vu qu’au paragraphe Utilisation des lecteurs ceux-ci sont sous-utilisés. La solution est d’utiliser du backup sur disque ou VTL (un cache intermédiaire) pour ensuite optimiser les débits d’écriture entre le disque et les bandes.
  • Des serveurs à renouveler pour suivre l’évolution du service de sauvegarde autant en termes de capacité que de performances.

Évolution du service

Les choix sur l’évolution du service sont expliqués ci-dessous, pour les parties lecteurs, serveurs, sauvegarde sur disque et délocalisation ! L’idée principale étant de simplifier si possible l’architecture, pour une administration du service plus efficace d’une part et pour un meilleur service aux utilisateurs d’autre part.

Lecteurs

Le choix des lecteurs étant quasiment imposés (librairie et lecteurs déjà existants), il nous fallait en déterminer le nombre nécessaire pour assurer un service optimal. Un nombre de quatre T10000B semblait dans un premier temps suffisant pour nos besoins, si nous étions capables de les utiliser à leur capacité maximale. Quatre lecteurs T10000B peuvent théoriquement écrire 20TB sur 12h (on sauvegarde sur disque la nuit, on écrit sur les lecteurs le jour), ce qui est plus du double de la volumétrie journalière observée sur la figure 6  [2].

Serveurs

Le choix des nouveaux serveurs s’est porté sur des serveurs SUN UltraSPARC T2+. Tout d’abord pour conserver un matériel qui s’est avéré très fiable depuis 2002 (une seule panne en exploitation : un disque). Ensuite pour l’utilisation de Solaris 10 et de ses fonctionnalités ZFS, qui nous permettent une gestion du stockage simple, sûre donc efficace.
Nous avons profité du renouvellement des serveurs pour en diminuer le nombre, nous avons réduit le nombre de médias serveur de trois à deux (moins de maintenance, plus simple à administrer). Le master serveur (T5240) a du stockage intégré qui remplacera la baie externe (3310) utilisée pour le stockage du catalogue (un élément en moins !) [3].
Voici les Les figures 8, 9 et 10 montrent l’évolution de la charge CPU sur les serveurs durant l’année 2009, on devine facilement quand ils ont été remplacés.

JPEG - 17.5 ko
fig. 8 -
Evolution de la charge CPU veritas en 2009
JPEG - 19.2 ko
fig. 9 -
Evolution de la charge CPU veritas-md1 en 2009
JPEG - 20 ko
fig. 10 -
Evolution de la charge CPU veritas-md2 en 2009

Sauvegarde intermédiaire sur disque ou VTL  ?

Le choix s’est porté sur de la sauvegarde sur disque dans un premier temps, et ceci, pour plusieurs raisons :

  • intégration simple ;
  • administration aisée ;
  • coût inférieur à une VTL.

Les avantages de la sauvegarde sur disques sont :

  • performances des lecteurs T10000B indépendantes des performances clients ;
  • meilleure utilisation des lecteurs —> diminution de leur nombre ;
  • restauration immédiate depuis les disques (pas d’accès aux bandes) ;
  • administration facilitée.

Les inconvénients du backup sur disques :

  • des coûts supplémentaires (on espère avoir un bon ROI avec moins de lecteurs en exploitation !) à l’achat et également en maintenance ;
  • des éléments supplémentaires dans l’infrastructure à gérer ;
  • en cas de panne d’une baie, l’impact sur le service est plus important qu’une panne d’un lecteur.

Nous avons choisi deux baies de stockages 6140 de SUN (www.sun.com/storage/disk_sys...), avec chacune 32TB de stockage net (48 disques SATA de 1TB). La protection utilisée pour les baies de stockage est du RAID6 (6+2). Le choix de SUN pour les baies nous assure une homogénéité pour la maintenance et le support de notre infrastructure de backup, c’est à la fois un avantage (un seul intervenant en cas de problème) et un inconvénient (pas idéal pour faire jouer la concurrence).
La volumétrie permet de conserver les backups sur disques environ une semaine pour le moment, ce qui permet dans la majorité des cas des faire les restores directement depuis les disques. En effet les demandes de restores sont généralement faites sur des données perdues récemment.
La gestion de la protection se fait au niveau des baies 6140 (RAID6), la gestion des luns et de l’espace de stockage associé se fait avec ZFS depuis les serveurs via un pool ZFS (B2D1 dans l’exemple ci-dessous).

# zpool list
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
B2D1  32.6T  28.8T  3.87T    88%  ONLINE  -
sys    136G  31.5G   105G    23%  ONLINE  -
DIT-EX[root@veritas-md1]# zpool status
 pool: B2D1
state: ONLINE
scrub: none requested
config:

NAME                                     STATE   READ WRITE CKSUM
B2D1                                     ONLINE    0    0     0
 c5t600A0B800048F476000007EB49D23F94d0  ONLINE    0    0     0
 c5t600A0B800048F4DA000008CB49D23F9Ed0  ONLINE    0    0     0
 c5t600A0B800048F4DA000009B14A4B8BD0d0  ONLINE    0    0     0
 c5t600A0B800048F4DA000009AD4A4B8B78d0  ONLINE    0    0     0
 c5t600A0B800048F4DA000009A94A4B88B4d0  ONLINE    0    0     0
 c5t600A0B800048F476000009404A4B9B76d0  ONLINE    0    0     0

errors: No known data errors

L’ajout de nouvelle capacité dans les pools ZFS se fait à chaud sans interruption de service. Il suffit d’ajouter le nouveau lun via une simple commande :


zpool add B2D1 c5t600A0B800048F4DA000009B14A4B8BD0d0

L’architecture de ZFS est basée sur 128 bits, voici quelques limites théoriques associées à ZFS :

The 128-bit architecture also means that there are no practical limits on the number of files, directories, and so on. Here are some theoretical limits that might, if you can conceive of the scope, knock your socks off :
  • 248 snapshots in any file system
  • 248 files in any individual file system
  • 16 exabyte file systems
  • 16 exabyte files
  • 16 exabyte attributes
  • 3x1023 petabyte storage pools
  • 248 attributes for a file
  • 248 files in a directory
  • 264 devices in a storage pool
  • 264 storage pools per system
  • 264 file systems per storage pool

Le choix de l’ OS a été pris d’une part pour sa fiabilité, mais également pour la partie ZFS, qui nous permet de gérer le stockage de manière simple, sûre donc très efficace [4].
Finalement, chaque 6140 est dédié à un seul média serveur, il n’y pas de partage du stockage entre les médias serveurs (à l’inverse des lecteurs qui peuvent être utilisés par n’importe quel serveur). La raison est simple, les licences Netbackup pour la gestion du partage du stockage se font au volume (par TB) et non par baie. In fine le coût de ces licences et leurs maintenances seraient prohibitifs en exploitation. La gestion des disques appelée standards de Netbackup (tel qu’utilisé dans notre architecture via ZFS) n’entraîne aucun coût de licence supplémentaire.

Architecture 2010 – Backup sur disque

La figure 11 montre l’architecture avec les nouveaux serveurs, les baies de disques et l’ensemble des lecteurs au nombre de quatre pour le service de sauvegarde et deux lecteurs pour la sauvegarde du projet CADMOS (remplace le Bluegene/L). Les serveurs ont été remplacés au printemps 2009 (comme le montrent les figures 8, 9 et 10) ainsi que l’ajout des deux nouveaux lecteurs T10000B, les baies de disques ont été mises en production en juillet. Le nombre de composants a diminué de 30% passant de 20 (serveurs, lecteurs, librairie et 3310) à 14, l’administration du service en est donc simplifiée.

JPEG - 5.8 ko
fig. 11 -
architecture générale 2009

Serveurs

Le master serveur intègre le stockage des catalogues via ZFS. Chaque média serveur est connecté à sa baie de stockage via deux cartes fibres ( HBA) de 4Gb/s chacune, les lecteurs sont quant à eux accédés via un seul HBA. Un média serveur utilise au plus deux lecteurs en même temps.
Les sauvegardes NDMP se font également sur disques via les médias serveurs et non plus directement sur les lecteurs T10000B.

Backup sur disque

Les sauvegardes se faisant sur disques, elles ne sont plus pénalisées par les erreurs d’écritures sur bandes.
Les demandes de restauration de données sont pour la plupart effectuées depuis les disques (en moyenne une semaine de sauvegarde conservée sur les disques), dans ce cas de figure il n’y a pas d’attente pour l’obtention des ressources (disque en lieu et place du lecteur et des bandes).
La duplication des données se fait dans la journée en utilisant de manière optimale les lecteurs (optimisation des performances d’écritures indépendantes des clients :-)). En cas de panne d’une baie 6140 on perd une nuit de backups, c’est un point négatif de l’introduction du backup sur disque. La probabilité est cependant faible (ZFS sur du RAID 6).
Sur les figures 12 et 13 on voit que les performances d’écritures sur les lecteurs T10000B sont atteintes (deux lecteurs en parallèle au plus par média serveur) : plus de 300MB/sec en pointe (supérieur à 2*120MB/s :-)).

JPEG - 19.7 ko
fig. 12 -
performances décembre 09 HBA veritas-md1 —> lecteurs
JPEG - 19.2 ko
fig. 13 -
performances décembre 09 HBA veritas-md2 —> lecteurs

Futur proche

Netbackup 7.0

Netbackup 7.0 est annoncé pour début 2010, une mise à jour de notre infrastructure n’est pas envisagée avant l’été ! Les nouvelles fonctionnalités sont en particulier l’intégration de la déduplication et des techniques de sauvegarde telles que VCB pour l’intégration des outils de backup de VMWare dans Netbackup (déjà existantes dans Netbackup 6.5). La mise en place de Netbackup 7.0 fera l’objet d’un article dans le Flash informatique.

Changement de SLA

Une évolution du SLA sera proposée courant 2010, pour une mise en place en 2011. Il s’agira de diminuer la rétention des données sauvegardées pour réduire la volumétrie conservée sur bandes et ainsi libérer des ressources.

Déménagement en BM

L’ensemble de l’infrastructure de sauvegarde (librairie, lecteurs, disques et serveurs) sera hébergé dans un nouveau local dédié dans le bâtiment BM. Cette séparation des données (source et sauvegarde) permettra de renforcer la sécurité et la pérennité du service. La librairie, les bandes et les lecteurs ont été déplacés au mois de novembre 2009, les serveurs et les disques seront déplacés du MA au BM en début 2010.
Une allée froide confinée a été installée pour héberger les serveurs dans le nouveau local de backup, ce confinement permet de mieux réguler la gestion de l’air froid et ainsi permet de faire des économies d’énergies :-). Le principe est simple : on pulse l’air froid dans une zone confinée (au plus près des serveurs) et non plus dans le volume total de la salle. On peut voir l’allée froide composée de quatre racks pour l’instant sur les figures 14 et 15.

JPEG - 13.4 ko
fig. 14 -
entrée allée froide
JPEG - 14.9 ko
fig. 15 -
arrière allée froide

Conclusion

Depuis plus d’une année des changements majeurs ont été apportés au service de backup, apportant une gestion plus simple d’un point de vue administratif et une plus grande flexibilité du côté client (restore immédiat depuis les disques). Les prochaines évolutions du service se focaliseront sur une meilleure gestion de la volumétrie avec très certainement l’introduction de la déduplication (côté client et/ou serveurs/disques) avec la mise en place de Netbackup 7, sans oublier la maîtrise de l’énergie et des coûts  !



Glossaire

B2D (backup to disk)
sauvegarde sur disque
CADMOS (Center for Advanced Modeling Science)
initiative des universités de Genève, Lausanne et de l’EPFL dans le domaine des ordinateurs à haute puissance de calcul et de leur utilisation
HBA (Host Bus Adapter)
une carte d’extension qui permet de connecter un système hôte à un bus externe réseau de stockage.
lun (Logical Unit Number)
identifiant d’unité logique, c’est-à-dire pointeur vers un espace de stockage.
NDMP (Network Data Management Protocol)
protocole de communication ouvert utilisé pour la sauvegarde des équipements stockage en réseau NAS. Il doit permettre, en environnement hétérogène, une meilleure communication entre équipements de stockage et logiciels de sauvegardes
PB (PetaByte)
1 pétabyte est équivalent à 1000 térabytes ou 1 million de gigabytes.
RAID (Redundant Array of Inexpensive Disks)
matrice redondante de disques indépendants.
ROI (Return on Investment)
Terme économique qui signifie retour sur investissement
SAN du DIT
service de stockage du Domaine IT mis à la disposition des Facultés et des services centraux de l’EPFL.
SLA (Service Level Agreement)
document qui définit la qualité de service requise entre un prestataire et un client.
VCB (VMware Consolidated Backup)
interface de backup VMware.
VTL (Virtual Tape Library)
technologie de virtualistation du système de stockage.
ZFS (Zettabyte File System)
système de fichier open source, produit par Sun Microsystems.

[1] seer.entsupport.symantec.com/docs/325328.htm

[2] Quelques références sur la librairie SL8500, les lecteurs T10000B et 9940B.

[3] Descriptifs détaillés des nouveaux serveurs sur le site du fabricant :www.sun.com/servers/coolthreads/t5240/index.xml et www.sun.com/servers/coolthreads/t5120/index.xml.

[4] Voici deux liens sur la gestion ZFS : www.sun.com/bigadmin/features/articles/zfs_part1.scalable.jsp et www.sun.com/bigadmin/features/articles/zfs_part2_ease.jsp.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.