Backup , l intégration du backup sur disque

Transcription

1 À votre service Backup , l intégration du backup sur disque Aristide.Boisseau@epfl.ch EPFL Domaine IT, Coordinateur de la cellule backup et stockage A new look for centralized Backup@EPFL Lifting du service de sauvegarde centralisé de l EPFL Voici la nouvelle architecture de backup introduite au DIT en 2009: l intégration sur disque (B2D & ). 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). Architecture précédente L architecture précédente, voir la figure 1, était composée de serveurs SUN: z 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; z 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; z 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; z un serveur T1000 pour faire l interface avec la librairie SL8500. 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: z Symantec Netbackup 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 backup.epfl.ch. Pour la partie stockage: z une librairie SL8500 Sun/Storagetek avec une capacité de 3000 slots depuis janvier 2007; z 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); z 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 Master server SunFire 280R Ultrasparc 900 Mhz 2GB RAM Catalog disk array GB ACLS server SunSparc T1000 1Ghz -8GB RAM 1* 4*2 Gb/s 4*2 Gb/s 2 Gb/s 2 Gb/s NETBACKUP drives BLUE GENE drives Drive T9940B 30MB/s 200GB / tape LAN - 100/1000 Mb/s 3 media servers Sunfire v240 Ultra Sparc IIIi 1Ghz - 2GB RAM 3*4 Gb/s SAN - 1/2/4 Gb/s ACLS controlled SL8500 library 3200 tape slots 3*4 Gb/s 3*4 Gb/s 4 Gb/s 4 Gb/s NETBACKUP drives Drive T10000A 120 MB/s 500GB / tape 3* 4*4 Gb/s EMC2 filer NDMP media server Local MA B0 466 fig. 1 architecture début seer.entsupport.symantec.com/docs/ htm 23 FÉVRIER N 2 3

2 Backup , l intégration du backup sur disque 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. fig. 6 volumétrie globale sauvegardée en gigabytes Capacité librairie SL8500 fig. 2 master server CPU load janvier-mars 2009 fig. 3 média serveur 1 CPU load janvier-avril 2009 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. 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.58 PB & Capacité librairie avec des médias pour T10000B: 3000*1TB = 2.92 PB 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. fig. 7 historique capacité librairie SL8500 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 fig. 5 NDMP gigabytes sauvegardés 4 flash informatique Les lecteurs 9940B ont été utilisés 7 heures en moyenne par jour sur le premier semestre 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

3 pas à fournir le débit pour une utilisation optimale en écriture des lecteurs. Bilan z 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 T Nous avons vu le gain en terme de capacité au paragraphe Capacité librairie SL8500. z 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. z Des serveurs à renouveler pour suivre l évolution du service de sauvegarde autant en termes de capacité que de performances. Évolution du service 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. fig. 8 Evolution de la charge CPU veritas en 2009 fig. 9 Evolution de la charge CPU veritas-md1 en 2009 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. 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: z intégration simple; z administration aisée; z coût inférieur à une VTL. Les avantages de la sauvegarde sur disques sont: z performances des lecteurs T10000B indépendantes des performances clients; z meilleure utilisation des lecteurs --> diminution de leur nombre; z restauration immédiate depuis les disques (pas d accès aux bandes); z administration facilitée. Les inconvénients du backup sur disques: z des coûts supplémentaires (on espère avoir un bon ROI & avec moins de lecteurs en exploitation!) à l achat et également en maintenance; z des éléments supplémentaires dans l infrastructure à gérer; z en cas de panne d une baie, l impact sur le service est plus important qu une panne d un lecteur. 2 Quelques références sur la librairie SL8500, les lecteurs T10000B et 9940B: et 3 Descriptifs détaillés des nouveaux serveurs sur le site du fabricant: et 23 FÉVRIER N 2 5

4 Nous avons choisi deux baies de stockages 6140 de SUN ( avec chacune 32TB de stockage net (48 disques SATA de 1TB). La protection utilisée pour les baies de stockage est du RAID & 6 (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-contre). 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 4 Gb/s 4 Gb/s/s NETBACKUP drives MAsterserver T5240 SunSparc T2+ 2*6 cores 1.2 Ghz - 32GB RAM 1TB embedded catalog Media server T5120 SunSparc T2 8 cores 1.2 Ghz - 16 GB RAM 2*4 Gb/s SUN 6140 Disk array - 4 GB 48*1 TB SATA-II fig. 11 architecture générale 2009 Drive T10000B 120 MB/s 1 TB per tape LAN - 100/1000 Mb/s 1* ACLS server SunSparc T Ghz - 8GB RAM Local BM *4 Gb/s 3*4 Gb/s SAN - 1/2/4 Gb/s 4 Gb/s 4 Gb/s BLUE GENE drives ACLS controlled SL8500 library 3200 tape slots Media server T5120 SunSparc T2 8 cores 1.2 Ghz - 16 GB RAM 2*4 Gb/s SUN 6140 Disk array - 4 GB 48*1 TB SATA-II # 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: 3* 4*4 Gb/s 4 Gb/s 4 EMC2 filer NDMP media server 4 Gb/s NETBACKUP drives NAME STATE READ WRITE CKSUM B2D1 ONLINE c5t600a0b800048f eb49d23f94d0 ONLINE c5t600a0b800048f4da000008cb49d23f9ed0 ONLINE c5t600a0b800048f4da000009b14a4b8bd0d0 ONLINE c5t600a0b800048f4da000009ad4a4b8b78d0 ONLINE c5t600a0b800048f4da000009a94a4b88b4d0 ONLINE c5t600a0b800048f a4b9b76d0 ONLINE errors: No known data errors Local MA B0 466 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: 2 48 snapshots in any file system 2 48 files in any individual file system 16 exabyte file systems 16 exabyte files 16 exabyte attributes 3x10 23 petabyte storage pools 2 48 attributes for a file 2 48 files in a directory 2 64 devices in a storage pool 2 64 storage pools per system 2 64 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 J 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 J. 4 Voici deux liens sur la gestion ZFS: et 6 flash informatique

5 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. 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 J). 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 J). fig. 12 performances décembre 09 HBA veritas-md1 --> lecteurs 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 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é 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. sanas.epfl.ch. 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. 23 FÉVRIER N 2 7

6 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 Une allée froide confinée a été installée pour héberger fig. 14 entrée allée froide 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 J. Le principe est simple: on pulse l air froid dans une zone confinée (au plus près des fig. 15 arrière allée froide 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. 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 (coté 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! n