FLASH INFORMATIQUE FI



Backup on SAN




Aristide BOISSEAU


Introduction

Au cours de l’année 2007 l’infrastructure du réseau de stockage (SAN) du DIT a grandement évolué. Cet article présente cette évolution ainsi que les modifications apportées à l’architecture du service de backup.

Architecture SAN

J’entends par architecture SAN l’ensemble des composants réseaux (switchs) permettant l’interconnectivité de différents éléments (serveurs/baies de stockage/lecteur de bandes/…) par le protocole fibre.

Initiale


JPEG - 15.2 ko
fig. 1
SAN : architecture initiale

L’architecture comporte deux sites :

site de production :
se trouve dans la salle machine du DIT, lieu où les serveurs doivent être pour se connecter à l’infrastructure SAN.
site de miroir :
se situe dans le bâtiment INJ, lieu où se trouvent des données répliquées (50%) du site de production. C’est un Disaster Recovery site  : si les baies de stockage du DIT partent en fumée :-(, les données répliquées seront sur le site miroir :-).
L’architecture initiale comporte deux fabriques (agrégat de switchs) qui s’étendent entre le site de production et le site miroir comme le montre la figure 1. Deux switchs Cisco 9232MDS avec chacun 32 ports en salle machine au DIT et de l’autre sur le site miroir, deux switchs Cisco 9216MDS avec chacun 16 ports. Les deux sites sont séparés par environ 1000m. Chaque client devrait avoir une connexion dans chaque fabrique du site de production pour des raisons de redondance.
Le nombre de clients du SAN grandissant, la capacité de connectivité du site de production s’en est trouvée largement réduite, une extension de cette capacité a donc été planifiée mi-juin 2007. Ce changement fut un projet complet (étude, validation, implémentation) qui s’est déroulé sur le premier semestre 2007. La migration des clients (serveurs Exchange, Mailbox et autres) s’est déroulée sans interruption de service, à l’exception du service NAS (service de fichiers) qui a nécessité un arrêt de service de huit heures environ.

Actuelle


JPEG - 9.4 ko
fig. 2
SAN : architecture actuelle

Des switchs de plus grande capacité sont venus remplacer les switchs de 32 ports. Ces switchs sont des Cisco MDS9509, on peut installer 9 modules par switch comme le montre la figure 2. À ce jour il y a deux modules de managements par switchs, deux modules de 48 ports/4Gbit ainsi qu’un module iSCSI (fabrique 1) et un module 24 port/4Gbit dédié à l’infrastructure backup (fabrique 2).

Architecture du backup

Précédente


JPEG - 12 ko
fig. 3
backup : architecture précédente

L’architecture du service de backup avant la modification de ce printemps était celle que l’on peut voir sur la figure 3.
Chaque lecteur de bandes était rattaché à un seul média serveur, autrement dit les lecteurs étaient dédiés et les ressources (lecteurs) non partageables entre les médias serveurs. Pour la mise en place d’une utilisation partagée des drives entre les différents médias serveurs, il était nécessaire de connecter l’ensemble des lecteurs et serveurs sur un SAN.

Actuelle


JPEG - 7.2 ko
fig. 4
backup : architecture actuelle

Depuis le mois de novembre, tous les média serveurs du service de backup ainsi que l’ensemble des drives sont connectés à l’infrastructure SAN comme le montre la figure 4. Chacun des trois médias serveurs a trois connexions sur le SAN, un média serveur peut utiliser au plus trois drives 9940B, parmi huit, en même temps. Les drives T10000A sont réservés pour les backups NDMP (Network Data Management Protocol), qui sont faits par les serveurs EMC du service de fichiers (NAS).

Partage des lecteurs


JPEG - 24.8 ko
fig. 5
lecteur partagé

Pour bénéficier du partage des lecteurs sur le SAN nous avons ajouté la fonctionnalité Shared Storage Option (SSO) sur l’application Netbackup qui gère le service de backup. In fine, nous eûmes un ensemble D de n drives pouvant être utilisés par n’importe quel média serveur.

Configuration
La configuration des lecteurs sur un média serveur nécessite un arrêt du service (15 minutes) sur ledit serveur, les modifications sous Solaris 9 se font sans reboot. Le lecteur de bande STK.T9940B.005, par exemple, est visible par chaque média serveur et accessible par trois chemins, comme le montre la figure 5.
Bénéfices
La gestion des lecteurs peut se faire de manière globale et plus en fonction de tel ou tel média serveur, la maintenance des lecteurs est plus souple (les impacts sur la production sont moins visibles pour les clients). Il y a une meilleure tolérance aux pannes : si un lecteur tombe en panne, cela affecte l’ensemble des ressources. Dans notre architecture actuelle (fig. 4) on aura un ratio de 7/8 (en ne prenant en compte que les lecteurs 9940B). Pour l’architecture précédente (fig. 3) selon le média serveur qui voit un de ses lecteurs tomber en panne le ratio est de 2/3 ou 1/2.

So what ?

Une nouvelle architecture c’est bien, mais à quoi cela sert ? Je vais pointer ici certaines possibilités et inconvénients majeurs de cette nouvelle solution.

Inconvénients

Le principal défaut de la nouvelle architecture du service de backup sur le SAN en est son coût et sa relative complexité. En effet, en ajoutant des composants supplémentaires on pourrait s’étonner d’une baisse des coûts ! Il y a en premier lieu le coût matériel de la nouvelle infrastructure et ensuite les coûts des licences SSO supplémentaires (une pour chaque lecteur).
Un autre inconvénient, que l’on néglige souvent, est la gestion de l’infrastructure SAN. L’architecture est plus complexe donc plus difficile à gérer. Des outils de mesure évolués sont nécessaires pour la bonne maîtrise de cet environnement.

Possibilités

Il y en a un nombre certain, pour ne pas dire un certain nombre. On peut parler d’un nouvel univers tellement les possibilités sont diverses et variées, et en particulier :

  • Backup to Disk to Tape (B2D2T)
  • Virtual Tape Library (VTL)
  • Serverless backup, LAN free backup.

B2D2T

Pour le B2D2T, l’infrastructure actuelle est suffisante pour une évaluation sans ajout majeur de matériel et logiciel. On pourra de la sorte scinder le backup sur deux niveaux de stockages et ainsi optimiser l’utilisation des lecteurs. En effet les performances de ces derniers sont le plus souvent très supérieures à celles des clients. Pour les lecteurs actuels les performances sont les suivantes :

  • 9940B : 30MB/s - 200GB/bande
  • T10000 : 120MB/s - 500GB/bande (bientôt 1000GB)

Un client connecté en 100Mb/s sur le réseau IP ne pourra dépasser 12MB/s, vitesse trois fois inférieure au débit des 9940B. Sur les trois derniers mois la bande passante moyenne pour l’ensemble des clients du backup est de 6 MB/s, comme le montre la figure 6. On est loin des 30MB/s des 9940B :-(. Par contre, le débit des disques pourra être choisi en fonction des performances des lecteurs.

JPEG - 13.6 ko
fig. 6
Gigabytes backupés

Pour le moment les T10000 sont connectés aux filers EMC du service de fichiers via le réseau SAN, ce qui permet de bonnes performances comme le montre la figure 7. On peut dire que ces lecteurs sont mieux utilisés que les 9940B, en moyenne on les utilise à la moitié de leur performance optimale :-).
JPEG - 16.5 ko
fig. 7
backup : performances T10000

Avantage triple du B2D2T :

  • meilleure utilisation des lecteurs (optimisation des ressources) ;
  • restore plus rapide si les données sont sur disque : pas d’attente de disponibilité d’un lecteur ;
  • augmentation de la disponibilité des drives pour les backups.

VTL

Des VTL font également leur apparition dans l’offre des composants du backup. Ce sont en fait des baies de disques avec de l’intelligence embarquée. On émule des lecteurs de bandes sur disques, ensuite le déplacement des données de la VTL vers les bandes du robot se fait en tâche de fond. Des technologies comme la déduplication peuvent être intégrées aux VTL, ce qui enrichit l’offre à tous les niveaux. Un dessin vaut souvent bien plus que moult explications, alors voici un schéma explicatif sur la figure 8.

JPEG - 7.7 ko
fig. 8
backup To Disk/VTL To Tape
  • le chemin 1 est le chemin suivi pour backuper des données depuis un client du réseau IP. Sans l’intégration de VTL ou de disques, les données iraient directement sur bandes depuis le média serveur ;
  • le chemin 2 représente le chemin de retour des données en cas de restauration depuis la VTL ou les disques ;
  • le chemin 3 représente le chemin de retour des données en cas de restauration depuis les bandes ;
  • le chemin 4 représente le chemin des données de la VTL ou des disques vers les bandes.

LAN free, serverless backups

On parle de LAN free backup lorsque le flux de données à backuper n’utilise pas le réseau IP. Le backup des filers EMC du service de fichiers (70TB) sur la figure 4 se fait de cette manière. Les performances de la figure 7 sont donc des performances de backup LAN free, les données à backuper circulent uniquement sur le SAN. On évite ainsi de surcharger le trafic sur le réseau IP. Il faut noter qu’il n’est pas nécessaire d’avoir un SAN pour faire du LAN free backup.
Le principe du serverless backup est l’utilisation de techniques (snapshot, clone) pour faire des backups, de manière à minimiser l’impact de ces derniers sur les serveurs de production. Un SAN permet une mise en place aisée de ce type de backup. Un exemple simple : dupliquer/cloner des disques pour ensuite effectuer le backup à partir des duplica/clones. Cette solution est coûteuse autant en terme de stockage (volumétrie doublée) qu’en terme de serveur. En effet, il faut un média serveur par type d’OS pour effectuer le backup du clone (sans compter l’applicatif si besoin). Une fois le clone créé, le serveur de production continue ses tâches productives et le backup peut se faire à partir du clone accessible via le serveur supplémentaire. Pour des services où la fenêtre de sauvegarde est une donnée critique (peu de temps pour le backup), cette technique peut être salvatrice.

So !

Un bilan rapide sur le service de backup nous indique une volumétrie de 6TB quotidienne comme le montre la figure 9. Un rapide calcul sur la capacité de backup des 8 lecteurs 9940B nous donne une estimation d’environ 20TB/jour :

JPEG - 15.4 ko
fig. 9
Gigabytes backupés

(30MB/sec * 3600 * 24 / 1024 /1024)*8 = 19.77 TB
Un rapide calcul sur la capacité de backup des 2 lecteurs T10000 nous donne une estimation d’environ 20 TB/jour :
(120MB/sec * 3600 * 24 / 1024 /1024)*2 = 19.77 TB

Nous disposons d’une puissance maximum de backup de 40TB/jour soit 16.5TB/10h. Les drives sont occupés en moyenne dix heures par jour comme le montre la figure 10, pour sauvegarder en moyenne 6TB. Il y a un facteur de 2.75 entre la puissance maximale de backup et ce qui est réellement backupé. Il est alors facile de comprendre les avantages d’introduire des composants comme des VTLs pour diminuer ce rapport.

JPEG - 9.8 ko
fig. 10
moyenne mensuelle d’utilisation des lecteurs de bandes

Une interprétation directe entre les figures 6 et 9 est fausse  ! Si on se base sur des performances moyennes de 6MB/s (fig. 6) avec 10 lecteurs on obtient environ 2TB/jour backupé, alors que la figure 9 indique 6TB/jour. La réponse est l’utilisation du multiplexage des flux de backups (plusieurs backups de clients différents en même temps sur une bande), et du multistream (plusieurs flux de backups en même temps depuis un client). Ces variables (mutiplexing et multistreaming) permettent d’augmenter l’utilisation des lecteurs, mais sont dépendantes de trop de facteurs (charge du client, charge des médias serveurs, charge réseau) pour établir de bonnes projections.
Maîtriser les évolutions futures du service de backup sur le SAN devient un nouveau challenge. L’idée principale est d’introduire de nouveaux composants dans l’architecture du service de backup pour optimiser l’utilisation des ressources. En introduisant différents niveaux de stockage (disques, VTL, bandes) on veut utiliser au mieux les lecteurs de bandes (moins de lecteurs pour le même volume backupé ou plus  !) tout en proposant des restaurations plus rapides. Cette démarche a aussi pour effet une maîtrise des coûts financiers, en somme tout le monde devrait en profiter !

Lexique et liens



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.