Quoi qu'on fasse, quelque soit les choix que l'on prend, on se heurte au théorème du CAP . Entre cohérence, disponibilité et résistance au morcèlement, on ne peut en choisir que deux. Ce théorème accompagne la mode du NoSQL, mais il a un effet rétroactif, il s'applique à toutes formes de stockage en réseau.
Mode block
La technique la plus transparente, le serveur met à disposition un "device block", qui est géré comme le serait un disque dur par le client, qui le formate avant de l'utiliser.
DRDB
Ce système très simple a été conçu pour les serveurs hautes disponibilités. Il s'utilise avec du RAID 1 logiciel. Le serveur principal monte un disque virtuel depuis un disque physique du serveur secondaire. Le serveur maitre monte un disque RAID 1 avec un disque physique et un disque DRDB. En cas de crash, le serveur secondaire peut être promu et il aura une copie des données. Au début des années 2000, dès que l'on entendait le buzzword HA, High Availability, on pouvait parier sur du DRDB.
On a ici une solution rigide : pour garantir une copie cohérente, il faut avoir une copie synchrone. DRBD garantie tolérance de panne, mais en cas de panne, le RAID recopie l'intégralité de la partition saine vers celle qui a eu un souci, plutôt que de se contenter de compléter ce qu'il lui manque. Tous les serveurs civilisés sont actuellement capables de faire de la réplication en mode Master/Slave, et donc faire de la réplication asynchrone en garantissant une cohérence. Je ne sais pas si DRDB est encore beaucoup utilisé en production, peut-être pour les solutions sans base de données.
iSCSI
Le concept peut sembler audacieux, de faire passer des trames SCSI dans du réseau IP, mais le SCSI a été conçu dés son origine pour communiquer avec plusieurs appareils, avec des messages asynchrones. Le SCSI aime le confort de ses grosses nappes, mieux vaut prévoir des gros câbles réseau, ou mieux, de la fibre optique.
Le iSCSI est un format standard de SAN. Il existe un équivalent pour l'ATA, Ata Over Ethernet , qui fait partie des technologies "juste ça marche", mais il utilise directement la couche Ethernet (L2) et de fait est non routable. Le format ATA a juste la notion master/slave et ne peut gérer que 2 périphériques.
Le iSCSI est très pratique dans le cadre d'un hébergement cloud. On peut créer et détruire des VM temporaires qui vont utiliser un volume distant, qui lui sera persistant. Amazon appelle ça EBS, Elastic Block Store, mais il existe aussi dans la plupart des hébergements Cloud. Le réel souci, outre le cout du serveur qui doit absolument être fiable, est le côté difficilement prévisible des performances. Les solutions de virtualisation sont plutôt fiables pour isoler les machines, mais pas le stockage distant. Certaines applications qui font trop confiance dans leur disque dur, comme MongoDB, souffrent pas mal dans ces conditions. Certains sites hébergés chez Amazon ont fait le choix radical de se passer d'EBS, et de se contenter de réplication applicative. DuckDuckGo a fait ce choix, mais il a un joker, son contenu est quasiment statique : il crawl un peu et se contente de dispatcher les recherches vers des moteurs plus traditionnels.
Mode fichier
Un système de fichier distant permet à plusieurs clients d'accéder à des fichiers distants comme il le ferait sur un disque local. Cette impression de "comme à la maison" est à double tranchant, les latences réseau, les accès simultanés d'une même ressource par plusieurs clients n'ont pas d'équivalent avec un accès direct. Les différentes technologies choisissent leur priorité et impasse.
Les traditionnels
Les partages traditionnels conservent la correspondance un fichier distant pointe sur un fichier local. CIFS , plus connu sous le nom de SMB (ou Samba, son implémentation libre) est très pratique pour connecter des clients Windows. Il existe l'équivalent Mac, AFP , mais à part les NAS multimédias, tout le monde s'en fiche. Ces deux protocoles peuvent imposer des restrictions arbitraires pour respecter leur filesystems d'origines.
NFS est le partage officiel des UNIX. Très classique, il s'appuie sur un grand nombre de rpc. Tout comme le CIFS, il est possible de choisir entre un montage sync ou async, pour choisir entre cohérence et performance. Le choix de la performance est souvent pris, ce qui a des effets un peu surprenants, comme le ls non garanti. Ce comportement est sujet de moquerie dans le monde UNIX, mais parfaitement admis dans le monde Windows.
Dans la même lignée, avec plus de violence, l' AFS . Andrew File System, une des briques du projet Andrew de l'université de Carnegie Mellon. Sans faire de révolution par rapport au NFS, AFS propose de passer à l'échelle supérieure, en gérant beaucoup plus de clients, des chiffres comme 25 000 clients sont annoncés. Comme amélioration, il propose l'agrégation de serveur. Les clients voient une seule arborescence qui en fait va pointer sur différents serveurs. AFS utilise massivement du cache, l'utilisateur lit et écrit en local, le serveur étant responsable de la synchronisation et des locks. Des possibilités de redondance sont proposées. Certaines fonctions d'AFS ont été reprises pour NFSv4.
Les réparties
Pour obtenir de meilleures performances, il faut casser la correspondance un fichier / un fichier et distribuer le travail en utilisant un serveur de metadata avec plusieurs serveurs de blobs, pour paralléliser les accès et proposer de la redondance. Cette souplesse permet de choisir les deux options parmi trois dans le théorème CAP, en fait. Conserver la notion de système de fichier et offrir de bonnes performances est apprécié dans les clusters de calculs, ce qui permet d'avoir un comportement similaire, entre son poste de travail et le cluster. Cette solution n'est plus aussi tendance, pour augmenter encore et toujours les performances de calculs, des approches plus radicales sont actuellement utilisées.
Lustre , mot valise pour Linux Cluster, est utilisé sur les clusters du top500. Il utilise un serveur de metadata pour plusieurs serveurs de blob. Clairement orienté performance pour du calcul, il sait utiliser conjointement plusieurs types de réseaux et du RDMA (Remote Direct Memory Access). Intel a racheté la startup chargée de faire les dernières améliorations de Lustre, et pour éviter que le produit se fasse accaparer par une entreprise, il est supervisé par openSFS .
MooseFS est un produit libéré depuis 2008, il reprend des principes de Lustre et du Google File System. Son serveur de Metadata propose une réplication en master/slave. Le client est basé sur FUSE et ils mettent un point d'honneur à tout implémenter la norme POSIX.
GlusterFS , un produit racheté par RedHat, utilisant une architecture décentralisée, avec la possibilité d'utiliser de l'infiniband en plus du classique réseau IP. Gluster gère une abstraction de stockage (qui peut se compter en peta) auxquels accèdent des clients via des traducteurs. Le stockage peut assurer de la redondance et du stripping (comme le ferait du RAID1 et du RAID0). Les clients peuvent se connecter en NFSv3 ou avec un protocole spécifique, via FUSE. Il est officiellement possible de partager un partage glusterfs, en samba, par exemple. Il intègre de l'anti entropie dans sa dernière version. Acquia l'utilise pour son offre cloudifiée de Drupal.
Ceph a été récemment (2010) inclus au kernel Linux et propose une version stable depuis 2012. Ceph recommande de s'appuyer sur BtrFS et propose une architecture headless. Comme originalité il propose 3 approches pour mettre à disposition les données. En mode block, à la SAN, en mode fichier, en natif FUSE, et en mode objet, à la S3. Il propose aussi une API pour C, C++, Python, Ruby et PHP. J'ai hâte de pouvoir tripoter mon premier peta octet en PHP. Il semble vouloir être la solution ultime pour Linux.
Mode Objet
Vouloir s'accrocher à tous pris à la notion de fichier et poursuivre la course à l'armement mène à une impasse. Accéder à un ensemble de disques avec des contraintes de résilience et de performance au sein d'une grappe de machines n'est pas comparable avec le comportement d'un disque classique utilisé directement. L'arrivée des SSD ne change pas grand-chose. Il faut limiter les exigences, et se contenter de mettre à dispositions des gros blobs, plus joliment appelés "objet"
HadoopFS est l'implémentation libre du white paper de Google sur son Google File System. Comme son nom l'indique, il est utilisé par Hadoop . HadoopFS ne propose pas de filesystem POSIX, mais une solution adaptée aux besoins de stockage sur du matériel courant. Premier constat, les disques durs deviennent de plus en plus gros, mais les temps d'accès restent sensiblement les mêmes. Les disques durs à plateau sont devenus les lecteurs de bandes d'hier, bon débit, gros stockage, mais seek hors de prix. Il faut donc écrire et lire des données dans des blocs contigus. Pas de seek, donc pas de possibilité de modification sur place, les blocs ne peuvent être que lu ou écrit entièrement. Il faut par contre reconstruire de temps en temps, en écrivant un nouveau bloc à partir de données dispersées. Cette contrainte permet de résoudre simplement les soucis d'accès concurrents depuis différents noeuds d'un réseau, tout simplement en ne les gérant pas : les blocs sont horodatés, et pour une même clef, on considère que le plus récent a raison, ou l'on peut résoudre le conflit depuis son application. Le trie des données permet de réduire le nombre de serveurs interrogés en cas d'itération pour obtenir un résultat : les réponses sont de fait contigu. Les clusters hadoopfs sont constitués de la maintenant classique paire metadata et stockages. Les serveurs de metadata sont choyés, avec du RAID1, par contre, les serveurs de stockages sont un empilage du plus grand nombre possible de disques (pour répartir les temps d'accès), et pas forcément les plus volumineux, avec autant de core CPU que de disques, et pas forcément à des fréquences très élevées. La RAM est conséquente, mais sans commune mesure avec le volume de stockage. Les SSD n'existaient pas à l'époque, ce qui permet à des produits comme Cassandra de pouvoir pinailler sur des détails d'implémentations tout en reprenant des principes similaires. Un des principes fondamentaux d'Hadoop est de favoriser la localisation du travail, plutôt que tout faire transiter par le réseau, dans tous les sens, il est plus simple d'effectuer le travail là où sont les données, pour ensuite le regrouper avant de répondre à la demande. C'est le célèbre map/reduce, une des armes secrètes qui a rendu Google aussi puissant. HadoopFS est écrit en Java. HadoopFS répond de à des besoins spécifiques, pour des applications spécifiques. Hadoop est son utilisateur principal, mais il y a aussi Hbase qui propose un accès un peu moins brut aux données, avec une api NoSQL. Pour l'instant on ne connait pas la limite physique pour Hbase, d'où le slogan de "web scale". Le ticket d'entrée pour HadoopFS est de cinq serveurs, et Yahoo, principal contributeur a monté des cluster Hadoop de plus de 5000 machines.
MongoDB propose GridFS qui permet de profiter des facilités de réplication de Mongodb, ou de conserver une cohérence avec des métas donnés complexes. Les plus aventureux pourront utiliser les modules Nginx et Apache pour le brancher directement sur de l'HTTP.
Partage HTTP
Entre l'approche système de fichier POSIX et API spécifique, il existe une solution standard et élégante : HTTP.
Le premier a avoir tout misé sur HTTP est est bien sur WebDAV qui a été torpillé par Winddows95, obligeant tous les serveurs a faire des choses bizarres pour être compatible. Résultat, aucun OS ne propose un client natif WebDAV décent, à part peut-être le gvfs de Gnome? De toute façon, l'idée d'un point de montage en HTTP est un peu criminelle : HTTP reste un protocole déconnecté, malgré les optimisations d'HTTP 1.1 . WebDAV, malgré la généralisation de CalDAV et CardDav semble être une mauvaise approche : porter les fonctions de FTP sur de l'HTTP n'est pas une si bonne idée.
Il n'est pas nécessaire de rajouter des mots au vocabulaire HTTP pour servir des fichiers, le REST couvre tous ces besoins. Il est alors possible d'exposer l'API aux utilisateurs, directement, ou via un proxy. HTTP est le meilleur ami des proxys.
MogileFS fut un des précurseurs dans le domaine du stockage HTTP. Pour rappel, Danga est une boite de perliste qui a initié beaucoup d'outils indispensables du web actuel : memcache (cache distribué), gearman (taches asynchrones), ou perlbal (du code métier dans un proxy HTTP). MogileFS utilise un serveur de metadata (du mysql en master/slave) qui indique où se trouve une donnée, qui ensuite passe par un proxy (perlbal) pour arriver sur le client. Il est possible d'appliquer des règles de redondance différentes, pour distinguer une image originale de ses vignettes, par exemple.
Le Simple Storage Service (S3) d'Amazon est rapidement devenu un standard de fait comme solution de stockage sur HTTP. S3 propose un système simple de stockage en chemin (pour ne pas dire clef) valeur, avec une écriture atomique, en 3 exemplaires. Il propose un système d'ACL et même de délégation de droit temporaire. REST sur le principe, mais pragmatique dans son implémentation, il propose par exemple l'upload direct via un formulaire web pour que le client puisse envoyer directement ses données sur S3, plutôt que de passer par l'intermédiaire d'un site web. Il utilise les spécificités du protocole comme les headers et les redirections. Depuis sa création, AWS a rajouté des surcouches comme un CDN (Cloudfront) et de l'archivage (Glacier). S3 a permis de démontrer la faisabilité d'héberger un site web sur un support volatil (les machines EC2) tout en centralisant les uploads de fichiers sur un stockage redondé. Le REST oblige à avoir des échanges courts, ce qui peut poser des soucis pour les traitements lourds. Effacer un dossier a toujours été une cause d'angoisse sur S3. Depuis décembre 2011, il est possible d'effacer par paquet de mille, c'est donc au client de lister les fichiers contenus (la notion de dossier n'existe pas dans S3, il existe juste des chemins), puis de boucler pour les effacer. REST attitude.
Riak est une base clef/valeur décentralisée REST. Les valeurs sont des blobs avec des headers, et malgré une limitation à 50M par fichier, Github de l'utilise pour héberger les pages statiques utilisateurs , offrant ainsi redondance, de beaux IO et un système d'url unique. On peut comparer ce choix d'architecture à un vélo sans vitesses de couleur vive, mais la mise en place à été rapide, et ça fonctionne. Le projet Luwak a eu la volonté de gérer des gros fichiers, mais il semble mort, et Riak propose maintenant RiakCS, un produit non open source qui singe l'API S3.
LeoFS est un serveur décentralisé proposant une API compatible avec S3 offrant réplication et gros volume de stockage. De l'erlang par des Japonais qui ne savent pas faire rêver avec leurs PowerPoint.
BackBlaze a développé une solution personnelle de stockage à des fins d'archivages (en HTTP). Le produit est propriétaire, mais le hardware est libre, ils fournissent les plans et la liste de matériel pour construire leur grosse boite rouge. Leur solution, avec 45 disques durs (soit 135To), permet d'obtenir un prix au kilo imbattable. Il faut prévoir de redonder les serveurs, qui pèsent quand même plus de 70kg. Ils ont un gerbeur, dans leur datacenter, pour ne pas se faire mal quand ils vont cueillir les disques morts et les envoyer en SAV, chaque semaine.
OpenCompute , une initiative pour proposer des serveurs normalisés et peu chers, aura des filers ressemblants aux serveurs rouges de BackBlaze.
Conclusion
Toutes ces solutions laissent beaucoup de place pour le tuning. Kernel, RAM, swap, mais aussi les systèmes de fichiers : JFS qui n'a plus la cote, XFS qui profite encore de son aura et de sa capacité à encaisser des gros débits, Ext4 qui prouve sa qualité (en plus de son coté officiel), et BtrFS qui fait rêver (en plus de venger l'humiliation ZFS). Il n'y a pas encore grand-chose de spécifique pour les SSD, qui supporte très mal les cycles multiples d'écritures, à part peut être le Flash cache de Facebook. Pour l'instant, c'est principalement les applications qui s'amusent avec les supports flashs ( Fatcache un clone memcache, Cassandra ...).
Ces solutions, plus ou moins exotiques, ne sont pas uniquement là pour gérer des grosses volumétries, LVM permet déjà de faire de beaux empilages. Tôt ou tard, les fidèles outils comme rsync, inotify, fsck ou find commencent à montrer leurs limites. La redondance, les débits, mais aussi les snapshots, la réplication sur un site distant, la recherche, le redimensionnement à chaud, font partie des fonctions proposées. La plupart des ses solutions s'appuient sur du matériel classique et abordable, en plusieurs exemplaires (dimensionnement horizontal) plutôt que de faire la course au matériel de luxe (dimensionnement vertical).