FLASH INFORMATIQUE FI



Configuration de stockage pour la sauvegarde sur disque


Dans le cadre d’utilisation pour un serveur de backup, la configuration d’une baie de disques doit tenir compte à la fois de la nature séquentielle d’un flux donné, mais aussi de la concurrence de flux en lecture et écriture.



In the context of a backup server, the configuration of a disk array storage must take into consideration both the essentially sequential nature of a given stream, as well as the concurrency of read and write streams.


Patrice BEAUD


Introduction

Dans le cadre du renouvellement de l’infrastructure du service de backup du DIT, nous avons demandé des offres à différents constructeurs. Ces offres devaient comprendre un serveur et son stockage attaché. Le cahier des charges était simple : la baie de disques de stockage devait offrir au minimum 30 TB de volume utile et supporter des charges concurrentes d’écriture et de lecture dans un rapport proche de 50 % et pour un débit total d’au moins 600 MB/s, chaque flux étant de type séquentiel.
Ce cahier des charges se base sur les spécificités du service de backup, à savoir qu’il fonctionne selon le principe du D2D2T (Disk to Disk to Tape). En d’autres termes, les sauvegardes se font ainsi : les disques des clients sur les disques des serveurs, puis les disques des serveurs sur des bandes magnétiques. Les disques des serveurs servent d’espace tampon à basse latence. La copie sur bande magnétique assure le stockage des données pour l’entièreté de la durée de rétention. Notons qu’en condition normale, les sauvegardes des clients, donc les opérations d’écriture sur les disques des serveurs, ont lieu durant la nuit, et les copies sur bandes magnétiques, donc les opérations de lecture sur ces mêmes disques se tiennent durant la journée. Cependant, il arrive que des sauvegardes débordent sur la journée ou que les copies sur bandes n’ont pas pu être terminées avant le démarrage des premières sauvegardes du soir. Nous nous trouvons alors dans un mode mixte d’écriture/lecture, pendant lequel les stockages disques doivent pouvoir balancer leur capacité entre écriture et lecture. Avec 300 MB/s de lecture, nous pouvons déplacer environ12 TB de données des disques vers les lecteurs en 12 h, pendant lesquelles autant de données pourraient être écrites par des sauvegardes concurrentes. Cela représente environ 30% de la capacité de la baie dans la configuration retenue. En sachant que nous visons une rétention sur disque comprise entre cinq et sept jours, ces 12 TB de données représentent au moins une fois et demie le volume moyen d’une journée.

Matériel et Spécifications

Le PowerVault MD3260 est doté de deux contrôleurs. Chaque contrôleur est doté d’un cache en miroir de 2 GB, protégé des coupures de tension par une batterie, assurant ainsi la sécurité des données et la haute disponibilité du stockage. Quatre ports SAS 6Gbps équipent chacun de ces contrôleurs. Le MD3260 est une baie compacte, où les disques sont disposés à l’horizontale par douzaine dans cinq tiroirs. Dans la configuration acquise, la baie comporte soixante disques SAS 10k de 900 GB brut.
Ces soixante disques ne sont pas exploitables directement. Il est nécessaire de créer des conteneurs logiques, qui peuvent être soit des disk groups ou groupe RAID, soit des disk pools. À l’intérieur de ces conteneurs, il faut ensuite définir un ou plusieurs virtual disks. Ce sont ces derniers qui seront présentés aux hôtes, les serveurs, via le LUN masking.
Les disk groups offrent une protection RAID classique avec les niveaux 0, 1, 5, 6 et 10. Le nombre maximum de disques pour les RAID 0, 1 et 10 est de 96, et de 30 pour les RAID 5 et 6.
Quant au disk pool, il lui faut un minimum de onze disques pour être défini, mais pas de maximum, si ce n’est le nombre que la baie et ses extensions peuvent supporter physiquement. Dans un disk pool, les données et la redondance sont réparties sur l’ensemble des disques, avec un niveau de protection semblable à un RAID 6. Ses principaux avantages sont la simplicité de configuration et de maintenance, ainsi qu’une reconstruction bien plus rapide qu’en RAID 6, en particulier pour les disques SATA de 3 TB.
Les données sont lues ou écrites par stripe, ou bande. Une bande est constituée de segments. Le segment est l’unité minimale avec laquelle le disque virtuel travaille et cette opération se fait sur un disque. Les disques virtuels définis dans un disk group peuvent être configurés avec une taille segment variant de 8 kB à 512 kB, alors que ce segment est de taille fixe de128 kB, dans le cas d’un disque virtuel créé dans un disk pool. La taille de la bande, ou stripe width, est le nombre de segments, donc de disques. Dans le cas des disk groups, cette taille correspond au nombre de disques du groupe RAID. En revanche dans le cas du disk pool, elle est fixée à onze. Il s’ensuit que pour n disques de la bande, l’OS doit fournir n fois la taille de la bande.

Outils et conditions de tests

Le serveur est configuré avec deux processeurs Intel Xeon E5-2650 et de 64 MB de RAM. La connexion au stockage est réalisée par deux cartes PCI-E SAS 6 Gbps, sans contrôleur de stockage. Dell ne propose pas d’outil de multipathing propriétaire, mais utilise les outils natifs des OS, en modifiant les paramètres idoines, lors l’installation de leur logiciel sur le serveur.
L’OS installé est RHEL 6. Les LUNs présentés par le MD3260 sont assemblés en RAID 0 par le RAID software du noyau Linux. Les résultats présentés plus loin sont issus de données récoltées par la commande iostat -m -x 1, pendant qu’une ou plusieurs commandes dd réalisent des écritures ou des lectures. Le lancement des commandes dd se fait par un script shell. Rien de très sophistiqué, c’est fait au plus simple. De plus, dd a le mérite d’être assez rudimentaire, avec relativement peu d’options, et d’offrir un comportement séquentiel, proche donc de l’application.

Configuration du stockage et premiers tests

Après quelques tests avec des disk pools, il s’est vite avéré qu’ils ne pouvaient pas répondre au cahier des charges. En effet, dès qu’un flux en écriture survenait, le ou les flux en lecture s’écroulait. Comme ce mode n’offre pas d’options de configuration, nous n’avons donc abandonné ce mode que pour revenir aux traditionnels groupes RAID.
Nous avons opté pour des disk groups protégés en RAID 5, qui offrent de meilleures performances en écriture séquentielle que le RAID 6. Nous avons fait des tests avec des groupes de 6+1 et 8+1. Ce choix est basé sur les discussions avec les ingénieurs Dell. Il est entre autres dépendant de compromis entre le nombre de disques virtuels, qui devront être assemblés au niveau OS, et la taille du groupe (plus gros implique un temps de reconstruction plus long). Avec soixante disques, nous avons donc :

  • 6+1 : 7 disques par groupe, ce qui fait 8 disques virtuels et 4 disques de hotspare.
  • 8+1 : 9 disques par groupe, donc 6 disques virtuels et toujours 4 disques de hotspare.

Nous avons pris garde à obtenir un nombre pair de disques virtuels, afin de répartir de façon uniforme les entrées/sorties sur les deux contrôleurs en assignant ces disques virtuels en même nombre aux deux contrôleurs.
Les tests n’ont pas montré de très grosses différences entre ces deux configurations. En d’autres termes les contrôleurs arrivent à gérer ces deux configurations sans souffrir dans l’une plus que dans l’autre. Au final, nous avons opté pour la configuration en 6+1, qui limite doublement les soucis inhérents au RAID 5 –la perte d’un second disque lorsque le premier n’a pas été reconstruit est fatale pour le RAID 5 –. En effet, nous limitons le temps de reconstruction, mais aussi la taille du volume, donc l’occurrence d’une erreur non décelable. De plus, un groupe de disques comportant plus de membres présenterait théoriquement plus de latence – les têtes de lecture de tous les disques impliqués ne vont pas se positionner simultanément sur le bon secteur–.

Résultats

La figure 1 montre un exemple de la sortie de la commande iostat pour une série de tests d’écriture et de lecture. La séquence montrée est un flux d’écriture, puis un flux de lecture, enfin un flux de lecture et d’écriture en simultanée. Nous pouvons constater que dans cet exemple, le débit du flux en lecture s’écroule avec la présence d’un flux d’écriture (voire entre 300 et 350 secondes).

fig. 1 – données de débit lecture/écriture d’une séquence de tests dd sur un disque virtuel sur un groupe RAID 5 en 6 + 1, avec un segment de 128 kB

Le taux des requêtes de cette même séquence est affiché dans la figure 2. Le test d’écriture pure et de lecture pure montre la pénalité d’écriture introduite par la protection RAID (suite au calcul de parité, la vérification des écritures nécessite des opérations de lectures supplémentaires). Le rapport entre les taux pour l’écriture et la lecture est d’environ 1:3.5. Cela est inférieur à la pénalité théorique de 1:4. Cette différence provient sans doute des effets combinés du cache et du circuit dédié au calcul de parité sur les contrôleurs. Le graphique montre aussi que, pendant le test d’écriture/lecture simultanée, l’écriture consomme l’essentiel des capacités d’entrée/sortie de la baie : pour une requête d’écriture de l’OS, la baie doit faire plus d’opérations de lecture, diminuant d’autant les ressources pour les requêtes de lecture.

fig. 2 – données du taux de requêtes au niveau OS pour la même séquence que dans la figure 1

Compte tenu de ce que nous pouvons observer ci-dessus, nous pouvons déjà conclure que dans cet état, le service de backup ne pourrait pas être assuré : les écritures des secondes copies sur bandes magnétiques et les opérations de restauration des clients seraient pratiquement impossibles en cas de sauvegardes simultanées (écriture sur les disques), vu le débit de lecture si faible. Notons tout de même que nous avons déjà un total des débits écriture et lecture proche des 600 MB/s demandé par le cahier des charges, avec un disque virtuel. Il faut si possible trouver une configuration modifiant la répartition des opérations de lecture et d’écriture.


fig. 3 – variation de rapport du débit de lecture sur le débit total en fonction de la taille du segment des disques virtuels, lors d’écritures et lectures concurrentes

Les données présentées sont calculées à partir des médianes des mesures iostat pour deux flux en lecture et huit flux en écriture. Les tests ont été réalisés sur un assemblage en RAID 0 logiciel (MD RAID de Linux) de deux disques virtuels (une paire pour chaque taille de segment).
Nous constatons un effet très sensible de la taille des segments. Plus cette taille est grande, plus le débit de lecture augmente. Cela est aussi le cas dans la répartition des taux de requêtes : dans la figure 4, nous voyons une répartition des taux de requêtes presque identiques pour les lectures et les écritures.


fig. 4 – taux de requêtes de lecture et d’écriture avec une taille de segment de 512 kB

Nous avons aussi observé que le débit de lecture ou le taux de requêtes de lecture n’est que très peu dépendant du nombre de flux, que ce soit en lecture ou en écriture. En d’autres termes, la multiplication des flux de lecture ne va pas augmenter le débit de lecture, mais le partager entre les flux. La taille du segment du disque virtuel influence la répartition des ressources entre les opérations de lecture et d’écriture.

Conclusion

La configuration d’un stockage disque dépend fortement de l’application qui va l’utiliser. Dans le cas d’une application de backup, nous avons des flux qui, pris un à un, sont généralement séquentiels. Dans notre cas de figure, le service de backup du DIT, il faut donc garantir un taux de lecture suffisant sur le stockage disque. En présence d’écritures, il faut limiter les pertes de débits de lecture, afin de pouvoir poursuivre la copie sur les bandes magnétiques dans des conditions suffisamment bonnes. Il est crucial que les données soient rapidement protégées sur les bandes magnétiques, pour pouvoir purger ces données des disques des serveurs et ne pas bloquer les futures sauvegardes des clients.
Nous avons donc cherché les conditions optimales dans ce sens. Nous avons constaté que la taille de segment des disques virtuels montre une influence notoire sur la répartition des taux de requête d’écriture et de lecture. En augmentant cette taille, la part réservée aux lectures augmente. Nous avons pu obtenir le rapport souhaité entre écriture et lecture avec des groupes RAID de six disques de données et une taille de segment de 512 kB.



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.