Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Gestion de fichiers

Gestion de fichiers

Une problématique différente

S’il y a des similitudes entre le partage de données gérées en base, et le partage de fichiers, il faut garder à l’esprit aussi les différences essentielles :

  • Un serveur de base de données est à la fois une unité de stockage et une unité de traitement. Pour répondre à une requête, il doit effectuer des traitements, qui peuvent être complexes et longs.
  • Au contraire, un serveur de fichiers n’a que des traitements très simples à effectuer pour savoir quels blocs il doit accéder sur quels disques. Il a donc une plus grande capacité à servir des requêtes, et il est plus souvent limité soit par le débit de ses disques, soit par le débit de son interface réseau.

Il est assez aisé d’augmenter les capacités d’un serveur de fichiers, en premier lieu avec des disques plus rapides, puis avec une configuration RAID avec stripping et des interfaces réseau Gigabit.
Malgré tout, comme tout composant central, le serveur de fichiers finira par devenir facteur limitant de l’architecture.
Etudions donc les différents moyens de gérer des fichiers partagés entre différents serveurs. On va d’ailleurs retrouver finalement les différentes voies étudiées pour les bases de données, en particulier la réplication, le partage et le partitionnement.

Des fichiers en base

Les bases de données acceptent des objets binaires (BLOB) de grande taille, qui peuvent stocker des fichiers. Gérer des fichiers en base de données peut être une option, lorsque la volumétrie est faible.
Il y a quelques bénéfices à en attendre :

  • L’homogénéité des accès : données structurées et fichiers sont gérés de la même manière.
  • La cohérence, et le bénéfice des propriétés ACID des bases de données. Typiquement, aussitôt qu’une application manipule à la fois une référence à un fichier, dans la base de données, et le fichier proprement dit, il y a des risques d’incohérences entre l’un et l’autre.
  • L’homogénéité et la cohérence des sauvegardes : en une seule opération, on sauvegarde l’état courant de la base et des fichiers associés.

C’est par exemple la solution retenue par différents outils CMS ou GED pour adopter un fonctionnement dit en cluster.
L’un des inconvénients est que le fonctionnement n’est pas transparent pour les applications, qui n’accèdent pas aux fichiers en base par les APIs ordinaires, et ne peuvent pas faire de l’accès direct.
Par ailleurs, dès que la volumétrie grandit, c’est un mauvais choix :

  • La base de données devient énorme et les opérations d’exploitation deviennent difficiles.
  • Les performances sont inférieures à celles d’un file system.
  • Il y a une certaine opacité du dispositif pour les exploitants

La réplication

Comme pour les bases de données, lorsque des fichiers sont très majoritairement en lecture, le plus simple et le plus efficace est de les répliquer vers les différents serveurs qui en ont usage.
L’important, comme toujours, est de bien identifier quelle est la version maître des fichiers, celle qui est à jour à un instant donné. C’est à partir de cette version maître que l’on organisera la réplication.

 

Rsync ne réalise pas une copie massive des fichiers, de la source vers la destination. Au contraire, il commence par analyser les différences entre destination et source, afin de réduire les échanges au strict minimum requis. Non seulement les fichiers inchangés ne sont pas envoyés, mais Rsync peut aussi découper les fichiers en morceaux, et ne renvoyer que les morceaux modifiés.
Du fait de cette économie de moyens, Rsync peut être lancé périodiquement, de manière assez fréquente, sans mémoire de son exécution précédente. Si rien n’a été modifié depuis la dernière synchronisation, Rsync ne transfère rien.
Notons que dans les environnements locaux, on utilise RSync en mode « -W » pour « whole file » (fichier entier) car le débit n’est pas contraint et cette technique utilise moins de CPU.

Gestion de contenus et réplication

Considérons le cas d’un site web entièrement statique, constitué d’une arborescence de fichiers Html et autres composants. Si ce site doit supporter une charge très importante, le moyen le plus efficace pour en assurer l’extensibilité, est de simplement répliquer l’arborescence de fichiers vers N serveurs, à partir d’un serveur maître.
Lorsque des modifications sont requises, elles sont opérées sur le serveur maître. Lorsque le RSync est lancé par l’ordonnanceur, il détecte les changements et synchronise chacun des serveurs. Cette synchronisation peut intervenir toutes les 15 minutes, de sorte que les modifications sont rapidement visibles.
Certes, durant la synchronisation, différentes petites incohérences transitoires peuvent intervenir. Les différents serveurs peuvent ne pas être exactement au même niveau, de sorte que si on a un load-balancing sans sessions, un même internaute pourrait apercevoir des pages différentes sur une même URL. Et sur un même serveur, une page de sommaire peut avoir été mise à jour avant une page référencée, de sorte que l’on courrait le risque d’un lien cassé. Ce sont de vrais problèmes, mais ces incohérences sont extrêmement transitoires, de sorte que la probabilité d’anomalie est faible, et les conséquences non critiques. En général, il suffira à l’internaute de rafraîchir la page pour voir disparaître l’anomalie.
Si l’on veut malgré tout éviter cela, alors il suffit de mettre en place un script un peu plus sophistiqué, qui prépare la nouvelle arborescence à côté de la précédente, puis bascule le serveur une fois synchronisé.
Cette forme de réplication est représenté sur le schéma suivant :

image106

A gauche on distingue un « contributeur », celui qui est susceptible de modifier les fichiers, par l’intermédiaire d’une application. Les fichiers sont répliqués sur N frontaux, ici W1, W2, W3, W4.
On a là une architecture réellement, totalement, extensible. En fait non seulement on pourra aisément ajouter autant de frontaux que l’on souhaite, mais de plus la capacité de chacun, servant des fichiers statiques, est extrêmement élevée, typiquement de plusieurs milliers de pages par seconde. Et ces frontaux peuvent aussi être répartis dans différents datacenters.
Il faut souligner aussi que ce n’est pas parce que l’on parle de pages statiques, de fichiers, que l’on ne peut pas bénéficier d’outils de gestion de contenus. Il est possible en effet de mettre en place un CMS sur le serveur de contribution, et donc de générer les pages à base de gabarits comme sait le faire un CMS. On exportera ensuite les pages produites dynamiquement par le CMS, sous la forme de fichiers statiques. Cet export peut être plus ou moins facile à réaliser selon les outils, mais il est généralement possible.
Quels sont les inconvénients de cette architecture sublime ?

  • Un peu de latence dans la mise en ligne de modifications, mais elle peut être réduite à quelques minutes ;
  • Un site qui est strictement en lecture seule, ce qui va à l’encontre des tendances actuelles web 2.0, où les aspects participatifs et de contributions communautaires deviennent prépondérants, sans parler des aspects véritablement applicatifs.

La réplication de contenus, de pages Html ou autres composants, sur des serveurs n’est toutefois qu’un des cas de figure de la réplication de fichiers.

On peut avoir à répliquer de simples fichiers de configuration, ou encore des programmes, ou des ressources utilisées par les applications.

Les outils de gestion de contenus manipulent également un grand nombre de fichiers : images, sons, flash, css, javascript, etc, mais aussi fichiers à usage interne : configuration ou templates, ou parfois fichiers de cache. Selon les outils, et selon les choix de configuration, ces fichiers peuvent être gérés en base de données ou sur le file system.

SAN

La technologie SAN (Storage Area Network) permet le partage d’un système de disques – mais non pas de fichiers – entre différents serveurs.
Pour bien comprendre son positionnement, il faut rappeler les trois couches intervenant dans l’accès aux données :

 

image108

L’application, qui est le « client ».
Le file system, système de gestion de fichiers, qui reçoit des requêtes des applications, les traite et leur répond. Le file system tient à jour une table d’allocation des fichiers, qui définit de quels blocs sur quels disques chaque fichier est constitué.
Le contrôleur disque, qui reçoit des requêtes du file system, les traite en accédant aux disques et répond. Le contrôleur disque ne connaît pas les notions d’utilisateur ni même de fichier. Il ne connaît que des disques et des blocs.

 

image110

Une configuration SAN intervient en aval du contrôleur disque et du file system, de la manière figurée ci-contre.
Les disques sont empilés dans une baie, raccordés le plus souvent par une liaison fiber channel à haut débit, sinon iSCSI, par l’intermédiaire d’un switch, qui permet de redéfinir à la demande la connexion des disques aux serveurs. Parce que les configurations disques sont gérées de manière globale et mutualisée, l’investissement est réparti, et l’on peut viser des configurations de très hautes performances, en termes de capacité, de débit et de tolérance aux pannes.

image112

Le principe général est que tous les disques d’une plateforme, ou d’un datacenter, sont gérés de manière globalisée, ce que l’on peut représenter comme ci-contre.

 

En effet, on ne peut pas partager des disques en aval de la table d’allocation, c'est-à-dire du file system. Autrement dit, deux file systems, gérant chacun sa table d’allocation, ne peuvent pas partager un disque.
Le SAN n’a donc pas une finalité de partage, mais plutôt de mutualisation de ressources, visant :

  • Une meilleure flexibilité dans l’allocation des ressource disque
  • De très hauts débits IO obtenus par stripping, répartition des bits de chaque octet en parallèle sur N disques.
  • Haute-sécurisation des données par RAID, répartition sur différents disques avec redondance permettant de tolérer une panne.
  • Gestion centralisée des sauvegardes.
  • Gestion rapide du secours, avec la possibilité de redémarrer un nouveau serveur sur la même unité logique. Ce qui est particulièrement efficace dans une architecture totalement virtualisée.
  • Et finalement, allègement de la configuration des serveurs, qui peuvent être sans disque.

Dans les plateformes web, le SAN est d’un usage réduit. C’est plutôt un outil au service de grandes infrastructures diversifiées, telles qu’un datacenter dans sa globalité. Dans ce contexte, la mutualisation peut compenser le prix élevé.
Le SAN est parfois incontournable, dans des domaines d’application qui requièrent de très hauts débits, et de très gros volumes, typiquement le brassage de flux vidéo.
Mais en conclusion, le SAN n’est pas la clé de l’extensibilité.

Architecture NAS

Un principe de partage
Au contraire du SAN, le NAS (Network-Attached Storage) est fait pour le partage de données entre différentes applications clientes.
Dans le cas du NAS, le file system est unique, et les questions de cache, synchronisation et cohérence sont donc traitées de manière centrale.

On le représente comme ceci :

image114

Les applications accèdent au file system réseau sur du TCP/IP, qui peut donc traverser des routeurs et switchs ordinaires. Les unités de stockage réseau peuvent être montées dans le file system local des serveurs clients, et donc être accédées de manière transparente par les applications, comme des données locales.

Bénéfices et limites
L’accès à un serveur de fichier de type NAS, typiquement NFS, est le moyen de partager des ressources fichiers entre différents serveurs, par exemple entre des frontaux web.

  • Il est approprié pour des ressources relativement statiques, mais dans ce cas la réplication peut être une alternative également.
  • Il convient moins à des ressources partagées en écriture/lecture de manière intensive. Dans ces cas d’utilisation, les problèmes de verrouillage peuvent provoquer des ralentissements importants.
  • Le débit IO est souvent limité par le réseau.
  • Les requêtes d’IO disques des différentes applications sont bien sûr additionnées sur le serveur NAS. L’extensibilité atteindra donc une limite.
  • Enfin, on voit que le serveur NAS est un point de fragilité (« SPOF ») de l’architecture, et nécessite donc un dispositif de failover.

NAS et SAN combinés
Servant, comme on l’a vu, des finalités très différentes, NAS et SAN peuvent tout à fait se compléter, avec une architecture de ce type :

image116

NFS
En matière de serveur de fichier réseau, une solution domine : le Network File System de SUN, NFS.

NFS est un protocole d’accès aux fichiers sur le réseau introduit par SUN au début des années 90, et devenu un standard de fait dans le monde Unix puis Linux. Il passe sur TCP/IP en 93, ce qui le rend compatible avec des réseaux de type WAN, mais malgré tout l’accès à un serveur de fichiers requiert des débits sensiblement plus élevés que l’accès à un serveur HTTP.

NFS est particulièrement approprié pour gérer le déploiement d’applications ou assurer l’unicité des données partagées. Mais il peut rapidement devenir point de contention de l’architecture en termes d’IO. Un partage NFS (ou CIFS dans le monde Windows) est en général peu approprié au-delà de 4 à 8 serveurs clients, selon le taux d’accès.

Un serveur NFS sera généralement doublé avec un spare, synchronisé par DRBD (voir plus loin), avec heartbeat et secours automatique

DRBD

DRBD est un outil de réplication disque qui s’insère entre le file system et le

contrôleur disque, de la manière suivante :

image118

Il assure une réplication disque transparente, vers un serveur de secours passif.

Il supporte deux modes de fonctionnement :

  • Synchrone : chaque opération d’IO ne se termine qu’après double écriture
  • Asynchrone : l’écriture répliquée est légèrement différée.

Le mode synchrone assure une parfaite cohérence des deux disques, même en cas d’arrêt brutal, tandis que le mode asynchrone assure de meilleures performances.

Il faut souligner que le file system de secours est totalement inutilisable, il ne peut pas être monté, même en lecture seule. C’est donc une configuration exclusivement réservée au secours.

L’accès concurrent aux fichiers

Les systèmes de gestion de fichiers réseau gèrent les accès concurrents et le verrouillage de fichiers, et même de blocs au sein d’un même fichier.

En fait, les applications modernes utilisent de moins en moins les fichiers, et encore moins en accès direct, ou en accès concurrents. Dans tous les cas, l’absence de transactions dans l’accès aux fichiers présente des risques d’incohérences. On ne peut pas englober 3 écritures sur 3 fichiers en une transaction insécable qui sera soit totalement exécutée, soit nullement exécutée.

L’utilisation typique est plus souvent du type : lecture globale du fichier, modification, écriture globale. C’est ce qui se passe lorsque le fichier représente un objet, sérialisé, ou bien stocké en Xml.

Lustre

Beaucoup croient que la problématique du file system est un sujet clos, une question réglée depuis 20 ans. On ouvre un fichier, on lit, on écrit, on ferme… rien de bien complexe là-dedans.

Mais il n’en est rien. Comme les SGBD, les gestionnaires de fichiers n’ont pas réglé tous leurs problèmes, et restent un domaine de recherche très actif. Parmi leurs problèmes figure, précisément, la question de l’extensibilité.

Lustre est un système de gestion de fichiers distribué, conçu pour une extensibilité maximale. Porté par une startup, il a été repris en 2007 par SUN, qui en a fait un produit stratégique dans son offre.

Lustre est un produit haut de gamme, open source, parfaitement robuste et « production ready », prêt pour une utilisation en production. Il est utilisé par plus de la moitié des 30 plus grands centres de calcul parallèle du monde. C’est d’ailleurs le domaine d’application favori.

Lustre peut gérer littéralement plusieurs peta-octets de fichiers, avec des débits globaux de plusieurs centaines de Gbps. Lustre traite en premier lieu d’extensibilité, la haute-disponibilité quant à elle, est traitée au niveau de chaque nœud de l’architecture.

Les principes généraux de Lustre sont les suivants :

  • Une gestion centrale des métadonnées. Les métadonnées, c’est tout ce qui caractérise le fichier : son nom, son répertoire, ses droits, dates de modification, … mais aussi sa répartition sur différents serveurs. Dans Lustre cette gestion des métadonnées est centralisée sur le MDS, MetaData Server.
  • Chaque fichier est réparti sur un ou plusieurs Object Storage Targets (OST), chacun composé de plusieurs Object Storage Server (OSS).
  • Une fois que le client (l’application accédant au fichier) a obtenu la table d’allocation du fichier sur le MDS, elle adresse des requêtes aux OST concernés.

Le caractère centralisé du MDS n’est pas un blocage pour l’extensibilité, puisqu’il y a un facteur 1000 ou plus entre les volumétries de fichiers et celles des métadonnées. Nous avons vu que d’une manière générale, le principe d’un partitionnement couplé à une forme d’annuaire global est une voie classique de la haute extensibilité.

Lustre met donc en œuvre un principe de partitionnement / consolidation, comme on l’a évoqué plus haut, mais ceci de manière totalement transparente pour les applications, qui ne voient que des APIs POSIX d’accès aux fichiers.

  • Si vous avez de très fortes volumétries de données au sein de votre plateforme web, alors Lustre est une solution à considérer.
image120

On voit sur le schéma ci-contre une variété de cas de figure, un serveur simple OSS-1, deux serveurs OSS-2 et 3, avec un DRBD croisé, leur permettant d’être en secours réciproque, et finalement un ensemble de serveurs partageant une baie SAN.

MogileFS

Dans la catégorie des systèmes de gestion de fichiers distribués et à tolérance de panne, il faut citer également MogileFS, qui a certes moins de références gigantesques, mais est d’une mise en œuvre plus simple, et constitue donc une bonne alternative pour une architecture web. MogileFS est un projet de Dange Interactive, les créateurs de LiveJournal, qui ont également apporté le gestionnaire de cache distribué MemCached.

Hadoop HDFS

Parmi les principaux systèmes de gestion de fichier distribués il faut citer également HDFS, associé au projet Apache Hadoop, dont nous avons parlé plus haut.